BPMN 2.0: Introduction to the Standard for Business Process Modeling

1 BPMN – A Standard for Business Process Modeling

1.1 Why a Notation?

In order to manage business processes, they have to be described and documented. There are various possibilities to do so. The easiest way is the usage of textual or tabular descriptions. Flow chart diagrams are quite often created using presentation and graphics software. These diagrams mostly consist of small boxes and arrows, not following a defined method.

Unfortunately, this does not meet the requirements of exactly representing extensive processes with all relevant aspects, such as splitting rules, events, organizational units, data flow, etc. For this, appropriate notations are required. A notation for graphic business process modeling defines, for example, the symbols for the various process elements, their correct meaning, as well as their possible combinations.

Thus, a notation is a standardized language for the description of business processes. Everybody, who is familiar with this language, can understand models created by someone else. Furthermore, processes can be systematically analyzed, and their dynamic behavior can be simulated based on a standardized representation.

The subject of Governance, Risk, and Compliance (GRC) , which is getting increasingly important, also requires a standardized and complete documentation of adequate processes that makes sure that any legal and industry-specific demands with respect to risk management, quality management, and the compliance with safety rules, etc., are met.

Models also provide a basis for the development of information systems for executing and supporting business processes. Therefore, the models need a standardized structure, and they have to contain all information relevant for system development.

System-supported processes are more and more controlled by business process management systems (BPMS). These contain process engines which directly control the workflows using appropriate process models or formal process descriptions. For this purpose, the models have to meet very strict demands because they are not converted into a computer program by a human being, but directly processed by a machine.

In the course of time, several notations for process modeling emerged. These were quite often proprietary notations of special modeling tools or workflow management systems. By now, standards for executable process descriptions have been established, such as XPDL (XML Process Definition Language) [Workflow Management Coalition 2012], and BPEL (Business Process Execution Language) [OASIS 2007]. But XPDL and BPEL are no graphic notations, and their primary area of application is the definition of automated processes.

In the area of business-oriented process modeling, the notation of the event-driven process chain (EPC) is still frequently used. This notation was rather popular before the development of BPMN. However, EPC is not a standard, and many users have replaced EPC with BPMN. Today, most EPC modeling tools also support BPMN modeling.

Other standards, such as the activity diagrams of the Unified Modeling Language (UML), did not become accepted for business process modeling in practice. Their use basically remained restricted to the area of object-oriented software design, where UML is the accepted standard.

During the last years, BPMN (Business Process Model and Notation) has become accepted as the leading standard for business process modeling. The website bpmnmatrix.github.io contains a list of more than 50 tools which support BPMN modeling. An increasing number of websites, weblogs, and publications demonstrate the growing interest in this notation (e.g. [Debevoise and Taylor 2014], [Freund and Rücker 2014], [Herrera 2015], [Silver 2012]). Even a novel on process modeling with BPMN has been published [Grosskopf et al. 2009]. A selection of interesting internet sources can be found in the annex of this book.

Many organizations are providing their process management teams with BPMN training, and they are rolling out BPMN as their organization-wide modeling standard. In the e-government standards of Switzerland, for example, the use of BPMN is recommended as a common notation [Fischli et al. 2016]. Other examples of organizations which have published their BPMN modeling guideline documents are the public administrations of Queensland (Australia) [Queensland Government 2016] and British Columbia (Canada) [Lindner 2014]. In a recent survey on the use of BPM tools, BPMN was also the most widely used process modeling notation [Lübbe and Schnägelberger 2015].

1.2 Development of BPMN

Originally, BPMN was developed by the Business Process Management Initiative (BPMI), a consortium which consisted mainly of software companies. In the beginning, the purpose was to provide a graphical notation for process descriptions expressed in BPML (Business Process Modeling Language). Comparable to BPEL, BPML was used for specifying process descriptions which could be executed by a BPMS. BPML is not being developed further anymore; it has been given up in favor of BPEL.

The first version of the BPMN specification was developed by a team lead by Stephen A. White from IBM. It was published in 2004. In the meantime, BPMI has become a part of the Object Management Group (OMG). This organization is known for several software standards, such as the aforementioned UML (Unified Modeling Language).

In 2006, BPMN version 1.0 was officially accepted as an OMG standard. After some smaller changes in versions 1.1 and 1.2, version 2.0 brought more comprehensive changes and extensions. It was published in 2011. The latest version of the specification document, version 2.0.2 was released in 2013 [OMG 2013]. The actual content has not changed from version 2.0, as only minor corrections of the text have been made. In 2013, BPMN also became an official ISO standard [ISO 2013].

The most recent version of the BPMN specification can be found here:

www.omg.org/spec/BPMN

1.3 Contents of BPMN 2.0

For the majority of BPMN users, the most important aspect is the graphical representation of the models. BPMN provides three diagram types:

Process or collaboration diagram: In this type of diagram, the process flow can be modeled, including activities, splits, parallel flows, etc. It is also possible to show the collaboration between two or more processes with their exchanged messages. Process diagrams and collaboration diagrams are of the same diagram type. A diagram with only one process is often called process diagram, while a diagram with several interacting processes is a collaboration diagram.

Choreography diagram: Modeling of the data exchange between different partners, similar as in collaborations. However, each data exchange is modeled as an activity, so that on this level it is possible to visualize splits, loops, etc. in order to represent complex exchange protocols.

Conversation diagram: A conversation diagram is an overview of several partners and their interrelations.

