Blog Posts BPMN DMN

BPMN 101: What Is a Process?

Blog: Method & Style (Bruce Silver)

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 it 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? defines it as “a systematic series of actions directed to some end”.  Some key ideas there:

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:

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:

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.



Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples