Oracle to BEA Customers: No Surprise Here

Oracle finally placed its cards down on the table regarding its roadmap for BEA products, and for the most part there’s little surprise. As Gavin Clarke reported several weeks ago, Oracle will be deconstructing AquaLogic. But taking a cue from its Applications Unlimited Strategy, Oracle is telling BEA customers that it will support all existing BEA products, regardless of whether they wind up on maintenance.

Cut to the chase, Oracle’s choices for strategic products going forward are not exactly a shock. WebLogic Server, until a few years ago the leader in the space, is going to be Oracle’s Java middle tier going forward. It wasn’t until Oracle 11g that, in Larry Ellison’s words, it finally got the appserver right. So it’s obviously going with the more established offering. Tools are another story: Oracle claims to be the second largest contributor to Eclipse, yet it continues to spurn the IDE on which the Eclipse Foundation was founded. Instead Oracle focused its efforts on EclipseLink, the implementation of JPA that it donated to Eclipse.

While Oracle has been schizoid in its Eclipse strategy, BEA was schizoid on tools in general. Originally embracing a VB-like approach with the original WebLogic Workshop, BEA later forsook the technology following acquisition of an Eclipse-based successor, throwing its installed base into a confusing migration strategy. No question here as to which way Oracle is going.

In other areas, Oracle’s roadmap is a case of seasoning its Fusion portfolio with BEA pieces where they fill gaps. That includes AquaLogic Service Bus, which now gets fortified with Oracle’s service composition fabric that comprises its implementation of the proposed SCA standard. Ditto for SOA governance, where AquaLogic Repository fills a gap, and where both relied on OEM bundles with Systinet for the UDDI service registry. And the same goes for entitlements, a BEA technology that will be added to Oracle’s Access Management suite. As for BPM, BEA’s AquaLogic offering –the former Fuego product – provides the middle ground for business unit level implementation that complements the top-down of its existing bundled offering from IDS Scheer. While BEA/Fuego customers liked the degree of control that their tool provided, under Oracle they are going to have to give up the run time to Oracle’s BPEL Process manager. Call that a case of realpolitik.

In a deal this size, there are always going to be a myriad of details as to which product features make the cut and which don’t. With Oracle’s previous large acquisitions (read: PeopleSoft, Siebel), there has been little question about which application is the strategic one going forward. In spite of Larry Ellison’s early posturing, it was never about sunsetting a particular ERP or CRM package because customers are not going to make forklift migrations. Middleware is another story because of the predominance of standards; migrations are painful, but nothing compared to dumping your ERP system. And thanks to de facto standards, and more importantly, open source, tooling is fungible.

Unless the viability of a company is in question, most customers don’t like to see their vendors get acquired as they often fear getting lost in a larger fishbowl. It’s even more the case with Oracle, whose past bravado, aggressive sales force, and high pricing have turned customers off. SearchSOA’s Michael Meehan cites results of a BEA customer poll that his group conducted last week, and the results aren’t exactly shocking: most BEA customers were happy with the way things were and aren’t looking forward to life with Oracle. So it’s not surprising that one of the points that Oracle emphasized in its presentation is that BEA pricing would remain grandfathered in for existing customers. The die was cast back in 2003 when Charles Phillips backtracked from Larry Ellison;s posturing about wiping PeopleSoft apps off the planet with what eventually became the Applications Unlimited policy. No matter, Oracle still faces living down its reputation as it cries all the way to the bank.

But back to product roadmaps, Oracle’s strategy for BEA products is a conservative one – not simply from the decision to continue supporting even obsolete products, but rather, that it has not been as fast on the draw with new technologies as was BEA. That explains BEA’s earlier embrace of OSGi, but the flip side of bear hugging the new and trendy explains why it has never had a consistent tooling story while Oracle’s, love it or hate it, has.