Comparing Portal Products
Enterprise Portals: Tip of Which Iceberg?
by Janus Boye
06-Apr-2006 --
Today's enterprise sets ambitious goals for content and service integration. Following nearly ubiquitous advice from the trade press and conference circuit, IT departments and business units frequently turn to portal software to help them achieve those goals. But many customers find to their great frustration that their portal package is much less out-of-the-box than they hoped.
Meanwhile, the much mis-used term "portal" can describe solutions to a variety of disparate business needs, from workgroup project collaboration to customer self-service extranets.
So if portal software is only the tip of the project iceberg, then customers and vendors also need to ask: which iceberg are we on? After talking to dozens of customers and integrators around the world in connection the just-released Enterprise Portals Report, we came to identify different types of portals, and found that no single portal software vendor excels across all scenarios.
Portals: The Good
I've pointed out previously that portals offer some key strengths, particularly when compared with traditional content management systems or simple web applications. Portals address the need for improved business processes by providing a framework for integrating existing applications and information stores, and creating a flexible infrastructure that can adapt to shifting enterprise requirements.
At a high level, portals can play a role in broad strategic initiatives by:
- Improving coordination with business partners, suppliers, and customers
- Facilitating internal and partner collaboration, even among widely-dispersed teams
- Allowing better management of intellectual assets
- Aiding in compliance with government regulations.
More specifically, portal technology can:
- Enable business users to visually arrange design elements and perhaps build composite applications.
- Deliver dashboard-style interface integration, including personalization
- Provide a framework for deeper content and process integration
- Offer a platform for application development more broadly, often with tight integration to a favored IDE.
Obviously portal software does not do all of this on its own. Portal products typically leverage existing services, such as enterprise software, document management, search, and data warehouse tools.
Portals: The Bad (and the ugly)
And therein lies the germ of the first potential problem with portal products. It can be hard to understand which services the portal package supplies itself, and to what extent the platform is merely providing a window into your existing (and perhaps rather ugly) enterprise tools and repositories.
A portal may provide a nice set of built-in applications that can get you off the ground in a short period of time. In reality though, what often happens is that portals prove to be just the tip of the iceberg, with much more work to customize and integrate the various layers than most customers expect. As with other similar technologies, portal buyers tend to underestimate implementation times and costs and overestimate the pace of user adoption and business pay-back.
Of course, in any young market, there are always rapid changes and growing pains. All the major software infrastructure players can now boast portal offerings, but the technology remains comparatively immature, with vendors and customers alike struggling to address chronic performance problems, usability shortcomings, and low adoption rates.
Our research found performance problems particularly crippling. Many portal customers find themselves buying too much software and too little hardware. Despite sophisticated caching and related technical wizardry, the fact remains that portals are resource-hungry animals, whose voracious appetites have a tendency to reveal themselves tardily during final user-testing.
Therefore, truly meeting the expectations of business control and real integration almost always requires significant effort. In many enterprises an initial portal project takes no less than 12 months, with full roll-outs measured in years. This is far from any dream of a brief "Web 2.0" project, and more like a tough ERP implementation. Underestimating complexity is one of the common reasons why CMS projects go over budget, and the same unfortunately applies to portal projects.
Your Choices
There is an important caveat to all the generalizations above: portal implementations frequently differ with respect to scope. Some portals are designed to span an entire enterprise, while others seek to fulfil a specific business mission, often at a departmental level. Not surprisingly, different vendors target different scenarios. All vendors in the Enterprise Portals Report call their products "enterprise portals," but the reality is that they do better and worse across different use cases and vary substantially in complexity and cost.
Consider as an example the popular Microsoft SharePoint Portal Server, which may be a good fit for workgroup document sharing, but quite weak for e-business and self-service scenarios that involve participants from beyond the enterprise.
To better understand the various portals vendors, it can be useful to take a closer look at the following archetypal use cases:
- Dynamic web publishing; possibly the simplest use-case and a common entry point for portal developers.
- Self-service portal; improving customer, partner, or employee care by enabling them to help themselves and obtain better service on their terms.
- Collaboration portal; allowing geographically dispersed teams to work together on projects, handing out assignments, collaborating on tasks, providing review on documents and tracking progress.
- Enterprise intranet; helping employees work more effectively and efficiently, often via multiple specialized portal applications.
- E-business portal; enabling enterprises to extend commercial information and services to external trading partners, suppliers, and customers
- Enterprise integration; possibly the most complex use case, piecing together enterprise systems to achieve greater efficiency and agility.
Some vendors will do well in multiple scenarios, but as noted earlier, no vendor on the market today does well in all of these. (The Enterprise Portals Report identifies the suitability of different vendors for these specific scenarios.)
The systems on the market in 2006 also have quite different IT architectures. You can choose between systems based on .NET, Java, or Python. Some of these are designed to be interoperable with other systems, utilizing a service-oriented architecture for integration, while others are clearly more intended as stand-alone portal solutions.
Remain practical, and do your homework
It's always a balancing act to make the decision to acquire a portal. In your enterprise, timing will be driven by organizational issues, budget processes, and ideally no little amount of strategy. While it may be tempting to launch an ambitious portal project, the real advantage may come in making conservative portal investments, building and testing at each step of the journey.
That way, you can more effectively deal with inevitable and potentially quite difficult engineering challenges, but also ensure that you are rolling out the right platform for your particular scenarios. Keep those ambitious goals, but remain realistic about the limitations of individual portal solutions. Good luck and let me know how it turns out!