Efficient BPMN: from Anti-Patterns to Best Practices



Sponsored by:

No Magic Inc.

No Magic, Inc.

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 article 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.

The examples are taken from extensive authors’ 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. It is important to note that MagicDraw and Cameo Business Modeler enables modelers to specify model validation rules that enable automated detection of some anti-patterns. The presented business process examples are specified at analysis level, i.e. without properties providing technical details for process automation. For simplicity, only a small number of BPMN elements are applied, which is usually sufficient for business analysis purposes.

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 1 examines some typical anti-pattern in naming and corresponding best practices/patterns.

Table 1 -  Some Naming Anti-Patterns and Best Practices 

Anti-Pattern                   Best Practice
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 per-form 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 1 and refactoring it is presented in Figure 1.

Figure 1 - Business process “Make Loan Proposal” with inconsistent naming and an improved version complying with naming best practices

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.

Anti-Pattern #2: Large Process Diagrams

The second fundamental thing that needs to be reviewed is the complexity of process diagrams. While BPMN supports modeling processes in multiple levels of detail, many practitioners are used to “everything in one page” style, which impairs overview and makes it difficult to understand and analyze the process. Psychologists have determined that the best number of visual elements to focus on in one diagram is 5±2. In practice this rule is rarely followed. We think that it is quite practical to increase this number to 7±4, but consulting various organizations on business process modeling, we have seen extreme cases of business process diagrams with up to 450 (!) tasks. Such large diagrams make it very difficult to analyze them and spot the issues – the value of visualization is lost. In Figure 3, a presented example of a large diagram contains a number of inconsistency issues such as lack of Confirm Seminar activity that is symmetric to existing Cancel Seminar activity, a non-ending loop for registering participants after Decision Deadline, uneven levels of detail for announcing seminar (the first four tasks) and canceling it (one compressed subprocess), no clear distinction of early and late registration and others. However, it is rather difficult to spot such issues if you are analyzing a large complex business process diagram – you are happy that you have managed to read and understand it and do not question its quality.

Figure 2 - A large business process diagram Organize Seminar with 16 activities

A key best practice, which enables getting rid of complex diagrams keeping all the important information about business process tasks, is using several layers of detail. Figure 3 demonstrates an improved version of the example given in Figure 2, which uses subprocesses with additional diagrams assigned for each of them. In such an approach, you can decompose a very large (and typically inconsistent!) business process into a simple and consistent process structured in several levels of detail. For example, a business process with three levels of detail following the rule of up to 10 activities in one level may contain 103 = 1000 tasks.

Figure 3 -  A improved business process diagram “Organize Seminar” with 7 sub processes and sub process “Announce Seminar” specified in a separate diagram


Anti-Pattern #3: Inconsistent Use of Gateways

Gateways are very important as they control the branching of a business process sequence flow based on data or upcoming event(s). They also specify a connection point from the sub process end events to the external process. In practice, we see a lot of issues in using gateways. Often gateways are omitted and multiple sequence flows go in to/out of an activity, which impairs readability and interpretation. In our opinion, a frequent convention of using a question for a name of a gateway and Yes/No on branched sequence flows is wrong because it makes it impossible to connect the gateway names to the names of end events of a preceding sub process (Yes and No are not very good names for the end events). Also, we observe a frequent misunderstanding on how to use event based gateway and workflow patterns related to it. In Table 2, three common anti-patterns in using gateways are presented together with corresponding best practices, and Figure 4 show fragments of a business process before and after applying best practices.

Table 2 - Typical Gateway Usage Anti-Patterns and Best Practices

Anti-Pattern Best Practice
Multiple incoming/outgoing sequence flows – makes it difficult to understand how many flows are re-quired to come out/in. Always use gateways for branch-ing/merging – improves readability of the diagram and explicitly indicates control points.
Event-based gateway with outgoing sequence flow unconnected to event – makes it ambiguous when the alternative sequence flow should be taken. Apply Deferred Choice pattern – all the sequence flows after event-based gateway should be connected to events. Use timer event to model cases when expected event does not happen.
Gateway unsynchronized with preceding subprocess ends – shows inconsistency between sub process details and its usage in a larger process. Apply Internal Business Error pattern with synchronized end/branch naming – makes it very straightforward to consistently use gateways and sub processes.


 Figure 4 - A fragment of a business process “Sell Licenses” with anti-patterns and an improved version complying with best practices

