WebSphere Portal Server: Aparat Emptor (Let the Buyer Prepare)

IBM's WebSphere Portal Server is attaining significant market and mind share. However, it is a complex product that must be approached with caution and insight to ensure success.

META Trend: By 2004, portal frameworks will become the centerpiece of a delivery infrastructure that acts as a fulcrum to aggregate reusable application, content, analytical, and collaboration components for highly dynamic user interfaces. By 2005, organizations will exploit portal frameworks to deliver contextual business workspaces, enabled via maturing XML and Web service standards. Through 2007, portal vendors will increasingly leverage enterprise infrastructure services.

IBM has had a hit on its hands with its WebSphere Portal Server (WPS). After starting poorly with its Enterprise Information Portal product (really more of a services offering), it decided to develop a new product to complement its WebSphere portfolio rather than acquire a mature vendor. The resulting product (now in Version 4.2.2) is an add-on to its WebSphere Application Server, which is still leveraged for its execution and clustering capabilities. IBM’s success comes as no surprise given its global reach, powerful sales channel, strong consulting services, and ready-made market of “Big Blue” shops. Indeed, IBM rated as one of only three leaders in the October 2002 METAspectrumSM.

Initially, WPS was rough around the edges (e.g., security, integration of Lotus components), but it has been chipping away at these issues with each new release. We remain hopeful that Version 5 (2H03) will make further headway, particularly with regard to installation. We expect future versions in 2004/05 will continue to whittle away at the issues, though internal organizational separation between product groups will remain a challenge. IBM will be a market share leader in the portal market through 2006, after which time we believe IBM will seamlessly blend its portal product into the WebSphere application server and assume the role as interface for other IBM products. In the meantime - to IBM’s credit - it has been willing to dedicate significant sales and consulting resources to solving client problems.

However, beneath its success there has been a constant grumbling of customers who have been less than pleased with the product. These customers are demanding significant sales and consulting attention to resolve their issues, which include the following:

• Depth of functionality: Customers have found that functionality and integration, which were expected to be “out of the box” (e.g., single sign-on [SSO], content management), required unanticipated consulting time to fully implement.
• Scalability and reliability issues: There have been problems with WPS on the mainframe.
• Long installation times: Two- to four-week installation times with frequent reinstalls are common before any development can begin, even with IBM Global Services (IGS) resources. Preconfigured images can help address this issue but are not always an appropriate fit for the client’s environment.
• Content management: Clients have found bundled Web content management capabilities (WebSphere Portal content publishing [WPCP]) to be basic and easily outgrown. However, the full-scale alternative, IBM Content Manager, is an enterprise (not Web) content management solution that is far more complex than most organizations want to tackle. IBM is addressing this issue through its Aptrix acquisition. Although the current Aptrix offering from IBM (sold under the name Lotus Workplace Content Development) is not integrated into WPS, IBM will be adding or replacing its current WCPP use with Aptrix technology during the next 12-24 months.
• Lotus integration: The presence of Lotus components (e.g., Domino, Sametime, Quickplace) often leads to a WPS decision. However, we have uncovered issues with the depth of integration into these products. Single sign-on is a particular pain point if a separate LDAP directory is used. Version 4.2.2 had numerous fixes for this and, as these components are rewritten on the WebSphere platform (expected YE03), such problems are expected to diminish.

We have encountered a few happy WPS customers with successful implementations but not as many as unhappy clients. Successful WPS projects seem to share many characteristics: strong IBM relationships, highly strategic projects with large budget and flexible time frames, previous WebSphere Application Server (WAS) experiences (many of the difficulties can be traced back to this), and use of experienced systems integrators for implementation.

Such issues have not been common to all large, complex portal projects. Conversations with customers of other portal products (Plumtree, in particular) have uncovered high levels of satisfaction and few surprises in terms of functionality or difficulty. It is true there is a spectrum of “buy versus build” products in the portal space. We should expect a build-oriented product such as IBM’s to be more complex as a tradeoff for its flexibility, though other build-oriented portals (e.g., BEA) have not had such issues.

Portal project managers considering WPS should do the following:

• Perform a pilot that verifies desired functionality in detail (i.e., particularly with regard to content management, collaboration integration, single sign-on, and administration ease of use). This pilot should be small enough in scope to permit abandonment, if necessary.
• Check up on customer references for configuration (i.e., operating system and combination of separate packages that need to be integrated such as groupware, single sign-on, and content management). Although we always recommend checking references, we believe this deserves extra attention with WPS, and the focus should be on finding similar configurations over comparable industry references.
• If one of IBM’s content management solutions is being considered (including Aptrix), organizations should go beyond checkbox feature lists and ask how difficult each feature will be to implement (e.g., out of box, non-coding configuration, coding required). The best option is to verify this functionality in the pilot.
• Organizations should not go it alone. They must plan on significant involvement by IGS or a highly experienced WPS SI. We recommend budgeting four to five times the cost of portal software for consulting (i.e., versus two to three times for more out-of-the-box products such as BroadVision, Plumtree, and Vignette).
• If requirements do not warrant the full, large enterprise solution, organizations should consider WebSphere Portal Express. This product has been greatly simplified and has not generated any complaints.
• Ensure a base of J2EE knowledge in the organization before beginning a WPS project. Java coding will be required, and the project will grind to a halt if learning curves are inserted randomly into the project timelines.
• Include three to four weeks in the project schedule for product installation unless a preconfigured image is used.
• Ask for a fixed bid proposal to shift the cost burden for surprises onto the SI. Organizations should note that this will require significantly more specification time upfront (i.e., requirements gathering and specification time should be two to three times what would be allotted in a standard time and materials contract).

Business Impact: Preparing for a WebSphere Portal Server implementation and knowing common pitfalls can avoid failure to meet time and budget expectations.

Bottom Line: Organizations proceeding with a WebSphere Portal Server project should set expectations properly, plan for longer installation times, and budget for significant consulting services.

META Group originally published this article on 10 September 2003.