Reframing the BPMN vs BPEL Debate

Haven't we beaten this to death yet? Apparently not, if Keith Swenson and Boris Lublinsky have anything to say about it. The discussion is leading nowhere. Boris inadvertently sums up the pointlessness of it in his conclusion:

The confusion about BPEL and BPM in general seems to keep growing in the industry. There is still no agreement on the most basic BPM issues:
  • Is BPM a business Discipline or software engineering?
  • Whose responsibility is it to implement (automate) a business process?
  • Should we aim to move from design to deployment with no programming?
  • Whose responsibility is it to maintain a business process?
Only by getting agreement on these issues will allow us to frame BPEL discussion and the whole BPMN/BPEL relationship discussion correctly.
No, Boris. We will never get agreement on these issues. It is impossible. If standards like BPMN and BPEL are to have value, that value must assume a BPM community where there is no agreement on these things.

So let's reframe the discussion. Imagine a new version of BPMN. Let's call it, for argument's sake, BPMN 2.0. It adds new elements that allow, for example, fault and compensation handling more compatible with BPEL. It elevates data to first-class status and provides BPEL-like assignment and manipulation. In fact anything you would need to execute the model would be provided in BPMN-standard attributes. It would even provide an optional "compatibility mode" where one or two flow topologies incompatible with BPEL, such as arbitrary loopbacks, could be excluded from the diagrams. If you looked at the XML representation you would call it BPEL-like, except that the constructs are BPMN elements and they match the diagram. And let's say further that you wouldn't have to populate all this implementation detail, but you could if you wanted to.

Now, the question is, would you want this? The hypothetical BPMN 2.0 team imagines that you would. If I were a BPEL-based BPMS, I certainly would, if only to make BPEL relevant to the BPM community. But if I were a non-BPEL BPMN-based BPMS - like Appian, Adobe, Cordys, Fujitsu, Lombardi, Savvion, Singularity, SoftwareAG, Tibco, or Vitria - would I want this? I have my suspicions but I don't really know. It addresses Keith's basic objection to BPEL, since now the picture is indeed the process. But in a way it commoditizes the runtime, which only favors the "stackers" and open source guys.

It's time to stop beating the dead horse, when there is a new one very much alive and kicking.