Clay (Coat o’Paint) Richardson and I have agreed to disagree about whether IBM Business Process Manager’s having two process engines is a bad thing (sez he) or a don’t-care (sez I). In the analyst session at Impact today, it wasn’t really clear if the two-engine approach is the long-term answer or just all they can do for now. I don’t think it matters all that much, but Clay got me thinking about where they “should” be going. And it didn’t take me long to remember that neither engine today is BPMN 2.0-enabled, so they need to update the process engine plumbing in any case.
Even though Judy Huber just about bit my head off last year when I asked her when BPMN 2.0 support was coming, I’m pretty sure that that was the plan for WPS 8.0 before the Lombardi deal happened. So let’s speculate. The longterm options would seem to be these:
- Freeze the BPEL engine at the current level (except for cloud- and other infrastructure-related enhancements) and focus BPMN 2.0 work on a single engine that works with Process Designer 8,0.
- Develop separate BPMN 2.0 engines for Process Designer and Integration Designer, with some common code.
- Develop a single BPMN 2.0 engine that works with both Process Designer and Integration Designer.
Of these, option 1 seems the most logical. Developers who love WID today would see little upside in moving from BPEL to BPMN 2.0, and matching WPS transactional process support in the BPMN 2.0 engine might take some time. Option 1 also would let IBM get it done in the 8.0 timeframe, while option 3 might not. Option 2 might be a path of least resistance, but seems a waste of effort. Once the BPMN 2.0 engine is made fully SOA-enabled and transactional, the BPEL engine could be left to wither — I think that’s Clay’s preference — but option 1 would allow two or three years to get to that point. I guess that’s what I think will happen.
Well that’s all very straightforward compared to the IBM/Rational endgame on UML tools. There are so many renamings and rebrandings of their three or more seprate offerings in the UML space that I can’t work out what’s what.
|<
[…] The good news is that Lombardi in technology and product has remained alive and well. We’ll characterize IBM Business Process Manager 7.5 as Lombardi giving IBM’s BPM suite a heart transplant; it dropped in a new engine to reinvigorate the old. As for the peanut gallery, Janelle Hill characterized it as IBM getting a Lombardotomy; Neil Ward-Dutton and Sandy Kemsley described it as a reverse takeover; Ward-Dutton debated Clay Richardson that the new release was more than just a new paint job, while Bruce Silver assessed it as IBM’s BPM endgame. […]
I still think BPEL is more suitable for Integration Designer.
What do you think about option 4, the Integration Designer continues to use BPEL and on deployment the BPEL code gets converted to BPMN 2.0 and executed by BPMN engine.
Also, since the Process Server users will continue to see the familiar BPEL designer, this should be the less resistant option too.
Yugesh,
Good idea, but I think this is the same as option 3. The issue is that BPEL engine (actually BPEL+, because they added BPMN-like constructs such as collaboration scopes already) is transactional, and Lombardi BPMN (1.x) engine is not. A better way of framing the question is which code-base will underlie the BPMN 2.0 engine – Lombardi (shared-model, instant playback, etc) or WPS (not-shared model, not-instant playback, but transactional)? Option 1 is Lombardi-only; option 2 is both, separate engines; option 3 is they merge the two. So I think you are saying option 3.
–Bruce
Will Oracle BPA support full BPMN 2.0 and its conversion into BPEL 2.0 in new releases ? Or is it better to use BPM systems that directly execute BPMN?
Andrew