Portal Battles Create Customer Conflict

When we wrote about the portal framework as the “Battle for the Enterprise Desktop” back in spring 2002, we were referring to clashing vendors that saw the portal as at once an opportunity and a threat to their business. Now enterprises are suffering the collateral damage as their constituents clash over portal standards.

The Bottom Line: For most companies, the notion of a unified portal framework is a worthy goal, but a single-vendor portal framework is impossible until standards mature and are wholeheartedly adopted.

What It Means: Lately, relatively few of our conversations with enterprises are about choosing a new portal product or vendor. More often, we’re mediating disputes over whether companies should standardize on a portal, and if so, upon which portal to standardize. Too often, the interaction is with either Information Technology (IT) or business owners trying to justify their notion of the portal and their vendor preference.

It typically goes like this:

• IT executives argue that their versatile, infrastructure-oriented portal framework is the only way they can serve the various needs of the business.
• Business executives argue that they can’t wait for IT to build or integrate the specific features that their application vendor offers now.

Both arguments are sound and valid. But in the meantime, the most prominent problem with portal implementation is lack of adoption by the mass of information workers and other constituencies that measure the portal’s success. The problem: neither the IT notion nor the business notion of the portal appeals to them.

A battle worth fighting?

AMR Research told the unified portal framework story in 2001, and we’re sticking to it. Whether that means a single-vendor portal framework is a different question. In fact, for most businesses, it’s simply not possible now.

This is largely because of a failure on the part of many vendors to cooperate, which is only understandable given their intense interest in retaining account control and owning the enterprise desktop.

The following are the some of the suspects at the center of the conflict:

• SAP--The best, most efficient way to Web-enable a range of SAP applications is with SAP Enterprise Portal. Newer and updated SAP applications, in fact, rely on the portal and NetWeaver as their next-generation architecture.
• PeopleSoft--Typically in place when companies start internal portal initiatives with HR processes, PeopleSoft is part of a prominent adoption pattern.
• Oracle--It includes its portal as part of the 9iAS platform, which leads to a similar dynamic as the one with SAP and PeopleSoft.
• Microsoft--Microsoft’s SharePoint is appealing as an extension of Microsoft Office and Outlook and as a foundation for its own enterprise applications.
• Established Portal Vendors--Often, a portal framework from the likes of Plumtree, Vignette, IBM, or BEA is already in place.
• Niche Application Vendors--Many more specific application vendors, often Business Intelligence (BI) vendors and Customer Relationship Management (CRM) vendors, offer a fairly versatile portal as a Web user interface.

All of the above have good, versatile, proven products now, and all of them, at some level, participate in standards efforts like, JSR 168 and WSRP.

But when standards threaten to commoditize vendors or compromise their ability to retain account ownership, they will resist adopting them, or they will build so much “value-added” capability atop them that they will negate the standards’ value.

Products reach parity--depending on the audience

Broadly speaking, portal frameworks were relatively close when we did our product evaluation two years ago; they’re much closer now in terms of functionality and scalability. But they are clearly not equal for every audience.

To explain: We talk to many enterprise vendors that “listen to their customers,” and “know what their customers want” when it comes to portals. And the various vendors’ customers seem to want different things. And then we see that their customers--in terms of corporate logos at least--are the same customers as their competitors’ customers.

Their customers are different people in different positions--CIOs, IT architects, IT developers, business executives in various roles--within enterprises. Portal vendors must appeal to their existing, specific customers, each of which have entirely different perceptions of what a portal is or should be. For some, a portal is an architecture; for others, a portal is a dashboard; for others still, a portal is a platform for relationship management, or collaboration, or search, or knowledge management.

No market is quite so challenging for vendors as the portal market. And as a consequence, few initiatives are quite so challenging or cause so much conflict as the enterprise portal framework. So many people in so many various levels and roles are critical to an enterprise portal framework success.

Recommendations: When choosing portal frameworks, downplay feature-function in favor of the following:

• For business people--IT cannot serve the business efficiently unless it imposes and enforces portal framework standards.
• For IT people--business users cannot wait for a bureaucratic process to prioritize, approve, or build new capability. Build portal frameworks with flexibility--within certain constraints around governance, security, and development standards--and then allow business users to serve themselves.
• Skip “vision” and think about vendor interests and motivations. Who have they been serving, and who are they likely to serve most readily in the future? How well do their interests and motivations align with yours over the next five years?
• Speaking of five years, count out vendors unlikely to be in your business vertical in five years. Enterprise portals are evolving, long-term programs. The big vendors are in it for good.

AMR Research originally published this article on 25 March 2004.