IBM's BPMS Endgame

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:

  1. 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.
  2. Develop separate BPMN 2.0 engines for Process Designer and Integration Designer, with some common code.
  3. 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.