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.
Tags: BPMN, bpmn 2.0, bpmn training, methodology, process modeling
7 Responses to “BPMN “Levels” and Tool Interoperability”
BPMN Training
NEW! Virtual classroom Jan 25-28. Find out more!
Learn BPMN the right way. Not just compliance with the spec, but maximum effectiveness as a common visual language. Methodology, patterns, best practices, organizing complex models.... Hands-on with a tool. Loads of exercises, both in class and post-class (with individualized help, certification of proficiency). 60-day license to Process Modeler for Visio included.
Available online and in 2-day public classes. Don't be left behind.
2010 public classes Online Jan 25-28, Chicago April 21-22, San Francisco June 30-July 1, DC September 15-16, New York November 3-4. Have 10 or more students? Private 2-day classes delivered at your site, with same tool and post-class certification. Contact me for pricing and details.
BPMN Method and Style
Expanded (inline) subprocess.
I really like this as an opportunity to show where the design of an activity is heading. The subprocess may not be completely understood or defined at the time a Level 1 diagram is appropriate or sufficient but using an inline subprocess can explain ideas about organisational peculiarities better than just the activity name or a note somewhere else.
OR gateway
I would like the OR gateway to be available even in early modelling stages as it has specific meaning that may be relevant well before people worry about a specific executable. I am particularly anti anything that deliberately ignores the ‘rules’ of the BPMN specification because I feel that will cause problems in exchanging models between tools where A is pedantic and B is lax.
Pools, message flow, and Message start/end events.
I am really in favour of these constructs from the earliest point of modelling if the expected end point is an executable BP that is derived from the BP work. There is a practical difference between knowing all the information of the process and having the information constrained by the content and timing of a message. I think that there is merit in breaking what may be seen as a single process through multiple areas of responsibility in the organisation (say widget provisioning through sales, manufacturing, finance) into separate pools to formalise the relationship between areas of responsibility.
Bruce,
There is one design choice in BPMN that I have not understood before and maybe now that you have “insider” knowledge you can explain it to me. By default, when two flows point to the same task, the semantics is the same as if the two flows in question converged into an XOR merge gateway and then there was a flow from this “implicit” XOR merge gateway into the task in question. In other words, a token coming from any of the two incoming flows activates the task.
Now, why wouldn’t the semantics be a bit different here: when two flows point to the same task, the semantics should be the the same as if the two flows in question converged into an OR gateway and then there was a flow from this “implicit” OR-join gateway to the task in question.
This simple design choice in the standard would obviate in many cases the need for merge gateways, and would be quite handy when doing “high-level design”. The OR gateway simply behaves like an AND gateway or like an XOR gateway depending on the context. In high-level process models, people could omit merge gateways and simply connect multiple incoming flows to a single task. The merge gateways could be added later when making the models more detailed and executable, since it is likely that in many process execution engines, the OR-join will not be executed as efficiently as XOR or AND-joins.
I know this is a bit of a side-track with respect to the questions you pose in your post, but it is also somehow related. Because the question you’re asking basically boils down to “What subset of BPMN do I need for high-level process modeling”? This is basically your level 1 palette and the usage guidelines that would be associated to this palette.
Marlon,
Funny you should bring this up, because Vishal Saxena of Oracle has been on a similar campaign lately. He even managed to resurrect this issue for reconsideration in last week’s team meeting. I don’t know what the outcome of that was. Perhaps Vishal can comment?
I am conflicted on the matter. I agree that making the implicit uncontrolled merge semantics OR-join instead of XOR (ie pass-through) would a)conform to business modelers’ expectations (as you note) and b)save valuable real estate on the page. On the other hand, it is inconsistent with BPMN’s notion of sequence flow as control flow, so that without an intervening gateway (or the diamond-on-the-tail thing), completion of one node automatically enables the next one. More important for me, it is a major change at the last minute, and a semantic difference from BPMN 1.x. I would have to make 11th-hour changes to my book, my training, etc. Not a compelling argument perhaps, but I think the inconsistency with BPMN 1.x might be the determining factor in the team’s decision.
In the end, this is not a question of method and style but fundamental semantics of the notation. Let’s see what OMG finally decides on the matter.
Bruce,
great post as usual, interesting food for thought.
re: the question around merge vs. or-join semantics – I think simply that bpmn practitioners need to do a better job of explaining why it behaves that way – as you did – because split/join semantics are always explicitly modeled, and otherwise you have merely decision/merge semantics. it is actually a pretty simple rule and works well, though it takes getting used to.
regarding your 3 points:
1. expanded subprocesses are nice eye candy , but a bit confusing at implementation level – some tools have expanded subprocesses, but not “nested processes” that can be re-used by multiple parent processes. some have limits about how deep you can go. some allow no expanded subprocesses but do the reusable nested processes. at the “novice” level i prefer to keep this to just a visual discussion and not get into the re-use aspects.
2. OR gateway. Although it is important to understand, new modelers will make LOTS of mistakes about the right split/join (gateways) to use. Better to just get them to approximately diagram the right thing, and then have an expert quiz them about the actual semantics they want on these splits and joins depending on the circumstances.
3. yep, makes sense to me…
1. Expanded subprocesses may be useful for didactic purposes and can be good for simple embedded subprocesses, particularly when they are AdHoc. But, should this be a criteria for model portability? Does it mean that if a process is exported with an expanded subprocess that another tool, on importing it, has to show the expanded subprocess?
2.I think OR gatweways are a big problem. The execution semantics are challenging because it requires a complex analysis to determine what to do at OR merges. Multiple inputs at an activity are now defined as an XOR (exclusive) merge and I think that is good. XPDL inherited a more sophisticated underlying semantics (Transition restrictions) which allowed more complicated logic both on the inputs and the outputs of an activity. This may help power users but basically obscures the sequence flow logic. In my opinion leaving out gateways is a shortcut to be used only when it is clear what is meant. So multiple parallel outputs from an activity is a clear shortcut for sticking in a parallel split. Multiple inputs is a clear shortcut for sticking in an Exclusive (XOR) merge. Multiple outputs, some with conditions, is arguably a mess.
Robert,
You bring up something I forgot to mention. Unlike XPDL, BPMN 2.0 serializes the subprocess expansion identically whether it is visually represented as inline expansion or hierarchical expansion. Identical except for the graphics (DI) part, which I think many vendors will ignore. So, to your point, a tool that does not support inline expansion should – in my opinion – be free to render as standalone expansion on import. In the BPMN semantic model, there is no difference.
This also calls to mind the question of whether Level 1 or XPDL SIMPLE should distinguish regular subprocesses (“embedded”) from Call Activity (the calling part of a “reusable” subprocess). I am with Scott on this… Notions of “reuse” are techy things that confuse business people, so I choose to leave them to Level 2. But it is true that in BPMN 2.0, Subprocess and Call Activity are distinct semantic elements with different graphics.
[...] been using the new levels-based method and style approach in private classroom training for the past couple months. I think it makes learning BPMN [...]