Which Way for BPMN 2.0?

Surprisingly little information has reached public view concerning BPMN 2.0, now under consideration in OMG. Unlike most standards approval processes, the outcome of this one is not preordained. There are two submissions, quite different, and it could go either way.

Oracle's Vishal Saxena notes that one reason BPMN 1.x has been so successful is that it "keeps simple things simple" by focusing on abstract business-level modeling, allowing developers flexibility in how to implement the technical details, and argues that BPMN 2.0 "should maintain this flexibility." In response, IDS Scheer's Sebastian Stein points out that a problem with BPMN 1.x is that it "only has implicitly defined execution semantics," and BPMN 2.0 needs to make them explicit. He goes on to neatly summarize the competing proposals:

At the current point there are two different approaches discussed within OMG, how to do that:
  1. BPMN 1.1 already contains an implicit definition of the execution semantics, so just make them explicit by writing them down.
  2. Use a more abstract meta model with well defined execution semantics like BPDM and map BPMN elements to it.
Approach 1 is a simple solution, because in the end it does not change much for the BPMN user. The implicit execution semantics are just made explicit, but they are not modified. Approach 2 is more complicated, because a second language is added to the stack and new concepts are introduced. Having more and new concepts might contradict BPMN?s current strength - simplicity. This will increase the learning curve for BPMN modelling and might hinder a further adoption.
I think this is a fair characterization, but it's not the whole story. Approach 1 is a joint submission by the large platform/middleware vendors, companies used to having their way in W3C and OASIS. Approach 2 is BPDM, which has been incubating in OMG for a long time, and wedded to OMG fundamentals like MOF and xmi. More significantly, Approach 1 reflects (to me, at least) a BPMS approach to BPM solution development, emphasizing unification of the business-oriented process model with the executable design, while Approach 2 is more aligned to OMG's programmer-oriented MDA vision, in which models are just a more efficient way to generate code.

It's a subtle distinction, and not everyone would agree with my characterization. A key element is that in Approach 1, the execution semantics of shapes in the diagram are specified by the standard, while in Approach 2 they can be redefined by the user. That's what the BPMN Wish List controversy back in March was all about.

As a non-voting guest member of OMG, I am not a party to the contest, but I am not neutral, either. I think a win by Approach 1 would greatly assist BPMS become mainstream and better define the relationship of BPM to SOA. Formal action by OMG on this is not scheduled until August-September.