BPMN Update from OMG

In terms of what it is and how it works, I was surprised at the number of new things I learned in his session... since I have been back and forth over that spec many times in preparing my BPMN training. For example:

  • Tasks in BPMN have a Type attribute, with defined values Service (the default), Send, Receive, Script, User, Manual, Reference, Abstract, or None. Depending on the value of the Task Type, certain message flows to or from the task are prohibited, and certain other attributes are required. According to Stephen, any real BPMN tool should enforce these validation rules. I am sure many do not.
  • A message intermediate event in normal flow can either send or listen for a message event. You can't tell from the diagram (unless a message flow is drawn). This might be legal but it seems bad practice. I think less ambiguous to use a Send or Receive Task instead.
  • A sequence flow is "not a control flow" because the target activity could also be gated by other conditions, such as data flow. I dunno about this one. All simulation engines assume a sequence flow is a control flow.
  • The exception flow from an error intermediate event can loop back to the same activity, essentially retrying it after the error handler. BPEL doesn't allow this; following the fault handler, BPEL re-enters the process flow after the activity (scope) where the fault was caught.
These might seem in-the-weeds details but it shows how complicated even a seemingly simple standard like BPMN can be to understand.

As far as where BPMN going, I was a bit underwhelmed. Rumors of an imminent BPMN 2.0 last summer were nowhere close to the truth. In spring of 2007 we should see BPMN 1.1, which makes minor tweaks to the current spec, cleaning up the semantics of details such as Link events and Exclusive Merge gateways. BPDM and a schema for BPMN? Don't hold your breath. When asked about this at his session, Stephen weakly offered WfMC's XPDL 2.0. That's not OMG's official position, obviously. But to me, OMG's lack of urgency on this issue is unconscionable. What about some kind of compliance guidelines, such as a list of MUST-SUPPORT objects and attributes? Today any tool that has rounded rectangles and swimlanes claims to be BPMN. Stephen was vague on this, but it sounded like a possibility. However, OMG will not be enforcing or certifying compliance.

BPMN 2.0 -- the version that brings in BPDM, choreography, etc. -- is still about two years away! The RFP should go out in the spring.