The Future of BPM at BEA/Oracle

I see my friend Jesper is moving on from BEA, so the reality of the Oracle acquisition is finally sinking in. When I hear people say that Oracle bought BEA for their BPM, I have to laugh. I'm fairly confident the Oracle crew that went after BEA could not even spell BPM. But no doubt the two BPMSs will have to be merged or rationalized somehow into a single primary offering (although IBM/FileNet provides an example of how that can be dragged out for years). I don't actually know what Oracle's plans are, and they haven't solicited my opinion - you can be sure that if they had, I would not be writing about it. But I have thought a bit about what they ought to do.Since TIBCO-Staffware and BEA-Fuego, both of which seemed crazy to me at the time, I've had a change of heart about consolidation in the BPMS business. At the time of those acquisitions, integration middleware vendors had one view of what BPM is - essentially a business wrapper around SOA - and workflow vendors plus the BPM pureplays had different one, focused on improving "work" and optimizing business performance. And it was not clear which vision would prevail. The middleware vendors were certainly bigger companies with more cash and resources, and in the software industry bigger usually wins.

But TIBCO and BEA, confounding my own expectations, did not embed their acquisitions as a human workflow subcomponent underneath their existing integration-oriented suite, but instead made the acquired company the centerpiece of their BPM offering. In fact SOA, the bigger business at both TIBCO and BEA, became the sub-component, with BPM at the top.

And that was smart, smarter than I was at the time for sure, because the energy in the BPM market has proved to be definitely on the human-centric side, with an emphasis on improving human work in the organization and empowering business to play a more direct role in the implementation. The way the acquisitions were handled allowed both TIBCO and BEA to understand that BPM and SOA are not just different brochures for the same product offering, but different things entirely, and require explicit links between them. It's taken a while to build those links - in fact, they are just rolling out for real this year for the first time in both TIBCO iProcess and BEA ALBPM. In contrast, IBM and Oracle, who continue to embed human workflow as a subcomponent of an overall integration-centric offering, still struggle with the boundary between BPM and SOA.

So what does this say about what should happen now with Oracle-BEA?

First, a couple points about the two existing BPMS offerings. Oracle uses BPMN modeling in an OEM version of IDS Scheer ARIS (extended with some Oracle-specific configuration dialogs for human tasks, business rules, and notifications) to generate skeleton BPEL that is fleshed out in the SOA Suite design tool. There is a simplified BPEL outline called Blueprint intended to serve as a diagram shared by business and IT to eliminate the roundtripping problem, but it's not as clean as a true BPMN-based design. ALBPM uses a common graphical notation for the process model and the implementation design. In version 6.1, that notation has been made (mostly) BPMN-compliant. I think this is the right way to do it, so on this point score one for ALBPM.

Oracle follows the BPEL paradigm in which the process does not actually perform activities itself but instead invokes services that perform the activities, and those services are defined outside of BPM, e.g. coded in Java and exposed as services in the SOA registry/repository. Or, in the case of human tasks, defined in the BPM environment, but deployed and managed as separate objects independent of the processes that use them. ALBPM follows the more normal BPM pattern in which activity implementations are defined and used within the BPM environment itself. If services are created in SOA and exposed in the registry/repository, ALBPM can bind to those, but it's not the only way to do it. In a SOA-based production environment, both BPMSs get you to the same place, but it's easier to do rapid iterative BPM development and deployment the ALBPM way.

So, if Oracle's goal is to maximize success in the "straight" BPM market, making ALBPM the environment for both modeling (replacing ARIS) and end-to-end implementation makes the most sense, moving SOA Suite (BPEL) down to the SOA layer and replacing the links to AquaLogic SOA components with links to their Oracle Fusion counterparts.

But it's not at all clear that the straight BPM market is Oracle's objective. Like SAP, Oracle tends to view BPM primarily as a platform for transforming their enterprise applications from old-style monoliths to composable services. The BPMS developers, I'm sure, would like to make their product a good fit for both the straight BPM market and their own apps business, but that is hard to do. For example, one reason for separating human tasks from BPM is to support the apps business. Also, a reason for hanging on to ARIS, despite the clumsy integration with implementation, is that it provides prebuilt reference models for the apps.

It is possible that Oracle could adopt an IBM-like strategy and keep both threads alive until things sort out, using ALBPM on top of Fusion as the straight BPMS offering, and the current ARIS+SOA Suite to support the apps business. In some ways that's the path of least resistance, anyway, so I suspect that's what will happen.When I hear people say that Oracle bought BEA for its business process management suite, I have to laugh. I'm fairly confident the Oracle crew that went after BEA could not even spell BPM. But no doubt the two BPMSs will have to be merged into a single offering... I don't know what Oracle's plans are... but I have thought a bit about what they ought to do.