Does BPMN Belong to BPEL?

Assaf Arkin guest-posts an impassioned love-hate note to BPMN on IT|Redux. I admit I only understood about half of it, and I think you'd need to have stayed awake through many a BPEL TC conference call to get most of the references. His first core assumption - that BPMN's deeper purpose is to provide process design portability, not just a drawing - is one I agree with (e.g. here and here and also here)... but it's hard for me to accept his second one, which is that a BPMN independent of BPEL makes portability impossible, and we should just accept that BPMN's purpose is to be the notation for BPEL.

Since he knows OMG won't go this way anytime soon, he sort of hints/threatens to just build the reference implementation himself and provide it to Eclipse. I suppose if open source BPEL 2.0 wins in the marketplace (or even makes a strong showing), this would make Assaf's BPMN metamodel the de facto real one, while OMG keeps fiddling with BPDM.

I lack the smarts to debate this with the likes of Assaf, but I question whether the ultimate test for BPMN should be the level of portability he demands, and in particular binding it to one particular interpretation of the BPEL 2.0 specification. He seems to be worried about subtleties in the interpretation of scopes and compensation, while much bigger problems revolve around things like human tasks and subprocesses, neither of which BPEL 2.0 even supports, and those crazy freeform BPMN looping and merge patterns, which BPEL doesn't allow, either. I'm happy to junk the latter two, but a BPMN without human tasks or subprocesses isn't really about business processes.

Obviously, perfect portability on a free commodity platform is not going to motivate leading middleware vendors to play ball, and I don't even think it's the right goal. A much bigger win for both Intalio and BPMN would be a 99%-portable notation that would provide the same basic execution semantics on both BPEL engines (IBM, Oracle, Intalio) and non-BPEL engines like Lombardi, BEA AquaLogic, Cordys, ones that at least support basic BPMN concepts like intermediate events. I agree BPMN needs to be tightened up to do it, and it probably needs to be done outside of the OMG process.

In my view, an engine-independent portable design notation that allows BPMS vendors to compete on runtime functionality would stimulate the market, not kill it. And users would benefit more from that in the end.