BPMN 2.0: from notation to executable processes

Business Process Model and Notation, version 2.0, is not just another notation in a long line of methods for describing business processes. It is an attempt to create a universal language that business analysts, methodologists, developers and managers could all speak to one another — and that language must be directly executable by a computer.

Did it succeed? Both yes and no. In this article we break down what exactly BPMN 2.0 is, how to use it correctly, and the mistakes teams most often make when adopting it.

A brief history

BPMN 1.0 was published in 2004 by the Business Process Management Initiative (BPMI) — an industry consortium of the largest players in the BPM-tools market. In 2005 BPMI merged with the Object Management Group, and further development of the standard proceeded under its aegis.

BPMN 2.0, published in January 2011, was a watershed. Where BPMN 1.x was mostly a graphical notation with vague interpretation rules, BPMN 2.0 introduced strict executable semantics, a formal metamodel and XML serialization. That same year BPMN 2.0 became the international standard ISO/IEC 19510.

Three levels of BPMN

The industry has settled on a classification distinguishing three levels of BPMN use. It helps avoid mixing the purposes of models and choose the right level of detail for the task.

Descriptive level

At this level a minimal set of elements is used: tasks, XOR and AND gateways, start and end events, sequence flows. The model reads like an “advanced flowchart” — clear and understandable without training. Descriptive BPMN is a tool for communicating with the business and documenting a process in broad strokes.

Analytical level

The full range of gateways (including event-based and complex ones), events of all types with detailed semantics (messages, timers, errors, escalations, signals), pools and lanes for organizational structure, and data artifacts come into play. At the analytical level the model is already hard to read without training, but it is ready for technical detailing.

Executable level

The model contains all the technical attributes needed to run in a BPM engine: process variables, scripting-language expressions, service-task specifications (REST endpoints, message queues), user-task forms, error and compensation handlers.

The main mistake — mixing levels

The most common mistake when adopting BPMN is trying to use one and the same model across different levels. A business analyst draws a “pretty” descriptive model and hands it to a developer with “now automate this”. The developer adds the required technical detail — and the model stops being understandable to the business.

The right approach is to maintain three different models of one process, one at each level. They should be linked at the level of task identifiers: the same task “Approve contract” has the same ID at the descriptive, analytical and executable levels, but is described in different degrees of detail.

Token semantics

Understanding token mechanics is critical for correct modeling. Each process start spawns one token at the start event. The token moves along sequence flows, passes through tasks (which “hold” it while work is done), may split into several tokens at parallel gateways and merge again.

A process completes when all tokens reach end events or are consumed. If even one token gets “stuck”, the process hangs in an unfinished state. This is a typical problem in poorly designed models with parallel branches that do not converge correctly.

What to choose instead of, or alongside

BPMN is powerful but not universal. For adaptive, loosely structured processes CMMN is a better fit; for business rules, DMN; for the top level of a process architecture, VAC or VAD; for production flows with a focus on waste, VSM.

Modern practice is to use a combination of standards. OMG deliberately designed the “triad” BPMN + CMMN + DMN as a single ecosystem. A BPMN process can invoke CMMN cases and rely on DMN decisions, and all of it is executable in modern engines such as Camunda 8.

Conclusion

BPMN 2.0 is an investment that pays off in projects with a long lifecycle, a need for automation and a need to document processes at different levels of abstraction. For a one-off documentation of a simple process, a flowchart is more appropriate.

The main thing when learning BPMN is to remember that a notation does not exist for its own sake. A good BPMN model is not one that uses every possible element, but one that solves the task at hand with minimal complexity.