Introduction
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 process – repetition 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 events – complicates dia-gram and its maintenance. |
A subprocess with attached event – enables 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)
SUMMARY
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.
References
- 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!
- 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
- http://www.nomagic.com – for the No Magic homepage where users can find more information on MagicDraw and the Cameo Suite
- http://www.nomagic.com/products/cameo-business-modeler.html – specific No Magic webpages for the Cameo Business Modeler solution
- http://www.bpmn.org – resource for more information related to Business Process Model and Notation (BPMN) specification