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.
Bruce, I read your first paragraph and couldn’t agree more!
My read on the TIBCO-Staffware situation was different than yours, but you may have more data than I do. My understanding was, at the time of acquisition in early 2004, staffware was the biggest BPM player on the planet. I was working at Lombardi at the time and we were a small scrappy little company with an astonishingly small # of employees. A well-executed takeover by TIBCO could have been curtains for an up-and-comer in the BPM space. but that competition never materialized.
The rumor mill was telling me that Tibco had an organ donor rejection vis-a-vis staffware and that all the key people were lost in the transition. I also heard that they hit the “reset button” on BPM at TIBCO and essentially started over on the product. So that, rather than making staffware a centerpiece, they rewrote it. Now, as you say, when they position BPM today, they are starting to position it more correctly “on top”, but that was a long slow evolution in my experience – probably learned through some hard knocks. And the goal is still to sell that SOA solution -BPM “on top” is sort of an architectural courtesy, certainly not reflected in the way that they sell into customers, from what I’ve seen so far.
btw, i suspect your thoughts about oracle’s approach to bpm are spot-on. that they are likely to see bpm as a way to make their existing enterprise apps more flexible, rather than a way to really approach the business of business process differently….
(standard caveats should apply: my data points are only a few in comparison with the total # of deals that tibco or oracle has done, and just reflect my assimilation of data in those cases)
Actually the truth about the result of the acquisition is a long way from what you suggest. Like any acquisition, there?s usually an initial period where you have to educate both fields (in our case the TIBCO North American field) on Staffware and BPM, but we addressed that by putting together a SWAT-team from the ex-Staffware side of the house and are now executing very successfully. I think the main reason you weren?t seeing TIBCO as much is that we primarily sell into the Global 2000. We don?t see Lombardi that much in these deals, especially for larger projects involving mission-critical business processes with BPM and SOA. That could be in part due to Lombardi?s size or a focus on smaller projects.
In terms of the product and people; again no organ-donation rejection there. The core BPM IP of product strategy, product management and product engineering is still very much in the hands of the UK-based team that were acquired by TIBCO. I myself, as Director of BPM Product Strategy for TIBCO, am ex-Staffware and based in the UK; as is the BPM Suite Product Manager and the VP of BPM Engineering, who is an ex-Staffware PLC board member. The vast majority of the current BPM engineering and support organization are people who were acquired and a great many of the ex-Staffware worldwide field organization are still around.
The product has under-gone a very significant investment under TIBCO ownership; particularly on the Process Modeling and Implementation side. Business Studio, the cornerstone of our TIBCO ONE strategy to integrate all our key IDEs (SOA, BPM, Rules, etc..) within an Eclipse-based environment, in fact started life within the UK-based BPM team and the BPM team were the first to complete their migration to Eclipse. You can be assured that the BPM market and our competitors will see many, many more interesting and unique developments coming from this focussed investment in BPM by TIBCO over the coming years.
As for the demand for BPM, there continue to be many independent BPM deals. We did start doing more BPM+SOA projects after the acquisition, and companies are clearly starting to realize that BPM+SOA is the right approach for BPM implementations where integration is needed. But these deals are driven more by business reasons and the needs of BPM, not by SOA; but it is, of course, nice to have the market?s #1 SOA infrastructure in your back pocket to solve those inevitable messy integration problems that the pure-plays just love to ignore!
[…] View full post on Yahoo! Search: Oracle BPM […]