Although many big organizations still use the written word to describe their processes and requirements, a significant amount of evidence suggests that pictures are a better way to communicate. This is where modeling languages come in. Modeling languages allow companies to show their processes pictorially to minimize error and miscommunication. They can also be used to delineate responsibilities, find areas for improvement, and plan for future changes.
In this article, we look at business process modeling and notation (BPMN) as a standard of modeling languages for enterprises. We’ll discuss what it is, what it was, and how it should be used. We’ll review BPMN elements and extended elements in detail, as well as provide guidelines for modeling and tips for using the notation. We present examples of BPMN models, and finally, we’ll offer a method for choosing a BPMN tool.
Process modeling notation is a language that’s readable to humans and that describes the structure and elements of a business sequence. The vocabulary is defined, and the language is organized such that we understand how it should flow and how the information is presented. As a data science, process modeling notation includes about 40 different elements, delineated with rules about their use.
This language tells stories about our work. By creating a model similar to a flowchart with this language, a business can capture, analyze, understand, automate, and even optimize their processes. As with any language, it’s important to learn the terms and rules of grammar. Since the 1960s, countless notations and their varying structures have come and gone. When it comes to a modeling notation, experts recommend that you choose a standard that is based upon your purpose, that it is supported by a wide number of tools, and that comes with training and references.
Business Process Model and Notation (BPMN) is a standardized graphical notation that is used globally for business process modeling. It is open source, which means that the original code is available for anyone to change and use. The specification defines its symbols and shapes precisely.
BPMN starts and ends with the business process flow diagram. This is a technical map of an organization’s flow and practices, presented in a standardized language, and available for users to improve, share, and follow.
The Object Management Group (OMG), a nonprofit technology standards consortium, governs and maintains BPMN. OMG offers several certification programs, including the OCEB Certification (OMG Certified Expert in BPMTM) for BPMN. The field of business process management (BPM) approves of standardization and often uses software (BPMS) that includes the BPMN language. Some are low-code platforms, meaning that the business can configure its BPMS to work with its incumbent software and needs.
The BPMN language is not owned by a commercial enterprise, though Trisotech is a commercial software and consulting company that helped develop BPMN by building on its standards internationally. It has also been involved in developing and setting BPM standards, XPDL, BPSim, and CMMN, and is considered a leader in BPMN consultation.
At its core, BPMN is intuitive. Even when staff members do not understand the exact symbols, they can figure out the meaning of the workflow. However, for more advanced users, the nuances are apparent. For example, in the simple process below, Lane 1 starts a task. This could be your company, which is the pool. Your department is Lane 1, which starts the process and completes the first task. The work is then sent to another department (in Lane 2), which sends it back for Task 3 and completion. This seems more complex with the standardized language, but if you add names, it is very clear. You can model this simplicity throughout your processes, even those that appear very complex.
A simple BPMN process map
The OCEB 2 Program has five examinations, each offering a certification. After the Fundamental level, there is a track for business and another for technical. In the BPM world, these certifications assure employers that you understand not just the principles, but also the practice of BPM. The OCEB 2 Certification was designed by 25 BPM professionals from the commercial industry, with the intent of providing this assurance to their peers and prospective BPM employers. The certification gives BPM practitioners an edge over their uncertified competitors.
Different users of BPMN describe it as simultaneously complex, simple, prohibitive, and helpful. There are certainly times when you will prefer to use this standardized language. Three reasons you would want to use BPMN versus another notation include:
OMG merged with the Business Process Management Initiative (BPMI), the inventors of BPMN, in 2005. Since its inception, five releases of BPMN have followed. BPMN 2.0 arrived in early 2011. The five versions and their dates of release are below. Each version is linked to its official specifications.
BPMN was originally a modeling notation that was meant to give all stakeholders, from high-level decision makers to technical staff, a standardized language for diagrams. But with the release of version 2.0, BPMN became about models and notation. The difference is that instead of standardized models alone, BPMN offers a standardized XML (Extensible Markup Language) schema that can map between software tools. At this time, more than 80 tools support BPMN.
OMG originally developed the Business Process Definition Metamodel (BPDM) as a bridge between BPMN and software. BPDM describes the rules, constraints, and theories of BPMN so that software programs can map and use it with an XML syntax (such as the Business Process Execution Language, or BPEL). The originators thought users should be able to move process models from one modeling tool to another without losing information. According to OMG, “By providing a common, syntax-independent vocabulary for business process concepts, BPDM standardizes the way BPMN diagrams are stored and exchanged.” However, according to experts, the advent of BPMN 2.0 negates the need for BPDM. Further, experts say that BPEL does not fully support BPMN.
BPMN 2.0 also improves the following:
Example of choreography diagram. The choreography diagram in the center represents the communication between the pools.
Example of conversation diagram. Conversations diagrams show a different view and incorporate two new elements: the hexagon and the double line.
According to some experts, not everything in BPMN 1.0 has a partner in BPMN 2.0. However, software packages are available that provide migration pathways to update older models.
OMG states that there will not be another version of BPMN for at least two to three more years. Since many users want a stable long-term platform, OMG is not in a hurry to get to BPMN 3.0. In 2014, OMG did release a complement to BPMN called the Decision Model and Notation (DMN), which provides a separation in the decision and the process. DMN was designed to work to connect with BPMN as a schema model in XML format via the identified processes and tasks, as well as through the decision knowledge base data type. In other words, BPMN shows the processes, while DMN models show how decisions are made in the processes.
BPMN’s main goal is to be a notation that all users can understand. This includes not only the businesspeople who manage all of the processes, but the business analysts and the technical developers. Other goals of BPMN include:
Your BPMN diagram should represent not only business process activities, but can and should show the following:
Many organizations strive for interoperability, where different software applications and IT systems are able to communicate, exchange data, and use the information and knowledge from the exchanged data. You can consider interoperability from three perspectives: private business processes, public business processes, and collaboration business processes. For IT, these perspectives are important for the ability to exchange data.
Private business processes detail:
Public business processes:
Collaboration business processes:
This makes sense in BPMN, because part of the purpose of BPMN 2.0 is to exchange BPMN models between different software systems. There are noted limitations on this interchange; these are intentional on the part of the designers of BPMN 2.0 because they wanted to ensure maximum flexibility. Visually, these include colors of shapes and text, shape decorations such as shadows, gradients, backgrounds, text wrapping, and thickness and style of lines. Semantically, these include proprietary extensions such as the script of a script task, user task implementation, and global user task implementation.
BPMN Constraints
For all of BPMN’s capabilities, it is specifically constrained to business processes. Some organizations and analysts assume that BPMN is a magic bullet for all of their process modeling needs. However, the following processes are not meant to be supported by BPMN:
These types of processes can be addressed in other UML models or additional documentation. It must be noted that BPMN models are not data flow diagrams (DFDs), which show the flow specifically of data information from one place to another. These diagrams provide only one view of a process through the data.
BPMN was designed so that all users can understand it: businesspeople, business analysts, and IT staff. Although the BPMN originators had these groups in mind during development, they were also concerned with how they could link BPMN to other OMG standards. Further, although the standard supports all of these professionals, not all professionals design to the same level.
Bruce Silver discusses three levels of BPMN users in the trainings that he conducts. Level 1 is your typical user who employs only a handful of symbols. Their diagrams are simple and conform to a very traditional standard. Some journals estimate that almost 90 percent of users are at this level of design. (This figure is referenced by many blogs and periodicals, but there is no specific study that supports it.) Level 2 users provide the layer that IT professionals can then add to. It is essentially a more advanced business process layout using less common
BPMN keeps elements of a business process model to a minimum so that the look and feel of the diagram stays as consistent as possible. You can always add more detail after the basic categories are complete.
There are two types of elements: descriptive and analytic. Within this framework, you’ll find over 40 different elements, each with rules about when they can and cannot be used. Business analysts developed descriptive elements to model processes as documentation, and technical staff developed analytic elements to model executable processes within the software.
The five basic categories of elements are:
1. Flow Objects. These define the behavior of business processes.
2. Data: These elements call out information about the activities. Data is either provided or stored for the activity.
3. Connecting Objects: These connect the flow objects to each other or to other information.
4. Swimlanes: In BPMN, a swimlane is an element that shows where the responsibility for the process resides, and a pool represents the participant. Lanes break apart the pool as a partition of responsibility, showing the location of activities. Lanes can also delineate phases (first phase, second phase, etc.). In other words, a pool is a container for a single process, and a lane classifies the activity within it.
Lanes do not have semantics in BPMN; they are merely a partitioning concept. You can arrange swimlanes either vertically or horizontally. Lanes are optional and may be nested. Some issues with swimlanes:
5. Artifacts: These are used to give extra detail about the process. The two standardized artifacts are:
6. Message: This element is shown in the tables in the specification guide for BPMN, but not put into a specific category. It is used in extended notation as well. A message represents communication between participants.
The five basic categories of BPMN elements.
Extended modeling elements take the basic elements, add notation, and change their meaning while still showing consistency. The following sections are a foray into extended elements. The elements shown are not meant to be exhaustive, but provide the most commonly used elements in BPMN.
An example of an extended element is the use of a Start Event. A message element is then added, and the meaning changes from plain “Start” to a “Start triggered by a message.” The extended modeling element in this scenario allows users to specify how the event begins, not simply that it has begun, adding to the detail in a process.
Events Extended
We know there are three type of events: start, intermediate, and end. These events can also be broken down into catching events, throwing events, and interrupting or non-interrupting events. A trigger defines catching events. Once the trigger is activated, the event starts. Throwing events are assumed by BPMN to trigger themselves. They do not react to triggers; instead, the process triggers them. Whether an event is interrupting or non-interrupting is related to the action. When an interrupting event is fired, the action is blocked. When a non-interrupting event is fired, the action continues.
Extended Event Sub-Processes
Activity Tasks, Sub-Processes, Transactions, and Call Activities Extended
You can add to tasks as well, with extra notation to show more specificity. The following image shows the notation and the meaning of each.
Three types of markers are specified for a task as well. These include loop, multiple instance, and compensation.
Loop tasks, sequential multiple instances tasks, and compensation tasks, respectively.
Sub-processes show lower levels or more detailed levels in a process event task. A collapsed sub-process is shown below:
Additionally, you can combine four types of markers with the sub-process marker. These include loop, multi-instance, ad-hoc, and compensation.
Transaction Sub-Process
A transaction sub-process is embedded. You can use it to group multiple activities and show that they either fail or succeed collectively. These groupings of processes are surrounded by a double border to show they are a transaction.
In the above example, the flow moves to a Cancel End Event in the case of an error due to unavailable bookings. This activates the process rollback, and any completed reservation activity will be undone. The tasks in this example are undone in the reverse order that they were completed.
Gateways Extended
Notation may be added to gateways to represent different kind of control behavior, such as making decisions, branching, merging, forking, and joining. The types of possible gateways are exclusive, event-based, inclusive, complex, and parallel.
Data Objects Extended
Data objects are available in processes and sub-processes. Aside from the main type of data object, you can add notation to indicate data input, data output, collection data item, collection data input, and collection data output. Data inputs and outputs relate to the entire process. Collection data relate to the actual collection of some type of information during the process.
From left to right: Data input, data output, data object collection, data input collection, and data output collection.
Connecting Objects Extended
The addition of extra notation to connecting objects can extend their usage in BPMN. These include conditional flows, default flows, exception flows, and compensation associations.
Conditional flows and default flows.
Exception flows and compensation flows.
Critics have written widely about BPMN and why it is not appropriate for widespread use. The majority of the criticism centers on BPMN’s complexity. With more than 100 unique elements (resulting from the five main elements and their additional notation), it is too much to learn, too easy to make errors, and too granular for business processes alone, according to critics. Further, doing BPMN for the sake of doing BPMN causes more harm than good.
Other risks of BPMN include:
Bruce Silver, who helped draft BPMN 2.0, says, “Business analysts should learn the semantics and rules, and that for most effective use the method and style of BPMN should also be learned.” Most professionals and organizations stick to a handful of symbols, so there is not much to learn. This in fact makes the notation simple. Diagrams can be extended for more granularities as needed, such as with an IT implementation. Further, BPMN is designed to model both human-centric and IT processes with equal accuracy. It also has the power and precision to display a clear vision of how your business works, saves time by showing unnecessary tasks, and reduces your employees’ rates of overlooked, forgotten, or poorly executed work.
BPMN diagrams have certain capabilities that other modeling languages do not. According to Silver, “Restricting BPMN to the part that is familiar from traditional process mapping is to miss its essence, which is the expressiveness required to describe not only the process’s normal or ‘happy path,’ but the various exception paths as well, and to do so with the semantic precision needed by IT to translate any proposed improvement into a working implementation.”
Essentially, Silver is saying that while it is well and good to model the few simple elements, the real value of BPMN lies in its capacity for the unusual circumstances (the exception paths) and to have those translated for automation. (Note: A happy path is the default scenario that features no exceptions or error conditions — the sequence of events where everything goes as expected.)
Even with the criticisms leveled at BPMN, it is still one of the most widespread and desired standards for process modeling available today. According to “The State of Business Process Management 2016 Report” from BPTrends, 64 percent of businesses surveyed are interested in adopting BPMN.
Process modeling guidelines are the same for any language or notation. In a 2009 paper on process modeling, authors Mendling, Reijers, and van der Aalst explain the main guidelines of modeling, regardless of the language used. They outline guidelines that may be considered best practices:
To take full advantage of the BPMN modeling language, use a tool. Although you can draw BPMN with a pencil and paper, doing so does not take advantage of the majority of its benefits. Software programs that specialize in BPMN allow users to model faster and easier, and it enforces the majority of the BPMN rules automatically. Software tools also decrease errors in the diagram, allow for easier reading on the human eye, and give the all-important capacity to capture the associated XML.
What are the recommended criteria in choosing a BPMN tool? At last count by BPMtips.com, there were anywhere from 70-100 tools that could fully support BPMN modeling. These include free, open source, and proprietary tools, as well as tools whose sole function is not BPMN, but support it anyway. To further complicate the selection process, a number of plugins to existing programs support BPMN modeling. The choice you make is critical because much time and money will be invested in not only learning BPMN, but in the production of the models.
Experts agree that if your business needs the standardization of BPMN, then the tool should first be able to claim BPMN compliance. For BPMN 2.0, compliance is defined within the ISO/IEC 19510:2013 standard. This ISO standard represents the best practices in business modeling. If the language is meant to be consistent in its meaning, it must first be standardized. In this, the tool must have four types of conformance:
Aside from actual BPMN conformance, one method to choosing a modeling tool is as follows:
It is clear that BPMN is a relatively simple, straightforward language that professionals use to standardize their process maps. If you have existing process maps, you could start by standardizing them with BPMN symbology. If you haven’t mapped processes before, start by creating the maps:
