By Janus Boye
We have been here before. A few years ago vendors were touting personalization software. A major buzzword of the dot-com age, personalization would ostensibly solve a series of business problems and enable a new IT paradigm. Many personalization projects failed due to lack of adoption, long implementation times, problems with the technology, lack of clearly defined business goals, integration and testing difficulties, and cost overruns.
Today many companies are experiencing the exact same difficulties with a new breed of enterprise software called portal software. Nearly every major software vendor has created an enterprise portal solution, which in many ways has replaced their personalization hype. Certainly the CMS market is young and immature, but I would also caution buyers that the market for portal solutions is younger and much more immature.
In fact, I question the whole concept of portal software. Based on a series of issues I have found with portal applications while working on CMS projects during the last few years, I am not convinced this is an investment each and every company should consider.
Brief History
A few years ago the term "portal" emerged in connection with major websites such as AltaVista, Google, MSN and Yahoo!. A portal offered a single entry-point to content and functionality. In today’s world we have portal software, which is roughly an attempt to recreate Yahoo! within the enterprise.
But you should consider the question: What does a portal really mean for my enterprise? Your answer will vary depending on your company. More importantly ask yourself: What is the difference between a Web site and a Portal? In this article I would like to challenge the commonly-held notion that you need portal software to create a widely functional Web site.
Strengths of portal software
In my view there are primarily two benefits that portal software can bring:
Enabling business users to visually arrange design elements (via pluggable portlets).
Portal vendors have taken steps towards the holy grail of enabling non technical business users to dynamically arrange and rearrange informational elements on a page. In practice, however, there is little evidence that portal users routinely modify default interfaces, and the overall design of content pages tends to resemble a stack of cards, which can be more or less usable depending on circumstances.Enterprise Content Integration.
Portal software can certainly be useful in an intranet where the company wants to present a unified interface to many back office systems and provide a single sign-on to those systems. In my view this is probably the best use for portal software today. The important thing to remember, though, is that you are unifying the interface, and perhaps creating a crude "dashboard," but not actually unifying the underlying logic and content models unless you invest in more costly and difficult application integration.
Nevertheless, for true content integration across multiple repositories and applications, most experienced developers will also prefer to work with portal software rather than a CMS. Portal vendors -- either themselves or through close partners -- bring stronger integration facilities with superior options for rapid development and deployment.
Fortunately, today technical standards are emerging that are relevant for integration. JSR-170, from the Java community process, specifies a standard API to access content repositories via Java 2, independently of implementation. JSR-168 is also relevant as it aims to enable interoperability between portlets and portals. Unfortunately few vendors support these, and for the Microsoft-based world there are still no good answers. Both were designed by committees so contains the basic minimum set of functions supported by each major vendor. In my experience, to make use of all the really useful portlet features that a portal vendor can offer, you will end up with a non-standard portlet.
Weaknesses with portal software
The problems with today’s portal solutions come in different flavors; business and technical.
Generally the market for these solution is immature. While portal vendors might have used various tricks to make the version number seem high, prepare yourself for challenges with unproven technology. New versions may or may not be backward compatible, service packs might require significant recoding, and do not expect the technical documentation to be entirely correct and updated. Of course, licensees say many of the same things about CMS products, but generally, portal tools are newer still.
Here is a brief overview of more weaknesses, starting with potential business shortcomings.
Costs.
Most portal software is based on an application server (either MS-based or J2EE). As application server pricing has plummeted, vendors have tried to reclaim what was lost with increasingly higher licenses on portal software. Pricing for commercial portal software is typically done either per CPU or per user. Keep in mind when you sign a software contract, that implementation costs for a portal project are typically at least 4 – 5 times the initial license fee.Usability.
Out-of-the-box most business users will be intimidated by the user interface offered. If you speak to existing portal users they will most likely call their portal software a nice demo, but very cumbersome to work with. Arranging and placing portlets on major sites can be a very time consuming effort. As the site structure grows, the navigation load time can increase dramatically. This is a problem web content management systems experienced years ago, but most have solved today. If you add a new menu item or rearrange the navigation you might be forced to place the portlets from scratch again. Most portal interfaces were far from designed for business users but instead IT staff.
Consider the screen above (click for larger version), an out-of-the-box installation of Sun Portal with FatWire Content Server. Users require significant training before they are comfortable working in this super user environment.
Among other problems, the occasional business user will find it very hard remembering what all the button and functions do. Of course, businesspeople may have the same difficulty using the applications (like this CMS) in a stand-alone environment, but in the latter case there is at least some context and the opportunity for in-line explanatory text that the squeezed portlet environment typically does not afford.Bookmarks.
With freedom to rearrange the design of the page, freely move portlets around, many portal users have realized that this comes at the expense of working bookmarks. This means that after brief time, visitors cannot expect their bookmarks to work, as the portlet they bookmarked might have been moved or might contain something new and entirely unexpected. Effectively the only page you can reliably bookmark is the frontpage. Any bookmarks below this level may not provide the expected result, unless you during the implementation spend time constructing the URL in a way so that bookmarks work. The problem with this implementation effort is that it runs counter to the provided flexibility to freely rearrange and reuse portlets. And unless you invest time on it, all pages will also have the same title, which makes it even harder to work with bookmarks.
Technical weaknesses
Performance.
Working with portlets typically requires thousand lines of code to be executed quite often, while the end result may be just a few lines of HTML. This puts strain on servers and requires projects to invest considerable time in caching and performance tuning. . Many firms acquire expensive high-end hardware to run portal software. It is a fact that most content is not dynamic and as such there is no need to deliver it dynamically. Do consider mixed publishing (dynamic and static) as an option to reduce the hardware investments needed.Obtuse URLs.
This is related to the bookmarking problem above. It seems like most vendors do not care about human-readable URLs. Well, humans do. Portal software is notorious for incredibly long URLs. This has several drawbacks, not the least of which is search engine optimization on public sites. Consider this URL from the BEA WebLogic-driven TDC Kabel TV, or this IBM Websphere Portal Server URL from the Copenhagen Stock Exchange.
Issues of integrating portal software with your CMS
Portal vendors have discovered the importance of content management and tackled it with different approaches. Initially most portal software was entirely without any content management functionality. This is no longer the case, as vendors like Plumtree cried out for "no empty portals," and licensees came to see the need for a concurrent CMS investment.
To get a larger piece of the overall pie, portal vendors have developed strong alliances with major CMS vendors coupled with either 1) acquiring a CMS package (done by IBM, Plumtree, Broadvision, and Microsoft), or 2) building their own CMS (e.g., Oracle and to some extent BEA).
For the business user, working with CMS and portal software typically means working with 2 different interfaces. Yes, these can be integrated into one, but in my experience this can be quite difficult and therefore few licensees actually do this.
For a web editor this must lead to the question: Why is a CMS not enough? You can draw a line between the two, as many have done, by saying that the CMS is responsible for managing content and the portal for delivery. This leaves an important grey-zone for the business user: Where do we place navigation, site structure and preview? How do we ensure that the non-technical business user can control the navigation and preview content with the actual site layout?
A really nice CMS feature is the ability to edit text directly on the site -- either through in-context or pure in-line editing. When put together with a portal solution, this is extremely tough to implement, as you then will need a way to write changes from the portal to update the CMS. What this means for many users, is that a key CMS out-of-the-box feature can not be used. There are techniques that a CMS vendor can use such as “preview this page in the portal” or using a preview version of the portal in the same editorial environment as the CMS. With the use of portlets to delivering the content to the end-user, this still makes the content manager’s job difficult as she will never be able to preview all the combinations that an end-user might select and this means the content manager can never answer a basic question; “how is this going to look on the page?”
Reconsider the business requirement
In fact most site visitors do not require portal functionality. This is especially true for public Internet sites. I have been in many presentations where I have been asked about providing the end-user with a “My Yahoo” type experience. When I ask how many customers they surveyed to get this requirement the answer is usually “what survey?”
The last time I came across this was for a local government council office. Most visitors of local government sites don’t want to rearrange their own pages and portlets. They just want to know when the next garbage collection will be or what times the local swimming pool opens. If my local council proposed offering me a portal, I would tell them to spend the money on a decent search engine. Forget about the personalized portal experience – just show me the right content and show it to me quickly.
Most vendors now speak to the Intranet use case, or the holy grail of an "Enterprise Information Portal," or EIP. Consider, though, the top features repeatedly requested on corporate Intranets:
enterprisewide search
employee directory
common guides and handbooks
instructions and other HR information for new employees
links to commonly-used internal applications
Do you really need portal software to accomplish these? Maybe you should start by creating a small-p portal deploying a simple website on top of any existing Intranet sites, and invest in big-P portal software only after you have put in place successful processes for publishing and aggregating high-value, highly-sought information. You may find you don't need portal software at all.
In any case, don't use the crush of a software deployment as an excuse for getting organized about the information needs of your employees -- you'll probably just fail on all counts.
This is because building and maintaining any Web site or intranet requires work. Writing quality content requires even more ongoing work. Using portal software is not a silver bullet. It is complicated and will require major efforts to get up and running and to maintain. Presented with proper alternatives the business case would most likely benefit immensely from reconsidering the requirement for portal software.