How Many Portals Should a Vendor Offer?

May 18, 2007 at 9:10 am | Posted in BEA, Oracle, portals | 2 Comments

I’ve often been asked how many portals a corporation should have (see my posting on “Portal Factories” for my answer to that one). But today the issue of how many portals a vendor should offer came into clear focus. Oracle and BEA both have two and, at least publicly, still insist that’s an OK answer. I disagree, as a conversation with a client today put into focus for me.

So what justification is given?

Let’s start with Oracle. The official word in the Oracle press release was

The WebCenter Framework will support portal and content integration standards including JSR 168, JSR 170 and WSRP 2.0 and will inter-operate with standards-based portals including Oracle Portal.

More recently, Peter Moskovits at Oracle said in InfoWorld

Peter Moskovits, product manager for WebCenter, replied that Oracle Portal and WebCenter Suite would coexist at least “for the foreseeable future.”

Now on to BEA. They made similar statements when they acquired Plumtree

Because the two portals target fundamentally different aspects of the enterprise, BEA officials said the company plans to keep the Plumtree and BEA portal product lines separate.

WebLogic Portal targets companies using transactional portals in a J2EE application development environment, according to Mark Carges, BEA’s CTO and executive vice president., Plumtree’s portal is designed for business users in a collaborative workgroup setting,

“We are keeping both [BEA and Plumtree products] as two separate portal product lines for as long as we can see,” he said. “Each product is a leader in its own right.”

Last year, BEA CEO Alfred Chuang reiterated their commitment to the parallel path, with an honest nod to the challenges

“We could integrate them but some companies are buying both, and nobody’s bitching. Yes, it would be much cleaner if we only had one product to support but at the moment I can sell some customers both – I’m trying to sell everyone who has one the other, and it’s going well.”

The justification in both cases is that one product is more developer focused and the other more user-focused (collaboration, intranet). There may indeed be different segments, but then the correct engineering response is to create a unified infrastructure platform that serves up JSR 168 portlets, WSRP, has identity management hooks, administration screens, delegated administration, and personalization capabilities and then offer different layers and packages on top of that to meet market needs. I suspect at some point BEA and Oracle will have to do that by establishing the core of one of their products to be the underlying infrastructure and keeping the other product as a different skin or layer that is productized on top of it.

Parallel paths just don’t work. Unlike consumer packaged goods, where Proctor & Gamble can gain marketshare by offering Tide, Gain, Cheer, etc. , buyers of complex technological products like portals expect their vendor to dedicate significant resources to keeping it up to date and supporting it. This is difficult with a parallel path. Granted, neither BEA nor Oracle have shown strain at supporting both yet (although Chaung’s statement above hints at that), but I believe it will start eating away at expenses over time. IBM is just extricating itself from the confusion caused in the Notes/Domino world over its parallel path strategy and has gotten kudos all around for offering a unified vision.

Sure, integration is difficult but it’s worth an effort. Vignette did not try to maintain parallel paths when buying Epicentric back in 2002 and went with Epicentric. All is not going swimmingly for Vignette at the moment, but competition in the market and not selection of a single path is the cause of that.