KnowledgeForward

ZDNet writes today that Oracle is making a bid for BEA for the demonic price of $6.66 billion. Well, the devil is in the details and there are plenty of them to hash out if this deal ever flies. There is a large degree of overlap in the application server, development tool, collaboration, and portal spaces between BEA and Oracle. At least BEA doesn’t have a content management offering too, so Stellent is safe for now. I find it rather ironic that after writing in May about “How Many Portals Should a Vendor Offer?” that both Oracle and BEA have two sets of portal products on offer, now Oracle could have four (4!) portal products in its portfolio. I’d love to be a fly on the wall as they try to rationalize that one!

There have been rumors of Oracle (or others) buying BEA for quite a while, but it hasn’t happened yet. For example, in May of 2004, Java.net reported “Faced with a tough, if not losing, battle for PeopleSoft, Oracle executives said Thursday that they were considering other acquisitions… Henley (CFO, Chairman) said Oracle had been ‘looking at a variety of areas’ but didn’t identify any potential takeover targets. It has expressed interest in BEA as well as reserve over the price.” Of course BEA was trading at about $8.00 a share in mid-2004 versus $18.05 at the moment.

Time will tell if this deal shall come to pass. It is not for me to judge the will of Carl Icahn, who has reportedly been pushing for a sale for quite some time now. This simply shows that Oracle is continuing to seek growth through acquisition and that BEA has been undervalued, which should came as no revelation to anyone.

In my previous posting on How Many Portals Should a Vendor Offer I talked about how both Oracle and BEA have dual portal strategies. Since then I had a conversation with Shane Pearson of BEA on this topic. I still stand by my posting, but Shane did point out that BEA is dedicated to maintaining 2 SKUs. This means they are dedicated to 2 purchasable products to meet different needs. They are moving forward over time to unify the infrastructure underneath them and new add-ons will likely support both.

To clarify my posting, I don’t think BEA has done anything wrong. There’s no magic wand that can be waved when an acquisition occurs to instantly rationalize all the personnel, products, and technologies and integrate everything. My point is twofold:

1. A roadmap should be forthcoming from a vendor within a short time after an acquisition (about 3 to 4 months) to reassure existing and imminent customers that their current path will continue or let them know frankly that a product or technology will no longer be supported so they can plan for migration or another purchase. No one wants to be the last one to buy a product before it is discontinued.

2. It is my opinion that, as a buyer’s advocate, software purchasers should be aware that as much as a vendor tries to make redundant services (caused by dual path strategies) under the covers transpearant, cracks start to form over time. These cracks are caused by fragmentation and take the form of higher costs (more specifically, costs that don’t decrease over time as quickly as market pressures encourage), higher risk that a piece of redundant infrastructure that a user is dependant on will be eliminated, slightly lower support costs (especially as one set of infrastructure becomes more rare in the marketplace), and slightly more difficulty finding consulting and integration services. I don’t know for sure that BEA will encounter this issue, but it is the norm and provides a reason for customers to be pessimistic in the long run.

I ran a breakfast roundtable here at the SharedInsights Portal, Collaboration, and Content conference this morning and found it to be quite enjoyable and enlightening (despite the hotel dragging away the coffee and tea service too quickly…). The table had about a dozen attendees, mostly architects, and was a good cross section of portal implementations. A large food franchise, a few large government agencies, a major retailer, a vendor (not a portal vendor), a real estate firm, and an international utility were represented.

The primary issue they were all faced turned out to be integrating service oriented architecture (SOA) concepts into their portal environments. Point goes to Plumtree a few years ago who dedicated themselves to the “enterprise service bus” concept. Portals were originally created as “Swiss army knives” that could connect and adapt to all sorts of identity management, security, content management, and application products. It seems that need is still prevalent. Unfortunately, the vendors have been slipping into the mode of integrating the portals into their infrastructure stacks and playing favorites by connecting to their own infrastructure first and then allowing a standards based connector to everything else (blaming it on the other vendors if they can’t take advantage of JSR 170, JSR 168, LDAP, etc.).

It was interesting that while the momentum is certainly in favor of Microsoft and IBM right now, none of the people at the table reported using them as their main portal. Instead it was BEA, Vignette, and a few Oracle. One was interested in open source as well. The table felt that the reason is that legacy environments are not going away, particularly for content management and portal. While many vendors can show a nice, unified stack now, that doesn’t help the practical reality that organizations face with the large amount of built up legacy infrastructure. Governance is a key success factor then in getting each part of the organization to agree to corporate standards even if it is a little less useful for them. Optimizing enterprise-wide sometimes means a sub-optimal environment for those that heavily use another app that offers a portal.

Workflow was also important to the attendees. A few had workflow/BPM tools they wanted to hook up to the portal such as TIBCO and Ultimus, while others were interested in the more simple capabilities you get out of a portal itself.

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.