An Introduction to BPMN

Abstract

This text gives an introduction to the Business Process Modeling Notation. It is based on a chapter of a research report that I wrote some years ago (link). It has been updated to the current state-of-the-art. More important, you can start modeling your own processes today using Microsoft Visio (on Windows) or OmniGraffle (on Mac OS). The stencils required can be found here.

Business Process Modeling Notation

The Business Process Modeling Notation (BPMN) allows the definition of business processes in diagrammatic form. The notation has been originally proposed in 2004 by the Business Process Management Initiative (BPMI), whose members are major well-known software vendors. In 2006, the BPMN was adopted as a standard of the object management group (OMG).

In the presence of many different process modeling approaches---such as Event-driven Process Chains or Workflow nets---the question arises, why yet another one? The members of the Business Process Management Initiative yield expertise and experience in many existing notations and combined the best ideas into one single standard notation. This standard should be easily understandable by different business users. Therefore simplicity was a goal, which stands in contrast to another goal, the visualization and direct mapping of XML languages designed for the execution of business processes.

The BPMN is designed to bridge the gap between business process design and implementation. The long term aim is to automatically visualize business process execution language programs into standardized business process diagrams and vice versa. The effort of a human translator is then no longer needed. The BPMN specification defines a partly mapping from BPMN to WS-BPEL (Web Services Business Process Execution Language), as will be described later in this chapter.

The notation is intended to be used with business processes on three different levels of abstraction. This includes private, abstract and collaboration processes. The first is generally known as workflow, it describes business processes, which are internal to a specific organization. Abstract (public) processes represent the communication between a private business process and another process or participant. They contain only the activities needed for communication. Collaborations define a sequence of activities that represent the message exchange pattern between two or more business entities. In the domain of web services the terms orchestration and choreography are commonly used, where the former refers to private or abstract business processes and the latter to collaborations.

Notation

This section describes the achievement of the above goals, especially the dissolving of the requirement simplicity and the potentially conflicting requirement of mapping complex business processes to business process execution languages.

Simplicity is achieved through a basic set of core elements for grouping, primary modeling and connectivity. Using only these core elements, many business processes can be visualized. The core elements can be enhanced based on their basic visual notation. This means, adding something to the visualization of a core element, does not change the basic shape. This way, even new and unknown elements can be mapped back to core elements.

To achieve the mapping to business process execution languages, more information is needed. This information is provided in form of attributes for each element. Attributes can be set automatically by tools; this includes unique element ids, default names or conditions. Some default values are defined by the BPMN specification, always specifying the core format of the element. By modifying those attributes, enhanced and complex variations can be created. However, it is not necessarily needed to change the attributes to receive simple behavior.

Beginning with the core elements, the notation of BPMN is introduced in the following subsections. This is just an outline of the specified elements; the complete reference can be found in the BPMN specification. A real-world example follows in the end.

Core Elements

The BPMN core element set can be divided into three groups. These groups include elements for grouping, primary modeling and connectivity. Everything in BMPN can be modeled by further specializing single core elements. The core elements are shown in the figure below.

The primary modeling elements are events, activities and gateways. Events are something that “happens” in the course of a business process. They affect the flow of the process and can have a trigger or a result. An activity is work a company performs; it can be atomic or complex. Gateways are used as controlling structures for sequence flows. Sequence flows connect events, activities and gateways and therefore belong to the connectivity elements. The sequence flow defines the possible flow of the process. Message flows show the flow of messages between businesses. An association connects further information, like descriptions, to the core elements.

All primary modeling elements are placed inside pools. A pool is a container for grouping a set of activities for a particular organization. To further decompose an organization into specific units, so-called swim lanes inside a pool can be used. The pools can be black or white boxed. A black box pool hides it inside details; communication can only occur to the outside line of the pool, whereas a white box pool shows it inside details and allows communication to inside elements.

An example of a BPMN diagram using almost exclusively the core elements is given below. This particular process begins with a generic event, called start event. After processing the order, a decision for a payment method must be made. If "Credit Card" is chosen, the transaction must be confirmed by another participant: a bank. The bank is a black box pool in this example; internal processes are unknown. Afterwards the order can be shipped. The process ends with an end event, a slight modification of the basic event type.

Events

As explained earlier, the core elements can be modified to achieve more complex behavior. An example was given in the figure above, where the core element event has been named start event and a derived shape, with a bolder outline, end event. The intermediate event is a third form, visualized using double-lined circles. It does affect the flow of the process, but will not start or end it.



Based on start, intermediate and end events, different types of events have been specified. They are shown in the figure above. In BPMN all start events produce a "token", which follows the sequence flow of the process. All end events consume a token. This is in contrast to other notation like Petri nets, where transitions consume and produce tokens. The start and end events are optional. If they are suppressed, every activity that has no incoming sequence flow acts as a start event and every activity that has no outgoing sequence flow acts as an end event. The process finishes when all parallel paths have been completed.

The message event can be used to model communication with other participants, which can be omitted in the diagram or exist in another pool. The message start event triggers the start of the process after the arrival of a message, while the message end event finishes the process and sends a message to a participant. The message intermediate event stops the process to wait for the receipt of a message. An example is shown in the figure below. 

The timer start event triggers the start of a process to a specific time or time cycle. The timer intermediate event delays the process flow for a given time value or interrupt an activity at a specified time or duration. An example for a voting process is shown below.

The exception events are used within exception handling; they are described in section Activities. The cancel events are used to abort transactions, while the compensation events are used for compensation handling. The usage is also described in section Activities.



The rule start event works similar to the timer start event; the condition is set to a rule like “Temperature below 15°C”. The rule intermediate event is used for exception handling when a named rule becomes true. An example is given in figure below. Because the rule intermediate event is only used for exception handling, it has to be placed on the edge of an activity, as it creates exceptional flow. Exceptional flow is equal to sequence flow; it just opens a separate path.

REWRITE: The link start and end events connect the end of one process to the start of another. The link intermediate events connect the end of one process to the start of an event-based exclusive decision. This type of decision is described in section 4.1.4 (Gateways). The final usage of the link events is still an open issue in the BPMN draft specification; therefore no concrete example can be given.



The multiple event is used if there exists different ways of starting, ending or disturbing a process. The multiple events can be seen as a list of almost any other events, automatically choosing the triggering event. An example is given below.

The terminate event indicates a fatal error and therefore stops all (parallel) activities in the process without any exception or compensation handling.