Explaining the success of portal technology in a difficult economic environment is easy. Companies seek to exploit investments in existing applications and information sources. Information technology departments are trying to reduce cost by centralising, by regaining control over a mass of disjointed, redundant Web sites and applications, and by easing the deployment and administration of client-based applications.
In the meantime, business users are enamoured with the notion of sharing their workload and reducing turnaround time by collaborating with customers and partners.
Many portal advocates have found that the most compelling business case comes without numbers to back it up: the universally experienced information overload, the need to access and navigate through a sea of applications and information sources. C-level executives, those who approve big-ticket technology purchases, feel the pain as much as anyone else.
But somehow it's not quite so easy to explain what a portal is, and vendors have not helped. Joining the until-now, department-oriented, pure-play vendors are infrastructure vendors such as IBM, BEA Systems, and Sun Microsystems, offering portal functionality as a means of differentiating themselves in the application server market. Enterprise resource planning (ERP) and customer relationship management (CRM) vendors often refer to their Web-enabled interfaces as portals. Content management and e-commerce vendors, who have, arguably, been in the portal market for longer than they were called portals, are claiming leadership.
The confusion has led many companies to implement numerous portals using various products and technologies, sometimes depending on the applications they intend to deploy, sometimes depending on a specific source of information, sometimes on a specific audience, sometimes on a specific business process. Unless companies check this trend, they risk the same kind of proliferation that caused the problem in the first place.
The key to solving this problem is in finding the common denominator, the foundation for all portal deployments, the portal framework that can serve all portal needs-no matter the constituency, the source of information, or the intended use.
With the help of our clients, AMR Research has identified the five essential requirements for a unified portal framework (see "Build a Unified Portal Framework: Regain IT Control," The Report on Enabling Technologies, November 2001) and we've evaluated the top 15 portal products according to these requirements (see "The Portal Framework: The New Battle for the Enterprise Desktop," The Report on Enabling Technologies, March 2002).
For vendors, the stakes are high
For vendors, offering a portal framework is more than just a matter of jumping into the hot market in a cold environment. The portal framework is set to be the single point of entry for internal and external constituents-the single human interface for the enterprise.
Though large vendors may have ceded control of desktop tools and operating systems to Microsoft and IBM (for now), the portal framework may give them another chance at a killer category. And, since a portal framework can, conceivably, lock a given company into standardising on a specific development platform (including an application server, a database system, development tools, and more), a portal can be the vendor's doorway to exclusive and ever-expanding revenue.
Further urgency comes from the idea that becoming the established portal framework means displaying the information produced by other systems. For example, consider that Oracle's portal could become the primary means of accessing and deploying SAP and Siebel information and processes.
Part of the Oracle portal role would be to get the 5% of information relevant to a given end user out of SAP or Siebel and in front of the appropriate person in the appropriate context. Back-end-and so-called backbone-applications could end up getting devalued as even fewer users interact with them directly.
Users are in early phases
Most portal framework deployments are still in their infancy, serving a specific audience or business function while moving toward more universal use. At least part of the reason is that, despite vendors' honest assertions that the technology can be implemented in a matter of months or less-governance, change management, and other organisational factors take a great amount of time.
Simply deciding which applications should be deployed through the portal takes time-even before one starts the development and integration effort. And there are so many appealing uses for the portal, it's like a lifelong pass to Disney World: so many attractions, but you can only get to one ride at a time.
1. Think business goals first, requirements second, existing infrastructure third, and products last when evaluating portal framework strategies.
2. Plan for the ultimate portal framework rather than the immediate. For instance, even if your initial portal deployment is only departmental, make sure that administration and content contribution can be delegated when the portal expands.
3. Avoid systems that are firmly tied to specific applications and information sources. Choose a product that relies on open standards and obviates the need for specialised development expertise.