The process or collaboration diagram is the most frequently used diagram type. Some BPMN tools and books are even restricted only to this type. Although it is undoubtedly the most important type, there are useful application areas for the other diagram types, as well. Therefore, they are also discussed in this book.

The BPMN specification explains the various notational elements not only verbally, but also defines them in a metamodel. The metamodel is documented with UML class diagrams that graphically show the features of the different BPMN constructs and their relationships. Such a metamodel is more accurate and definite than strictly verbal descriptions. The metamodel also has got additional language constructs that cannot be represented in graphic models. Such constructs are required, for example, by process engines to capture the necessary additional information for process execution.

The typical modeler does not need to work with the metamodel. Normally, he will use a modeling tool that only allows the creation of models complying with the specification, and thus with the metamodel. Therefore, it is rather the vendors of modeling tools, process engines, and similar software, who have to deal with the metamodel.

The metamodel is also the basis of an exchange format for BPMN models. Before BPMN 2.0 it was almost impossible to transfer BPMN models from one tool to another. Now, the specification defines a standardized exchange format. Many tool vendors support this standard format so that it is possible to exchange BPMN models not only between different modeling tools but also between a modeling tool and a BPMS. However, not all implementations of the exchange format are entirely consistent, so that sometimes there still may be problems and losses of some details.

For process automation, it needs to be defined how to execute each of the different BPMN elements. For this purpose, the specification defines execution semantics. The objective is to make sure that different process engines all interpret and execute a specific model in the same way. Like the exchange format, the execution semantics have not been implemented uniformly by all vendors, so there may be some differences when executing the same model on another process engine.

In spite of these occasional deviations, both the exchange format and the execution semantics are very useful, because otherwise model exchanges between different vendors‘ tools would be entirely impossible, and there would be much more differences in how process models are executed.

In the first version, the abbreviation BPMN stood for Business Process Modeling Notation. In version 2.0, the name was changed to Business Process Model and Notation. This name change emphasizes the fact that BPMN not only consists of the graphic notation, but also comprises the metamodel, the exchange format, and the execution semantics.

1.4 Business-Level Models and Executable Models

The origin of BPMN was in the field of process descriptions that can be performed by the process engine of a workflow or business process management system (BPMS). But the developers of BPMN claim that this notation allows for creating technical as well as business-level models. BPMN is supposed to be a common language of both, business experts and IT experts.

And in practice, BPMN is actually being used both for business-level modeling and for executable models. This becomes clear by looking at the tool market. BPMN is the predominant notation both for business process analysis tools and for modeling components of BPMS.

Although having a common notation, business-level models and technical models are quite different in practice. The main focus of business-level models is on the comprehension of the basic process flow. Thus, the usage of too many details is avoided. Conditions at the exits of a decision gateway are rather expressed in plain text than in exact formal terms. Exceptions and rare cases are quite often not modeled in detail but explained by notes and descriptions.

The source of some BPMN constructs is quite clearly the field of executable process definitions. BPMN contains among others special loop constructs, exception handling, and transactions. Programmers and IT-specialists are familiar with these subjects. Business process modelers, on the other hand, normally omit such items. In accordance to this, typical business-level models only comprise a subset of the whole notation.

Some BPMN experts recommend using the rather technical modeling constructs also in business-level models, to be able to show business-relevant exceptions and their handling in processes. Silver refers to the well-known 80-20 rule. He estimates that 80% of the costs, delays, and errors are caused by only 20% of the cases – the exceptions. Examples are cancelations, order changes, items out of stock, and timeouts [Silver 2012].

Those who want to apply BPMN for business process modeling should decide in advance which constructs should be used and how certain cases should be represented. It makes sense to document such decisions in the form of modeling conventions. Should the processes be modeled on a business level, and then be automated by a process engine, the way of transforming business-level models into models of executable processes has to be specified, i.e. how to complement, reorganize and detail the models.

The transition from business-oriented models to executable models is discussed in [Stiehl 2014].

1.5 About this Book

This book provides an introduction to the graphical notation of BPMN 2.0. Starting with a small example process, the basic BPMN elements for modeling simple flows are discussed. Step-by-step, the different BPMN concepts are introduced and explained using examples. The examples are generally intelligible business domain models, so that the reader does not need to have any specific IT know-how. There are only a few examples actually referring to process execution by a BPMS which are required for understanding some of BPMN’s more technical features.

Since the main focus is on the application of the notation for business-oriented process modeling, the BPMN metamodel is not part of this book, nor are the execution semantics discussed. A comprehensive discussion of the execution semantics can be found in [Kosak et al. 2014].

This book presents the entire notation. Although as described above, not for every modeling purpose all BPMN elements will be required, modeling experts still should be familiar with the entire BPMN. Only then they can reasonably select what is required and useful for their own modeling activities.

It was taken care that the discussion of the various BPMN concepts conforms to the official BPMN specification, as much as possible. Sometimes it was necessary to interpret the descriptions from the specification to some degree. Therefore, the explanations in this book always represent the author’s understanding. The author is always happy to receive feedback concerning mistakes and suggestions for improvement.

The book is an introduction to the BPMN standard. Thus, it does not discuss topics outside the standard, such as a specific methodology, the use of tools, etc. There are entirely different ways of using BPMN. Some suggestions can be found in [Silver 2012] and [Freund and Rücker 2014].

In the second edition, a new chapter has been added, containing a collection of useful modeling patterns. They provide best-practice solutions for typical problems arising in the practice of process modeling.

Apart from that, the overall structure and the main contents