blog

BPMN Style Rules

Read Time: 6 Minutes

When BPMN 2.0 was developed a decade ago, the task force’s primary goal was making BPMN models directly executable on an automation engine, something that wasn’t exactly possible with BPMN 1.x. Consequently, the rules of the BPMN spec focused almost exclusively on “operational semantics.” In doing so, they lost sight of what the majority of BPMN users cared about much more, which is making the process logic clearly understandable from the diagrams. The spec had no rules to enforce that or even encourage it.

Method and Style

I developed the Method and Style approach to BPMN modeling to address that problem, in particular, the “style rules”, which complement the rules of the spec. They are not official, just what I consider best practice if the goal is to communicate the process logic clearly, completely, and consistently from the diagrams. (Students in my BPMN training must use them in their certification exercise if they want to pass.)

Trisotech BPMN Modeler can check models automatically for style rule violations in one click. On the BPMN ribbon, just click M&S Style Validation. That is really useful, both for improving your process model quality and internalizing the rules.

Original EU-Rent Customer Support

According to the rules of the spec, the Trisotech EU-Rent examples are valid, but they were not created following Method and Style. The original Customer Support model, for example, has many style rule violations. A good way to illustrate Method and Style is to compare the original model with an updated one that follows the style rules.

Version 1.1 of the model is shown below. If we click M&S Style Validation, we see it has 17 style errors. That’s quite a few! In this post, I will explain the issues and fix the model to conform with Method and Style. (Note: To access a particular version, from the File/Open dialog, right-click the model name and select Versions. If you don’t do that, the tool opens the current version.)

Figure 1. Customer Support model (original)

Figure 2. Style errors in the original model

Structural Issues

Before dealing with the specific style errors, there are structural issues with this model. A BPMN model may depict interactions between a process and other entities, such as additional processes or abstract external entities. Such a depiction is called a collaboration model. In a collaboration, the process and each of the other entities are called participants. The term participant is often misunderstood by modelers. It does NOT mean the performer of a process activity. A participant simply means a party involved in the collaboration. Each participant is represented in the diagram as a pool. Participants interact with each other through the mechanism of message flow, the dashed arrow in the diagram. This is all from the spec, not Method and Style. It’s just that the spec doesn’t explain it very well.

A process model normally describes a collaboration from the perspective of a single process. That means that participants other than the process are depicted abstractly as black-box pools. Black-box pools are empty, identified only by the participant name in the pool header. They contain no lanes, no activities or flow nodes of any kind. Interaction between the process and a black-box pool is visualized entirely through message flows connecting the pool with a process node.

Separate roles or departments within the organization providing the process should be modeled as lanes within a single process pool, NOT as separate pools. Lanes identify the performer of the activities they contain. Normally a collaboration model contains a single process pool, which may contain multiple lanes, interacting with one or more black-box pools via message flow. The only time a single logical process is modeled as multiple process pools is when the instances of the pools do not have 1:1 correspondence. Let’s leave that topic for a future post.

In this EU-Rent model, the pool labeled Customer Support and the pool labeled 2^nd Level Support Agent should be lanes within a single process pool, not separate pools. Also, the pool Supplier should be black-box. The Customer Support provider doesn’t really know what the Supplier’s process is. He just knows the message flow interaction with the Supplier. As you will see, there is no significant information lost in making Supplier a black-box pool.

In the Method and Style version of this model there is thus one process pool, Customer Support Process, containing two lanes, 1^st Level Support Agent and 2^nd Level Support Agent, and two black-box pools, Customer and Supplier.

Labeling

Many of the style rules concern labeling. Labels are extremely valuable for communicating meaning, but the BPMN spec does not require anything to be labeled. What were they thinking? Here are the basic style rules concerning labeling:

All activities – including subprocesses – should be labeled, preferably as an action, verb-object.

Message flows should be labeled as the name of the message, a noun, not as an action (verb) or state (adjective phrase). For example, Info Request is a good name for a message flow, not Send Info Request (an action) or Request Sent (a state). Also, a message flow to or from a child level must be replicated in the parent level, connecting to a black-box pool of the same name. Style rule validation checks for this. When you add a pool to a child level that has the same name as a previously defined pool in the parent level, the tool will ask if you intend these to represent the same participant. In Method and Style, the answer is YES.

Message start events should be labeled “Receive [name of message flow]”. Timer start events should be labeled with the frequency of occurrence. All intermediate events should be labeled.

In Method and Style, end events represent distinct end states of a process or subprocess. If a process level has more than one, each should be labeled with the end state name, an adjective phrase, such as Issue resolved. If there is only one, it should not be labeled.

In Method and Style, the gates of an XOR gateway represent the end states of the activity immediately preceding the gateway. The activity’s end state – an adjective phrase – simply means how did the activity end. Each activity end state corresponds to a different next step following the gateway.

The end states of a task are indicated by the labels of the gateway following the task. For example, Get issue description in the original model has three possible next steps, meaning it has three end states. Thus it should be followed by an XOR gateway with three gates, each labeled with an adjective phrase naming the end state. When there are two next steps, meaning two end states, an alternative labeling is allowed in which the XOR gateway is labeled as a question – typically the success end state followed by a question mark – with gate labels Yes and No.
When a subprocess has multiple end states, the child level diagram will have a separate end event for each, labeled with the end state name. In the parent level, the collapsed subprocess is followed by an XOR gateway with gates matching those end event labels. Style rule validation checks for this.

Note the XOR gateway labeling rules do not apply to OR gateways. The gates of an OR gateway do not represent distinct end states of the preceding activity.

The gates of an AND gateway or event gateway should never be labeled, nor should the gateway itself. Merge gateways also should not be labeled.

Other Style Rules

In the original model, the subprocess Escalate issue is missing start and end events. This notation, involving so-called implicit start and end nodes, is allowed by the spec under certain conditions, but not in Method and Style. In Method and Style, all flow nodes (except event subprocess) must lie on a continuous chain of sequence flows, within a single process level, leading from a start event to an end event.

In the original model, style error [0005] says the model should not have more than 10 activities in a diagram. This one has 11, but the reason here is that there are activities in Supplier, which should be black-box. The intent of the rule is no more than 10 activities in a single process level, so when printed it fits on a single page.

EU-Rent Customer Support with Method and Style

Version 2, the fixed model, is shown below. M&S Style Validation shows 0 errors. Both versions of the model are available in the EU-Rent repository. Readers are invited to compare them and explore the working of the M&S Style Validation feature.