Anti-Pattern #4: Inconsistent Use of Events

Events are fundamental elements in BPMN – each process begins with a start event, finishes with one or more end events, and potentially reacts to a number of intermediate events happening during the process. While events themselves are not very tricky, deciding at which process level to put the event initiating a process or choosing a proper scope of an intermediate event might be done incorrectly. In Table 3, we list two common anti-patterns with events usage and the best practices for improving them. Figure 5 gives an example of a business process fragment with anti-patterns and after improvements according to the best practices.

Table 3 - Typical Event Usage Anti-Patterns and Best Practices

Anti-Pattern Best Practice
Event outside and inside processrepetition makes it redundant; a formal interpretation would require the event to happen twice. Initiating event out of process de-scription it is easier to read a dia-gram and understand when/why a sub process needs to be performed.
Repeating eventscomplicates dia-gram and its maintenance. A subprocess with attached eventenables to clearly define the scope of an event.


Figure 5 - An example of a business process Administer Bad Loan fragment with anti-patterns in events usages and an improved version complying with best practices

Anti-Pattern #5: Poor Diagram Layout

Last, but not least, in practice there are many issues with business process diagram layout. You can spot many anti-patterns like different sizes of similar type elements, uneven spaces between elements, long, bended and crossing lines, etc. All of these anti-patterns in layout do not change the content of the business process but they make a diagram very difficult to read and understand. Figure 6 represents a typical layout, which contains many of these anti-patterns. The diagram can be improved to comply with the best practices in layout as presented in Figure 2, which was already used to explain multiple levels of details. One very important issue in Figure 6 is so called “slalom” – a lack of consistent direction of flow, which among other things makes it very difficult to differentiate the main and alternative scenarios.
In Western culture, a typical flow should be oriented either top down or from left to the right. We prefer top down as the first direction because it enables to balance use of space – the activity names’ text naturally flows from left to the right, and the sequence flows then progress in a top down direction. Missing a clear direction of flow also indicates that the modeler probably captured all the details at once, while a best practice is to address the primary ‘happy day’ scenario first and address alternative scenarios only afterwards.

Figure 6 - An example of a poor layout diagram for a business process Organize Seminar containing various layout issues such as slalom, different symbol sizes, uneven spacing and bended lines (see Figure 2 for a refactored version)


We have analyzed five practical cases presenting original business process model examples suffering from particular anti-patterns, suggested best practices that help to get rid of these anti-patterns, and improved the original versions into better quality business process models that comply with the best practices. The presented cases deal with inconsistent naming, large process diagrams, inconsistent use of gateways, inconsistent use of events, and poor diagram layout. We think that such example based approach to analysis of typical anti-patterns and resolving them is the most efficient way to teach business process modeling best practices. The presented anti-patterns should not be treated as an extensive list but rather as examples of a starting initiative. We hope that this paper will motivate more research and publications on improving BPMN models in both breadth (other cases) and depth (more technical details) directions.

About the Authors

Darius Silingas is the Head of Solutions Department at No Magic Europe. He helps organizations adopt the MagicDraw / Cameo modeling platform for efficient software and business modeling. Darius has delivered over 200 training and consultancy sessions in 20 countries, spoken at numerous conferences, and written multiple articles on software and business modeling. He is the chair of a local conference on BPM Practice, which annually takes place in Vilnius, Lithuania. Darius holds a Ph.D. in Computer Science and is an OMG Certified UML Professional and Expert in BPM. In addition to his work in the industry, Darius is a part-time Associate Professor in Vytautas Magnus University, and a visiting lecturer in the BPM program at ISM Executive School. Darius can be reached by e-mail at [email protected].

