Hagen Völzer from IBM Research in Zurich – and a member of the BPMN standards group – gave a tutorial on BPMN 2.0, with a specific focus on the new execution semantics.
BPMN 1.1 has taken us a long way towards a standardized process modeling notation, but has several shortcomings: no standardized execution semantics, no standardized serialization, and lack of choreography support. BPMN 2.0 addresses these and some other issues, but does not include organizational models, data models, strategy and business rules. BPMN 2.0 is still being finalized and will be adopted as a standard sometime in 2010, but many vendors are starting to include the new features in their products. The challenge, as he points out, is representing the interrelationship between the new diagram types.
He walked through BPMN, highlighting the changes to the visual notation in 2.0:
- Lanes can be used to structure visualization of activities by any suitable attribute, not just roles
- Call activity type that can call another process or a global task.
- Business rule activity type (although this could be handled with a service task type).
- Non-interrupting boundary events, including all event types except error events.
- Escalation events.
- Event subprocesses, which is an event handler within a subprocess (hence has access to the subprocess context); this can be triggered multiple times for the containing subprocess, and all event subprocesses must terminate before the containing subprocess terminates.
- Inline error handler, which appears similar to the event subprocesses but for handling errors; it can handle the error locally rather than propagating it up the scope tree.
- Compensation event subprocess, similar to the previous two handlers but for handling compensation events.
- Data are now first class elements, and can be used as an input or output to an activity using the new data association that describes data flow between data objects and activities or events.
- Choreography diagrams containing (not surprisingly) choreography activities that represent the activities between the participants; the pools and message flows are hidden, and only the choreography activities and the linkages between them are modeled. The two diagram types can be combined to show the choreography in the context of the pools and message flows.
- Conversations, which collapse multiple related message flows to visually simplify a diagram; conversations can include more than two participants.
He also walked through the execution semantics, which are based on token flows, with token being produced and consumed by activities, events and gateways. BPMN 2.0 also specifies the representation of an activity lifecycle to map all of the actions that can occur around an activity. We looked in detail at the token-based execution semantics for an inclusive join (where the number of tokens generated by the split is not known locally) in a variety of nested contexts. The complexity of this explains a lot about why the 7PMG guidelines recommend not using inclusive ORs: if it’s this hard to figure out all the possible execution semantics, it’s going to be complex for a human to understand the model visually.
He ended up with research opportunities that have been created by the new specification, such as formalizing semantics of choreography diagrams (now we know his motivation for sitting on the committee 🙂 ); it seems that there are many unresolved issues remaining.
It was useful to have a complete walkthrough of the specification as a refresher and to see the changes in context. I’m left with the impression that the event handlers and some of the other new features are exceptionally useful, but unlikely to be well-understood (and therefore used) by non-technical business analysts. As another one of the attendees pointed out, they’ve just invented a new visual programming language.