BPMN 101: What Is a Process?

It’s now 10 years since finalization of BPMN 2.0, the acknowledged standard business process description language. BPMN has been widely adopted, by tool vendors and end users alike, but there are still some folks just discovering for the first time. Because of BPMN’s outward similarity to traditional swimlane flowcharts, many of those users think they understand BPMN but are making some fundamental mistakes. This month’s post attempts to set things straight by explaining the basic concepts of BPMN. Even experienced process modelers may be unaware of some of them.

Let’s start at the beginning. What exactly is a process? Dictionary.com defines it as “a systematic series of actions directed to some end”. Some key ideas there:

• actions. The steps in a process are actions, not functions, capabilities, and other things that business architects like to talk about.
• directed to some end. A process seeks to achieve some result, at which point the process – we would say the instance of the process – ends. It is not a function performed continuously.
• systematic. A process follows some plan or rules. The sequence of steps is not random or ad-hoc.

BPMN is consistent with those ideas, but many swimlane flowcharts are not.

A BPMN process is a sequence of activities leading from some defined triggering event to one or more possible end states. All possible sequences leading from the start event to some end state are defined by the process model. Let me repeat that. A process model does not describe one possible path from start to end but all possible paths. That’s because a BPMN process is something performed repeatedly – not continuously – in the course of business. Each repetition, or process instance, has a definite start and end. That’s why not everything that BPM architecture calls a “process” qualifies as a BPMN process.

BPMN actually originated in 2002 as a business-oriented diagramming language for defining automated processes. To gain acceptance by business, it adopted the basic look of swimlane flowcharts, popular since the 1980s but just for documentation and analysis, not for automation. It was not until BPMN 2.0 that the diagrams were properly executable on an automation engine, but even today the vast majority of BPMN usage remains for documentation and analysis not automation. Nevertheless, the basic concepts of BPMN are rooted in process automation, in fact, a particular style of process automation called orchestration. A BPMN process is an orchestration.

In a BPMN process, the world is divided into three parts:

• performers, sometimes called resources. Performers, usually people but sometimes IT systems, are the actors that perform the process activities. They are members of the organization that provides the process. In the process diagram, swimlanes (the BPMN term is lanes) may be used to distinguish performer roles or organizational units.
• the process engine, sometimes called simply the process. This is a key orchestration concept, very real in automated processes but just imaginary in non-automated processes. The process engine is the thing that understands the rules defining the sequence of activities and, as each activity completes, directs the flow to the next one. It is the process, not the performers, that controls the sequence of activities.
• external entities. These are everything that is outside of the process, including customers, service providers, trading partners, and regulators. They interact with the process but are not members of the organization that provides the process. Each interacting external entity is called a participant, and is represented in the diagram as a rectangular shape called a pool. BPMN assumes that the process engine is unaware of the internal processes of an external entity, so the pool is “black box” (i.e., empty), defined only in terms of its interactions with the process, called messages. The process itself is a participant in the interaction, and its elements may optionally be enclosed in a pool shape as well, labeled with the name of the process (not the organization). A participant is NOT the same as a performer.

These concepts come from the BPMN spec. One important concept that comes from traditional business process management, not from the BPMN spec, is that the sequence of activities contained in a process should describe an end-to-end customer-facing transaction, cutting across departments and roles within the organization that provides the process. In other words, an order handling process should begin on receipt of the order and complete with fulfillment and billing (or equivalent accounting) for the order. Order entry, fulfillment, shipping, and billing should not be separate processes, but part of a single cross-functional process in which the process instance represents a single order. The reason is that BPM as a management discipline believes that business should be measured and managed from the perspective of these end-to-end processes rather than siloed departmental functions. BPMN supports this idea, but the spec technically does not require it.

Sometimes a single business process must be modeled as multiple BPMN processes, but this is not because they are performed by different units within the organization. The reason this could happen is if there is not a one-to-one correspondence between the instances of the processes. Within a BPMN process the instance of each activity must have one-to-one correspondence with the process instance. For example, in a process where the instance is an order, the instance of each activity must be an order. That means an activity that updates prices every month cannot be contained in the order process, since its instance is performed once a month not once an order. It requires a separate process that runs monthly.

Representing all the steps of an end-to-end process in a single diagram takes a lot of space, more than fits on a single printed page. BPMN allows a sequence of activities to be represented as a subprocess, shown in two ways: collapsed, as a single activity shape in one diagram, and expanded, as a flow from start to end in a second diagram with a child-to-parent relationship to the first. Thus an end-to-end BPMN model is in general not a single diagram but a hierarchy of diagrams, with a single top-level diagram hyperlinked to child- and grandchild-level diagrams detailing each subprocess. Where traditional flowcharting had to create separate high-level and detail-level models, difficult to keep in sync as the process evolves, BPMN provides both high-level and detail-level views within the context of a single model.

While the BPMN spec describes many different types of start events, in practice a process starts in one of only three ways:

• On external request. This is by far the most common, and represented in the diagram by a message start event. The request itself is drawn as a dashed connector, called a message flow, from a black-box pool.
• On a schedule, either one-time or recurring. This is represented in the diagram by a timer start event.
• Manually by a performer. Unfortunately BPMN has no manual start event, so this is represented in the diagram by a None start event (no trigger).

Thus it is possible to interpret how the process starts simply by the trigger icon in the start event.

The ability to understand the process behavior in detail simply by inspecting the diagram, unfortunately, was not top of mind in the BPMN 2.0 task force in 2010. They were solely focused on making the diagrams executable on an automation engine. But to most BPMN users today, precise description based on the diagram alone is much more important. That requires additional conventions on top of the concepts and rules of the spec. The ones I use are called Method and Style. Much of the need for BPMN Method and Style arises from the fact that the process behavior – which path out of a gateway is taken, for example – depends on the values of data objects. But BPMN 2.0 removed data objects from the modeler domain and moved them to the Java programmer domain, so they are not used in non-executable models. To compensate for this, Method and Style’s conventions assign meaning to things that are actually used in non-executable diagrams, such as the labels on end events and gateways or the icon of a start event.

For example, in Method and Style the label of an end event of a process or subprocess indicates its end state, meaning how did it end, either successfully or in some exception state. Each distinct end state is represented by an end event, so the count of end events represents the count of distinct ways it could end. Method and Style says a subprocess with multiple end states MUST be followed by an XOR gateway with an identical number of gates, each labeled to match the end state label. This indicates the path taken by each instance. So if an instance reaches the subprocess end state Report approved it follows the gateway path Report approved, and if it reaches the end state Report rejected it follows the gateway path Report rejected. Conventions like this allow common understanding of the process flow without defining data objects.

BPMN Method and Style provides a list of style rules intended to make the process behavior precisely described from the printed diagram alone. To reinforce these rules, some BPMN tools, including Trisotech Workflow Modeler, include Method and Style validation. In my BPMN Method and Style training, this has proven extremely valuable in raising the quality of BPMN models. You should check it out.