Edita Mileviciene is a Product Manager for Cameo Business Modeler, a plug-in to the MagicDraw modeling platform enabling BPMN 2.0 modeling capabilities. Edita has been working on the MagicDraw RD team since 2002 in various roles: QA engineer, analyst, and product manager. Edita is also an experienced UML and BPMN consultant, and regularly runs online and onsite trainings for MagicDraw customers worldwide. She holds a master’s degree in Computer Science from Kaunas University of Technology and is an OMG Certified UML Professional and Expert in BPM.


  1. No Magic World Conference 2013 – a premier conference in Allen, TX on February 17-20, 2013 focusing on modeling practices. This year the conference features a strong Business Analyst track, which offers tutorials, case studies, and technical sessions on BPMN, UML, business process, data and rules modeling, Enterprise Architecture, Business Architecture, privacy and security. The speakers include John Zachman (father of Enterprise Architecture), Kevin Brennan (Executive VP of IIBA), Richard Soley (President of OMG), Jim Arlow (author of best-selling books on UML, BPMN, MDA and other modeling topics), Darius Silingas (modeling guru from No Magic) and other worldwide regarded experts. Don’t miss a chance to learn best practices and modern trends in business analysis and build relationships with these experts and other conference participants – No Magic conferences are well known for excellent social program and networking opportunities!
  2. Powerful Business Modeling with No Magic’s Cameo Business Modeler @ Modern Analyst – a previous article from No Magic, which discusses the same case study, yet, focuses on Business Architecture without a connection to Software Architecture
  3. http://www.nomagic.com – for the No Magic homepage where users can find more information on MagicDraw and the Cameo Suite
  4. http://www.nomagic.com/products/cameo-business-modeler.html – specific No Magic webpages for the Cameo Business Modeler solution
  5. http://www.bpmn.org – resource for more information related to Business Process Model and Notation (BPMN) specification
Like this article:
  30 members liked this article


Tony Markos posted on Wednesday, January 2, 2013 4:07 PM
Multi-level BPMN? Ya, ya, ya, I've read that currently popular BPMN book that says that BPMN allows for unlimited decomposition (i.e., multi-levels).

But decomposing a problem without fully understanding the essential interrelationships - the data flows - between the pieces of the problem will, especially on a larger scale effort, create an inappropriate structure that impedes analysis.

Darius Silingas posted on Saturday, January 5, 2013 9:57 AM

Good point about data flows, which is rather neglected in BPMN. You are right - there is no clear approach how decompose BPMN processes taking into account they data parameters. Other modeling languages, e.g. UML and SysML, enable you to be more specific and precise on this aspect. BPMN was created as a simpler alternative to UML and SysML for users who focus on sequence flow. If you need more precision in data aspect, I would recommend exploring UML or SysML. These are languages that my customers are using when they model missiles, train control systems, medical devices, etc. But despite of your concern, the same principles apply. I have seen UML and SysML users making exactly the same mistakes and the same best practices help to avoid them.

Darius Silingas
Travis Barker MPA GCPM posted on Sunday, January 27, 2013 2:07 PM

Thanks for the article. It was an interesting read.

I think you make a valid point about the contributions of language and diagramming towards complex and misapplied business process methods. The often proprietary like language used to describe and explain Business Analysis erects a barrier to its adoption and the accuracy of its intended implementation.

I have found that thee Business Analysis methodology frequently incorporates models, methods, strategies, and technologies already available to other models but through the process of incorporation attempts to sever these previous relationships through the use of a paradigm that is defined in isolation from the history of its construction.

Where this proprietary like vocabulary becomes more appropriate, although not necessarily essential, is when the Business Analysis methodological systems seek to unearth granular insights that exceed the intent of the historical models that preceded the effort.

Although I am unfamiliar with the 5+2 rule mentioned, or the 7+4 rule subsequently proposed in the article, I am able to agree that the cognitive research has been able to establish that 7 plus or minus 2 overarching concepts, under which granular details is exercised, aids analysis, synthesis, retention, and recall. The comment that this principle will aid the diagram’s efficacy is well warranted and insightful. Utilization of memory research could likely contribute other insights into best practices for process modeling.

Consistency, when the 7 +/- 2 rule is adhered, could benefit from the planned and structured peer review process mentioned in another article on this sites. Iterative process and diagram modeling could also aid the retention and implementation of the identified process when non-ideal complexity is inevitable; sometimes the details are critical.

The Business Analyst methodology could aid the essential spanning of systems that is necessary to insure consistent modeling of processes, language, and requirements congruent with your insights to aid further support the same. The corporate culture and architecture have a strong influence on the Business Analyst’s ability to incorporate the consistency required of the BPMN.

Thanks again for the article. I found it quite insightful.

Travis Barker, MPA GCPM
Darius Silingas posted on Sunday, January 27, 2013 3:11 PM

Thanks for a positive feedback to our article.

I totally agree that practices like structured review, pair modeling and similar contribute to better quality models. There is a lot to discuss regarding business modeling practices. I believe that building a sustainable business modeling culture, which incorporates all such practices, deserves a separate article. In this article we focused on analysis of bad examples and how to improve them.

Darius Silingas
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC