Oracle’s been taking a bit of a beating lately, with Gartner stating that their middleware suites are “assemblies of convenience”, and that they are unlikely to offer any surprising innovations in the short term as they’re attempting to resolve the overlap and incompatibilities between the Oracle and BEA product lines. Gartner’s saying “watch this space”, but some of Oracle’s competitors are interpreting that as “they’ve got a big bunch of SOA stuff they have to integrate, and you know it’s going to hurt, so delay the pain”.
I discussed Oracle’s Borg-like acquisition of BEA back in June, and Bruce Silver recently agreed that Oracle knows how to do acquisitions right, and discussed the Oracle middleware product strategy outlined at Open World last month.
I did a review of the product strategy in early days shortly after the acquisition, then had a chance to attend an in-person briefing more recently at an BEA “customer welcome day” in Toronto along with about 120 attendees, with Mason Ng of Oracle as the main speaker. This followed the same lines as the web briefing that I’ve already written about, with the products marked in red for “strategic” (immediate adoption, minor redesign), blue for “continue and converge” (limited development, converge/merge with another product, 9-year support cycle), and white for “maintenance” (end of life). The AquaLogic brand is being discontinued, but not (necessarily) the products; other brands, such as WebLogic, are being maintained for their marketing value.
There were some misleading comments from Ng: he stated that BPMN is for human-centric workflow BPM and BPEL is for system-centric BPM, which certainly planted the wrong message about BPMN (a graphical notation) and BPEL (a serialization/execution language) in the minds of anyone in the audience who didn’t already have an opinion on this. I’m not sure if he doesn’t get it, or he wanted to create a reason for why multiple BPM products are required, but he positioned BPMN and BPEL as competing standards in his presentation; I think that he’s really talking about XPDL, since AL-BPM natively executes XPDL from the BPMN serialization.
Some mysteries remain, such as how Oracle ESB and AquaLogic Service Bus can both be considered strategic, when they are being merged into a single product, Oracle Service Bus. Realistically, both original products will be modified significantly to create OSB, but it was stated that AL-SB will be the core, with features from O-ESB rolled in. Good news for AL-SB customers, not so much for O-ESB customers. Ditto with Oracle BPM, which will be a merging of AL-BPM and Oracle BPEL Process Manager: both of the constituent products are considered “strategic” (which is supposed to mean “minor redesign” only), but they stated that the core will be AL-BPM with BPEL capabilities rolled into a single engine, which will mean major changes to Oracle BPEL Process Manager and, most likely, AL-BPM in order to create the merged product.
The attendees at this event were primarily BEA customers, which means fairly deep inside the IT organization, and not necessarily innovators. I saw a lot more old Blackberries than new iPhones. And in this conservative development environment, there’s a big perception problem as well: Oracle positions the 9 years of support for the blue products as being incredibly long, but organizations starting out on 5-year development projects (as was one audience member) see that as being just around the corner, and likely to be biting them just as they’re rolling out the last bits of the project. There’s the bigger question of why anyone is planning a 5-year portal development project, but when the guy beside me admitted that 50% of their desktops are still on Windows 2000, I started to see the gap between the starry-eyed vendors and the reality of the slow pace of enterprise development.
At the end, we had the obligatory appearance of the regional sales team — 5 white guys in suits — stating that “nothing has changed” and “it will be a good thing in the end”. In other words, resistance is futile.
Hi, Sandy.
For us, it’s pretty simple: there’s no reason — none — that creating services-based applications has to be this hard. I’ll bet Oracle customers get a headache just thinking about what this combination or that permutation could be.
If Oracle is taking a beating, it’s not due to the slow pace of enterprise development. Instead, it’s because no customer — even their current ones — should be expected to engineer Oracle piece parts together into coherent products by themselves in their own shop. And that’s precisely what Oracle is forcing them to do, because everyone knows this fundamental truth about commercial software development: what was designed as a separate product remains a separate product, even when you smash it together with some glue or UI.
Interesting that the analysts are taking a “wait and see” attitude about Oracle — they don’t want to be naysayers about the big O, but they’re really not sure how all this confusion is going to go down in the marketplace. I completely agree with you, Oracle has made this much to complex.