BPMN "Levels" and Tool Interoperability

By: Bruce Silver December 29, 2016 bpmn

BPMN is sometimes criticized for being too complicated for business users. That charge assumes that users need to understand every shape, symbol, and underlying attribute. But no one does, not even the experts, and most tools don't even support them all.

The way around this problem is through a hierarchy of modeling "levels." Levels are often used in modeling to distinguish views at different degrees of abstraction, from high-level business-oriented views to detailed technical views. I tried to get OMG to support something like this in the conformance section of BPMN 2.0, but without success.

Nevertheless, I have used BPMN levels successfully in my BPMessentials training, and have formalized it in the methodology of my new book, BPMN Method and Style. In that methodology, Level 1, or descriptive BPMN, is based on a limited working set of constructs familiar to most business users and supported by most modeling tools. Level 2, or analytical BPMN, draws on the full palette of BPMN 2.0 shapes and symbols, but omits the executable details underneath. The most commonly used event, gateway, and task types are included in what I call the Level 2 "core" palette. Level 3, or executable BPMN, is new with BPMN 2.0. There the diagram, elaborated with XML for data mappings, services, messages, and human task assignments, becomes executable on a process engine.

The key question is what to include in Level 1. I have two objectives here, which unfortunately are not always aligned.

The first is pedagogical, related to the business-oriented methodology. The Level 1 palette should be familiar to business users, but the basic structure of Level 1 models must be preserved when moving to Level 2. Otherwise you cannot achieve that goal of a common language shared by business and IT. So I have included in my Level 1 palette some things that others may question.

The second is portability of BPMN models across tools. The BPMN 2.0 team failed completely here, despite the lip service to that goal in the specification. Portability demands levels, at least if you want any tools to claim they support it, and there are no levels in the BPMN 2.0 spec. There are levels, however, in XPDL 2.1 - WfMC's serialization of BPMN 1.1/1.2 - and there will be levels in XPDL2.2, the BPMN 2.0 version. Robert Shapiro, driver of that effort, and I have been discussing what should be included in Level 1, or what XPDL 2.1 calls the SIMPLE class. We will continue to talk about it, but I think there is value in soliciting other views as well. Hence this post...

Here is a table comparing my Level 1 and Level 2 core palettes with XDPL 2.1 SIMPLE and STANDARD classes, and with Lombardi Blueprint. I picked Blueprint because it offers a limited BPMN palette for business users, and because I am offering a version of my Level 1 methodology using that tool.

Bruce Silver Level 1 Lombardi Blueprint XPDL 2.1 SIMPLE Bruce Silver Level 2 core XPDL 2.1 STANDARD
Red means new in BPMN 2.0 ~ means workaround in my Blueprint Level 1 course
Task (None) x x x x x
User task x x x x
Service task x x x x
Send task x x
Receive task x x
subprocess, collapsed x x x x x
Subprocess, expanded inline x x x x
Subprocess, expanded standalone x x x x x
Looping activity x (task only) x x
MI activity x (task only) x x
XOR gateway x x x x x
OR gateway x x x x
AND gateway x x x x x
Event gateway x x
None start and None end events x x x x x
Message start and end events x ~ x x
Timer start event x x x
Signal start event x
Terminate end event x x x
Catching message IE x x x
Throwing message IE x x
Boundary message IE x x
Non-int message IE x
Catching timer IE x x x
Boundary timer IE x x
Non-int timer IE x
Error boundary IE x x
Throwing error event ~ x x
Boundary escalation IE (non-int) x
Throwing escalation event x
Catching Signal IE x
Boundary Signal IE x
Non-int Signal IE x
pool x x x x
lane x x x x x
data object and data association x x x x
text annotation and association x x x x
Sequence flow (unconditional) x x x x x
Conditional sequence flow x x x
Default sequence flow x x x
Message flow x x
Link event pair (goto) x x x
Data store x x
Conditional events ???
Event subprocess ???
Message and data association x x
Since I worked with Robert on the XPDL SIMPLE class, he asked me why my Level 1 palette was different from that. The honest answer is when I was working on SIMPLE I was thinking about commonality among BPMN tools, and when I was developing my levels I was thinking about methodology and business-IT alignment. I always imagined those two goals were aligned, but obviously not entirely.

I invite discussion on the following points:

  • Expanded (inline) subprocess. I don't use it in my methodology but it is useful pedagogically, since you can show the child level and parent level flows in the same picture. Since I use it for that in the Level 1 part of the book, I put it in the palette.
  • OR gateway. It's confusing to some users, so I leave it out of Level 1. It's not used that often. The Level 1 method ignores the error of using AND-join where the technically correct gateway is OR.
  • Pools, message flow, and Message start/end events. Showing the "customer" (process requester) as a separate black-box (empty) pool rather than as a lane within the process is fundamental to my Level 1 method, and essential for business-IT alignment. So I include pools and message flows in the palette, as well as Message start and end events.
The last one may be the biggest obstacle to unifying the methodology with the tool interoperability classes. It's a change from my thinking about SIMPLE class in XPDL 2.1. The question is should they be added to SIMPLE in XPDL 2.2? Technically, in BPMN 2.0 you cannot even draw a pool unless you show two of them interacting via message flows. That's a change from BPMN 1.x, and we'll see whether tool vendors and users complain about the new rule (or simply ignore it). On the other hand, many tools - e.g. Blueprint - cannot have multiple pools and message flows.

I can see how multiple white-box pools could be an architectural problem for some tools, but usually there is only one white-box pool (the process), interacting with black-box pools representing the customer (requester) and possibly other service providers. That's just a drawing issue. Alternatively, BPMN 2.0 provides a notation within a process diagram (no pools) in which a message symbol (envelope) is linked to activities and events via data association (dotted line) to signify an incoming or outgoing message. This accomplishes the same thing. I would hope to keep the notion of process requests and responses in the Level 1 palette somehow.

Your comments are welcome.