Anyone interested in the history of business process management (BPM) technology (brief as it is) should not miss Ismael Ghalimi's recounting of it, "Why All This Matters." As a seminal figure in that history, Ghalimi's discussion of the relationship between BPMN and BPEL, the two important standards in BPM, is especially notable. Neither standard is perfect. But while BPMN has succeeded in the BPMS world in spite of its shortcomings, BPEL's shortcomings have largely confined it to the SOA/integration space, where "business-empowerment" does not have especially high priority. And in spite of the fact that BPEL was originally conceived by IBM and Microsoft as an Intalio/BPML-killer - Ismael does not say that directly, but I will - his post insists that BPEL remains central to BPM's (and Intalio's) larger mission.The context for this history is a geeky article and comment thread on infoQ that generally mocks Ismael's continued fixation on BPEL. Unlike the stacker-bashing posts that appear periodically from the BPMS pureplays worried about IBM and Oracle entering their turf, this one is technical, interesting here and there, but I think mostly beside the point. And Ismael's own post fails to address the question why BPMN has succeeded in the marketplace while BPEL has not. (He basically characterizes non-BPEL vendors as stuck in some benighted workflow past, but that doesn't explain why, for example, both SAP and Oracle are moving to "native" BPMN engines for BPM and edging BPEL into the SOA/integration box.)

Here's my take on it. The original goal of BPMN, as the design surface for BPML (and later, in Intalio's case, for BPEL), was business-empowerment. With BPMN the process model would no longer be just a "business requirements" sketch but - with implementation attributes added by IT - a diagrammatic representation of the executable solution. This idea is still twisted and mocked by many in the developer and enterprise architecture community, but it is in fact BPM's "winning idea."

Even though they need training to use it effectively, business analysts find BPMN's notation familiar and comfortable. A key reason for that is it is graph-oriented like a flowchart, not block-oriented like a structured program, or more to the point, like BPEL. For example, you can loop back to some previous step with a BPMN gateway, but BPEL places severe restrictions on that. What that means is you can draw BPMN diagrams that cannot be mapped to BPEL, or at least to "roundtrippable" BPEL that preserves the BPMN view after even minimal tweaking in the BPEL environment.

It's a square peg in a round hole. Vendors have tried to address it mostly by restricting the BPMN you can draw to block structures supported by BPEL - gateway branches must rejoin, no arbitrary loopbacks, restrictions on exception flows from attached events, etc. Really smart tools impose fewer restrictions than dumber tools, but they all have some. So the question becomes, is this still BPMN or a graphical BPEL designer? On this point, the marketplace has mostly voted that such restrictions make it less usable by business.

On the other hand, BPEL provides something that BPMN does not, which is standardized semantics. The issue is frequently mischaracterized as BPMN semantics being "vague." In most cases they are not vague at all. The problem is they are not required to be implemented by a BPMN-"compliant" engine. Attached events? Event gateways? Oh yeah, we don't support those. Or, as the vendors would put it, "our customers haven't told us those are a high priority." Ridiculous! With BPEL you don't have that luxury. You can add extra stuff, but if you don't support the semantics in the spec you're not BPEL. Period.

So it's a stalemate for now. But it could change if OMG, and in particular the BPEL backers in OMG, wanted it to. OMG could define a compliance spec for BPMN 2.0 - the elements, attributes, and flow patterns that MUST be supported to claim BPMN support. They have made some murky noises about it, but I haven't seen anything concrete yet. Since IBM and Oracle are driving the bus there, it would make sense that that subset would have a defined mapping to BPEL, but it would allow non-BPEL engines to be compliant as well.

That would be a healthy thing for the industry. But I'm not holding my breath.Anyone interested in the history of business process management (BPM) technology should not miss Ismael Ghalimi's discussion of the relationship between BPMN and BPEL, the two important standards in BPM. Neither standard is perfect. But while BPMN has succeeded in spite of its shortcomings, BPEL's shortcomings have largely confined it to the SOA/integration space, where "business-empowerment" does not have especially high priority.