BPMN Modeling Best Practices

Business process modeling practice is not yet mature and common modeling mistakes can make models difficult to understand, and even incomprehensible. Business Process stakeholders may not support modeling initiatives if diagrams produced are to complex and inconsistent.

Some individuals consider process modeling more an art than a science. In addition, design methodology are often the field of process though leaders, solution vendors, and consulting firms. These methodologies mainly focus on project management and organizational issues of process modeling or design initiatives. They often fail to address the ground work of process modeling itself. In response to such omission, it is important to consider modeling best practices.

A best practice can be seen as a successful way to treat a particular problem that may need to be adapted in skilful ways in response to prevailing conditions.

Following are commonly proposed process modeling best practices, regrouped by topics.

Process Scope

You should clearly define the scope of the Process by identifying the “Who”, “What”, “When”, “Where”, and “Why” of your process. The Process captures the “How”.

It should be clear what each instance of your process represent. The process instances are discreet and identifiable, therefore you can refer to each one of them and can count them if desired.

The potential alternative ways to trigger the Process should be identified, using Start Events. The potential alternative end states of the instances of the Process should also be identified using End Events. In BPMN, Start and End Events are optional. However, processes with implicit start and end events are undesirable and could lead to misinterpretations. Use Start and End Events in each Process and Sub-process to represent its beginning and completion.

Diagram Layouts

Aim for BPMN Diagrams that fit one page. The top-level diagram shows the whole Process on a single page, and Sub-processes can be used to expand process detail at nested diagram levels, so you can zoom in and out of your model to describe any level of detail.

You should create alternative visualizations of the same Process for different communication purposes and stakeholders. For example:

• A summary Diagram with all Sub-processes and Call Activities collapsed and not showing any Data Objects.
• A verbose Diagram with all Sub-processes and Call Activities, showing Data Objects and Annotations.

Layout your BPMN Diagrams neatly to ease readability. Diagrams can become unreadable and very confusing when the process logic is not explicit and clear. Avoid crossed lines and keep a consistent direction of flow. The diagram reading will be easier and its communication efficient.

Use consistent layout with horizontal Sequence Flows, and vertical Message Flows and Associations when your draw horizontally. BPMN Diagrams are not strict temporal orderings, as it is possible to loop back, but most readers expect a left-to-right ordering.

It should be clear what the primary scenario, the “Happy path” of the Process, is.

Whenever possible, externalize the business rules from the Process using Business Rule Tasks to create more concise and more agile Process models.

Remember that a BPMN diagram is obscured by:

• Long, meandering, crossing lines.
• Mixed flow of the primary and alternative scenarios.

Process Partitioning and Structure

A business process modeller should create a hierarchical Process model with multi layers of details for the Process. BPMN Sub-processes are used to split the Process into “phases” or “layers”. Use BPMN Call Activities to re-use other Processes or fragment of these Processes into your current Process.

Start and End Events

Explicit instantiation and termination of the Process should be enforced by always using Start and End Events.

Alternative instantiations of the process should be depicted with separate Start Events. Success and failure end states in a Process or a Sub-process should be distinguished with separate End Events. Flows that end in the same end state should be merged to the same End Event.

Gateways

To make it explicit, always use Gateways to depict split or merge of flow.

Do not mix Gateway types when both diverging and converging flows. For example, when a flow is divided with a Parallel Gateway, the resulting parallel flows should be consolidated via another Parallel Gateway if or when required.

Always place an Activity that determines the diverging condition(s) just before a diverging Gateway of type Exclusive, Inclusive and Complex. A benefit of this best practice is that this decision Activity can now be interrupted if need be.

Abstract multiple daisy-chained diverging Gateways into a Business Rule Task, simplifying potential overloaded diagrams.

Collaborations

Do not model the internal process under focus into a Pool. Without a pool to label, one will not have the opportunity to fall into the bad practice of naming the Pool with the Process Name.

Message flows can add valuable business context to your diagram, but it is important to use them consistently. For example, if you are going to show any message flows from and to a requester of your process, you really should show all of them, and show them consistently in each level of your model.

Other considerations

Make the process logic visible in the diagram by adequately labeling diagram elements and by showing the exception handling logic explicitly in the diagram. BPMN provides a business-friendly notation for describing exception-handling behavior. Even though the BPMN specification gives the modeler great freedom, best practice is to learn specific diagram patterns to distinguish each type of exception, and use them consistently.

Make sure your model is valid. If you want others to understand your model, you need to start by making it valid, so you should validate with appropriate tools, peer reviews, etc.

Keep a unique format along your diagrams and focus on a clean and friendly look and feel. Using different font sizes, colors, boxes sizes or overlapping labels might make the diagrams reading a challenge.