Portal products lend themselves to rapid deployment. Use of prebuilt integration components dramatically affects the resources and effort of deploying the 1.0 release, compared with subsequent releases of an enterprise portal.

Core Topic Internet Platforms and Web Services: Internet Applications, Portals and Technologies Key Issue What are best practices in deploying enterprise portals, and how are enterprises managing full deployments? Strategic Planning Assumption Through 2004, enterprises will understate by 50 percent the effort to enhance and maintain enterprise portals (0.7 probability).

Many portal product vendors provide good "out-of-the-box" functionality — that is, the vendor offers a long list of off-the-shelf integration components (e.g., portlets, gadgets, OMlets, Iviews, Eclips) for integrating a variety of applications and repositories. This functionality delivers to the end user a rapid prototype and fast deployment of the initial release of an enterprise portal. Nevertheless, out-of-the-box functionality is only indirectly tied to the overall architecture of the portal product. It is, rather, a manifestation of the partnerships created by the portal product vendor and the effort invested in providing this method of integration.

New Rule of Thumb. For the initial release of an enterprise portal (release 1.0), 90 percent of the capability will be delivered by the out-of-the-box features of the portal product, while only 10 percent will be delivered by custom integration components.

For subsequent releases of an enterprise portal (releases 2.0, 3.0, etc.), this ratio reverses, with 90 percent of new capability delivered by custom integration components, while only 10 percent of new functionality will be delivered by new out-of-the-box features.

This 90/10-10/90 rule has dramatic implications for the total cost of ownership (TCO) of the portal, the skill sets required, timing for subsequent releases, maintenance to back-end applications and overall architecture of the portal product.

TCO. Although many enterprises think that the major costs of the portal go into the product acquisition and initial release, those that have done their homework recognize that the long-term TCO of the portal is driven more by subsequent customization work.

Custom development of integration components is required for all those integration points that are not satisfied by the off-the-shelf portal integration components (portlets) or middleware/enterprise application integration (EAI) capabilities. This custom development can be extensive, and must be completed by internal developers or outsourced to consultants or systems integrators (SIs) — so these costs can be tremendous. Gartner encourages clients to budget one to three times the acquisition cost of the portal product for development, deployment, maintenance and support of the portal during its first two years of use.

Skill Sets. Custom development of integration components requires highly skilled developers. Those that follow the integration component approach must write code that calls for low-level application programming interfaces (APIs) or SQL statements. This code must be implemented in a variety of programming languages, depending on the portal product vendor selected. The majority of portal product vendors support Java for this purpose — and skilled Java resources are expensive, and will remain in short supply through at least 2002.

Timing for Subsequent Releases. The 1.0 production release of the enterprise portal usually occurs within four to six months of initiation of work. The 2.0 release, which requires significantly more custom integration development, may take much longer to deliver. It's a mistake to try to deliver additional functionality in a single release rather than through point releases. Iterative approaches should be used in the initial release, as well as in subsequent releases.

Maintenance to Back-End Applications. When back-end applications are upgraded or changed, the integration mechanisms for those applications must also change. If the integration mechanism is a portlet, these updates and changes present opportunities for software to get out of sync. The portlet model can be somewhat brittle — changes in the back end frequently break the portlet. The effort of coordinating updates to both the portal and the back-end applications will be a drain on enterprise resources. Because most portal products don't have sophisticated change management mechanisms, this synchronization will have to be done manually.

Overall Architectural Requirements. Portal products must have two major application integration mechanisms:

• Portlets
• A middleware/EAI (abstraction) approach