Business Process Model and Notation (BPMN) is already acknowledged as a de facto standard for business process modeling. However, it still takes a long journey to increase the maturity of business process modeling practice. In practice most business analysts do a lot of mistakes that make their BPMN models over complex, difficult to understand and maintain. Therefore, it is important to understand the common mistakes, which we refer to as anti-patterns, and how to get rid of them applying best practices. Practitioners learn best in an example-driven approach.
In this series of posts we will explore several cases presenting real-life business process examples representing common anti-patterns in business process modeling and demonstrating how to improve the examples by applying best practices.
Anti-Pattern #1: Inconsistent Naming
The first fundamental thing that needs to be reviewed is BPMN element names. It is quite typical that modelers use nouns for naming activities or use different naming style for the elements of the same type in different places. As several philosophers stated, “the language we speak shapes our thinking”. This applies well to business process modeling context – it is very often that modelers misuse BPMN elements, which is reflected in inconsistent naming. Table examines some typical anti-pattern in naming and corresponding best practices/patterns.
Some Naming Anti-Patterns and Best Practices
|Noun based activity name – indicates that element is an event, data object, or process area as opposed to activity.||Strong verb + domain specific noun – emphasizes achieving a discrete goal after performing work.|
|Gateway named as activity – indicates that a gateway represents a task, which determines the choice.||Unnamed gateway – it is merely a branching element that does not perform any work, so it should not be named (except for referencing).|
|Words and/or in activity name – indicates multiple activities captured in one activity.||No conjunctions in names – raise name abstraction level or split into two subsequent/alternative activities.|
|Long activity name – indicates that details of activity are emphasized instead of the goal; orients diagram towards textual document.||Short name + documentation – the name should emphasize the goal, and details of activity can be captured in comments or documentation.|
For an experienced business process modeler, solving naming conventions may seem to be easy. However, in practice we face inconsistent naming issues in almost every organization that adopts BPMN as a standard for specifying business processes. A typical case of business process model with anti-patterns presented in Table and refactoring it is presented in Figure.
We analyzed only a few most common naming issues – in practice, you will also face problems with inconsistent naming of events, data objects, participants, messages, etc. For organizations that are adopting BPMN as a standard, it is highly recommended to establish naming guidelines and perform regular review of BPMN models to ensure that these guidelines are followed.
The case was made by and the examples are taken from extensive authors’ (Darius Šilingas, Ph.D. and Edita Milevičienė) consultancy in financial, telecommunication, government, and information technology domains helping No Magic customers to adopt MagicDraw and Cameo Business Modeler products for efficient business and software modeling.