Several months ago, I got an urgent request from OMG – the organization responsible for BPMN and other BPM standards – to give a short blurb I had written a permanent URL on my website. The blurb was a promotional piece for my BPMessentials training called “Three Levels of Process Modeling with BPMN.” OMG proudly proclaims that BPMN assumes no particular methodology, but the notion of using it at three specific “levels” was just something I made up when I launched my BPMN course, to describe its value to different audiences. Now OMG needed it as a “reference” for their OCEB certification exam? I protested. “That’s just ad copy! It’s not in the standard. You can’t make that a reference.”
I’ve now been doing BPMN training for two years, and only recently have I begun to appreciate the true nature of BPMN usage levels. This reconsidered view may help you better understand what is rapidly becoming the one significant standard in BPM.
First, we need to acknowledge that even if they are all using the same process modeling “language” – BPMN – process modelers are not all striving toward the same goal. Many are business analysts simply trying to capture their current-state processes for documentation, analysis, and eventual improvement. They like the part of BPMN that is familiar from traditional flowcharting – swimlanes, boxes, and arrows – easily understood by their newly formed BPM project teams. They want to make their diagrams “conform to the standard,” but without straying too far from their comfort zone. Let’s call that Level 1.
Unfortunately, restricting BPMN to the part that is familiar from traditional process mapping is to miss its essence, which is the expressiveness required to describe not only the process’s normal or “happy path” but the various exception paths as well, and to do so with the semantic precision needed by IT to translate any proposed improvement into a working implementation. BPMN is the first serious attempt to provide a common visual language for process description shared by business and IT. BPMN does this with events and exception flows, pools and message flows, and other constructs needed to express how exceptions are handled. Instances following the happy path are rarely the reason for process improvement initiatives. It’s all about the exceptions, and BPMN at Level 2 captures all that. This is what we emphasize in BPMessentials, and being good at it requires a logical mind and attention to detail.
Still, we are just talking about modeling the activity flow, not the implementation of individual tasks, or even the process data and conditional logic needed in an automated process implementation. BPMN can be used for that as well. We used to call that Level 3, but today I see it as a flavor of Level 2. As practiced by a majority of BPM Suite vendors today, Level 2 BPMN models created by process architects, business architects, and top-tier business analysts form the base activity flow layer on top of which IT layers the data model, business rules, and other implementation properties. In other words, BPMN provides the activity flow model, and non-BPMN implementation properties are layered on top of it to form an executable process design.
Level 3 is what OMG seems to be emphasizing in the next iteration of the standard, using BPMN 2.0 not simply as a diagramming notation but as a full-blown executable design language. BPMN has always provided a set of implementation attributes, but I don’t know a single BPMS that uses them. BPMN at Level 3 will create fully executable process implementations based on a standardized design language. Using BPMN at Level 3, however, has platform dependencies, such as restrictions on the allowed element types and topologies in order to conform to the architecture of a particular runtime environment, like BPEL. In fact, the impetus behind this seems to be coming from BPEL-based BPMS vendors looking for a more business-friendly front end.
In summary, what most business analysts think they want when they go looking for BPMN training is Level 1. But the wide variety of BPMN tools, including many provided by BPMS vendors, are aimed at Level 2, which is where BPMN’s greatest business value still lies. The BPMS vendors most responsible for popularizing BPMN seem quite comfortable in adding implementation properties in their own tool-specific ways, and have not shown great interest in “executable BPMN,” or Level 3. But Level 3 seems to be the principal goal of BPMN 2.0 in OMG. When it is adopted, BPMN 2.0 will create a tipping point… for the mass market of process modelers, looking for Level 1. There is a delicious irony in all of this.
A crucial difference between Level 1 and Level 2 recently dawned on me, although it may have been apparent to many of you all along. BPMN describes any process, whether executable or not, as an orchestration, that is, a flow of control from one activity to the next, commanded by a central process engine. In other words, it treats any process as if it were automated by a BPMS, when in fact the vast majority are not. Level 2 modelers learn to accept that hidden assumption. For example, we teach that you shouldn’t model a task to “send” the work to the next performer, since that sending – including notifying the performer and delivering the required data and documents to the worklist – is inherent in the notion of sequence flow, i.e. the connector itself. But of course that makes no sense unless you pretend there is an engine, a worklist, and a notification framework where today there is none.
Level 2 modeling requires “playing along” with this fiction, even if there is no intention of ever actually automating the process. But for Level 1 modelers trying to capture the as-is, this cognitive dissonance is hard to sustain. With BPMN, the great divide is no longer between business and IT. Level 2 modeling does a great job of bridging it. The new divide is between Level 1 and Level 2 modeling, and we’ll be addressing that soon in the training.
