When you're deep in a hole of your own creation, the usual advice is to stop digging. But Assaf Arkin is not a slave to such conventional wisdom. He took a sound hammering on the comment thread to his original IT|Redux post where he states that BPMN should just be the diagram for BPEL 2.0, but he continues to dig in hard and reaffirms that process portability demands a common execution language, BPEL 2.0. But he doesn't really defend the assertion with arguments that the undecided can understand.
Today Ismael tries to bail him out, making the valid point that the only process definitions that are close to portable today are those based on BPEL. I would agree with that, and it's why I've never been a "BPEL-hater". But my own migration to the BPEL-doesn't-matter camp has been based on the vision of a new higher-level design portability standard: BPMN. Now that may or may not be OMG's view of what BPMN should be -- Fred Cummins' comments on Assaf's original post lead me to think not -- and I've already committed the heresy of saying if that is not included in OMG's vision for BPMN, the BPMS vendors should just get together and create "BPMN-P" (portable) themselves.
So let's get to the real point: What does design portability mean? Assaf's version, which I interpret to mean that two "implementations" of the same diagram should result in the same BPEL 2.0, is too narrow. Let's face it, each BPMS is going to have its own bells and whistles that "add value" on top of any standard. So the challenge is to draw a line -- the portability threshold -- separating semantics that must be standardized to conform with a reasonable process owner's understanding of portability from value-add features that do not. Those value-add features may figure decisively in the process owner's choice to go with BPMS A instead of X, Y, or Z. But portability also guarantees that if BPMS A turns out not to perform as advertised, another BPMS can be swapped in with relatively little redesign.
The BPMN 1.0 spec is silent on this issue, and it's not clear that BPDM addresses it, either. To most vendors today, showing activities as rounded rectangles, splits and branches as diamond shapes, and swimlanes is enough to claim BPMN conformance. Yes, I agree that is ridiculous. I also agree that an intermediate event attached to an activity or subprocess boundary is a valuable design concept that should be preserved in BPMN-P... even though leading non-BPEL "BPMN-compliant" tools (e.g., Savvion, BEA) don't support it today. But some do: Lombardi, Cordys... Compensation seems to be an important thing to Assaf, but the business requirement is very different for human-centric and straight-through processes, and fault and compensation handling is all over the map. Is compensation above or below the portability threshold? It's worth having the discussion.
Right now the real debate is on hold while we wait to see what BPDM looks like. Unlike the BPEL TC, where issues and interim drafts are open for view, the BPDM process is completely opaque. I hear rumblings about September, so maybe we'll know soon.