Oracle and BEA: A Day of Reckoning for Portal Implementers

Blogger: Craig Roth

The WSJ.com reports today that

• Oracle succeeded yesterday in forging an $8.5 billion deal to acquire rival BEA Systems Inc., a maker of programs known as middleware that had resisted an unsolicited bid from Oracle in October. The $19.38-per-share price is about 14% higher than Oracle originally offered, but below the $21 figure that BEA sought.

Despite Alfred Chuang's statement during the analyst call that "our two businesses are a natural strategic fit", I would say that their two businesses are instead natural competitors for much of what BEA offers.

In particular, portal buyers have reason to be dismayed. As I wrote in The Four Portals of the Apocalypse back in October, both Oracle and BEA offer two overlapping portal products. I don't buy the argument that they are meant for different audiences. It is true that different products may serve certain audiences better, but slicing a market into segments like that would require building products with those segments in mind and all four products were built from the ground up to do their best at meeting a broad set of needs even if they were strongest in one area (like BEA Portal for infrastructure developers or Oracle WebCenter for Web 2.0). This acquisition puts enterprises that have any of these four portal products in production or has need for a portal product to be purchased within the next year into a state of limbo.

Here's my initial handicapping of the portal options (not based on any inside information):

BEA AquaLogic User Interaction: Still perhaps the strongest pure portal product of the bunch, but getting a bit long in the tooth as trends have moved to Web 2.0. I don't see this disappearing anytime soon due to its install base, but Oracle may just raid it for piece parts (e.g., the service bus, collaboration server, portlets) and it would not get marketing push for expansion.

BEA WebLogic Portal: I think this product is more likely to suffer a quick decline. For current owners of the product, they will get some relief from the fact that BEA Portal is very standards compliant and it's infrastructure-like nature may mean that applications built on top of it could port with some effort to another Java-based platform.

Oracle Portal: Oracle Portal is in the same boat as BEA Portal. It's the "old" portal at a company that has something shinier and sexier in WebCenter. It would probably have been eliminated by now if it wasn't for a good install base (the full extent of which is not known since the product is kind of "free" and isn't licensed individually).

Oracle WebCenter: This may be the winner of the bunch and the foundation upon which piece parts from the other 3 portal products can be attached. It provides a modern, web 2.0 foundation.

It's impossible to know for sure which portal products will be eliminated and when. I believe that, long term, it is possible to sustain at best two portal products (if significant architectural work is done to shape them for their constituencies). So by that logic, 50% of these products will cease getting much new funding and eventually stagnate. That's equal to flipping a coin for any current or potential implementers of these solutions, something that these folks are unlikely to enjoy doing for a major infrastructure commitment.

My advice continues to be to isolate the product specifics as much as possible during implementation. This means:

• Leveraging external products for collaboration, content management, workflow, and analytics that can easily integrate into the current portal or any of the others you may choose. For the BEA+Oracle list, this means Java-based portals. Not only will the implementer gain best-of-breed functionality, but in the event the portal platform changes the repositories, metadata, and other setup will not need to go through a painful migration
• Building web services with thin, standards-based portal shims on top. Sorting through portlets coded with portal-specific APIs will be a nightmare if the portal platform changes. JSR168 (and JSR 286)-based portlets or WSRP can help create portable portlets, but the best option is to put as much code as possible into web services. All these platforms provide ways to perform discovery on a web service by scraping the WSDL and helping to quickly generate a portlet to access it. Not only is this highly portable (only the re-creation of the portlets would need to be repeated), but this opens up access to applications other than the portal that may want to access the information.

With this architectural guidance (and a little luck), owners of one of these four portals can get through the transition with minimal damage.