Explore the key elements of BPMN models and how they help bridge the communication gap between business and IT teams.

Business Process Modeling and Notation (BPMN) is the global standard for modeling business processes, a fundamental part of business process management. BPMN diagrams allow different stakeholders to visualize business processes, making it easier to make workflows more effective and efficient. Everyone from business analysts to developers to business managers can “speak the same language” to adapt to new circumstances with total confidence.

What is Business Process Modeling and Notation (BPMN)?

Originally developed by the Business Process Management Initiative (BPMI), BPMN is a precise, graphical notation for documenting business processes. It resolves the ambiguities of textual process specifications by visually depicting the sequence of business activities and information flows needed to complete a specific process:

BPMN has been maintained by the Object Management Group (OMG) since 2005. This open consortium helps ensure that BPMN diagrams can be easily exchanged in a standardized format across different modeling tools. The ultimate goal is to help organizations model ways to improve efficiency, account for new circumstances and/or gain a competitive advantage.

BPMN 2.0 is part of OMG’s “triple crown” of process improvement standards, which also includes case management model notation (CMMN) and decision model notation (DMN). The standards differ from unified modeling language (UML) used in software design. OMG’s BPMN 2.0.1 specification has been published as International Standard ISO/IEC 19510:2013.

The value of BPMN

BPMN provides a common modeling language that’s readily understandable by all business stakeholders. This includes the business analysts who create and refine processes, the technical developers responsible for implementing them and the business users who monitor and manage them.

The BPMN specification is designed to help organizations do the following:

  • Reach faster agreement on current and future processes through unambiguous models
  • Encourage stakeholder participation through graphically expressive notations
  • Facilitate the analysis and improvement of operations
  • Create a library of process flows, case definitions and business rules to train new employees

In addition, BPMN diagrams help teams create the XML (Extensible Markup Language) documents needed to execute various processes, such as contract approvals or reminders for monthly financial reports. A related XML standard is the Business Process Execution Language (BPEL) for web services.

How BPMN works

The BPMN language is based on flowcharts and graphical notations. The notations are separated into four categories for diagramming:

  • Flow objects: Descriptive objects that are used to define a process, such as events, activities and gateways. Typically, processes are triggered by a start event, have activities/tasks and gateways (decision points) in the middle and conclude with an end event. Complex processes also include sub-processes and intermediate events, as well as different types of gateways to show how workflow moves through the diagram. For example, an exclusive gateway has only one option for movement, an inclusive gateway has options based on the decision made at the gateway and parallel gateways represent two concurrent tasks in a workflow.
  • Connecting objects: Symbols that are used to connect flow objects, such as message flows, sequence flows and associations. The flows are represented by dashed or straight lines with arrows, while associations use a dotted line to show that specific documents or artifacts are linked to an event or gateway.  
  • Swimlanes: Containers that separate a set of activities from others, such as pools and lanes. In BPMN diagrams, pools represent the major participants in a process. A different pool may be a different company, department or customer involved in the process. Lanes within a pool show the activities and flow for a certain role or participant, defining who is accountable for specific parts of a process.
  • Artifacts: Supplemental information about the process, such as data objects, groups and annotations. A data object shows what data is necessary for an activity, a group shows a logical grouping of activities and an annotation provides details about what’s happening in a part of the diagram.

The following BPMN diagram shows the process of a customer ordering checks from a bank. The customer and bank are shown as process participants in their own pools. Different events and tasks are connected by sequence flows, as seen in this example from the IBM Documentation:

Types of BPMN diagrams

BPMN diagrams can be simple or complex and depict both internal and external processes. These are some of the types of diagrams:

  • Collaboration diagrams show the interactions between two or more processes, using more than one pool (like in the check-ordering example above). The collaboration diagram focuses on work performed by each pool, and in turn, each pool can pass messages between each other. 
  • Choreography diagrams show the interactions between two or more participants. The choreography diagram can be contained within a collaboration, adding tasks and sequences that establish how the participants interact more fully.
  • Conversation diagrams are a simplified version of a collaboration diagram. They show a group of related message exchanges in a business process.


To begin creating your own BPMN diagrams, check out IBM Blueworks Live. It’s a cloud-based tool that makes it easy for modelers to discover processes, analyze them and refine them. The business process diagrams can then be used within a BPM tool like IBM Business Automation Workflow to improve efficiency, productivity and consistency across multiple workflows and business groups.

Get IBM Business Automation Workflow as part of the IBM Cloud Pak® for Business Automation. With the end-to-end automation platform, you can eliminate repetitive tasks and reallocate your resources toward higher-value work. The solution is also ideal for exploring the future of intelligent automation.

To learn more about BPMN modeling, read “How to Take Business Process Modeling to the Next Level” and sign up for the IBM Business Automation Workflow software trial.


More from Automation

Observing Camunda environments with IBM Instana Business Monitoring

3 min read - Organizations today struggle to detect, identify and act on business operations incidents. The gap between business and IT continues to grow, leaving orgs unable to link IT outages to business impact.  Site reliability engineers (SREs) want to understand business impact to better prioritize their work but don’t have a way of monitoring business KPIs. They struggle to link IT outages to business impacts because data is often siloed and knowledge is tribal. It forces teams into a highly reactive mode…

Buying APM was a good decision (so is getting rid of it)

4 min read - For a long time, there wasn’t a good standard definition of observability that encompassed organizational needs while keeping the spirit of IT monitoring intact. Eventually, the concept of “Observability = Metrics + Traces + Logs” became the de facto definition. That’s nice, but to understand what observability should be, you must consider the characteristics of modern applications: Changes in how they’re developed, deployed and operated The blurring of lines between application code and infrastructure New architectures and technologies like Docker,…

IBM Tech Now: September 18, 2023

< 1 min read - ​Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announcements in the world of technology. Make sure you subscribe to our YouTube channel to be notified every time a new IBM Tech Now video is published. IBM Tech Now: Episode 84 On this episode, we're covering the following topics: The IBM Security X-Force Cloud Threat Landscape Report The introduction of IBM Intelligent Remediation Stay plugged in You can check out the IBM Blog Announcements…

Debunking observability myths – Part 5: You can create an observable system without observability-driven automation

3 min read - In our blog series, we’ve debunked the following observability myths so far: Part 1: You can skip monitoring and rely solely on logs Part 2: Observability is built exclusively for SREs Part 3: Observability is only relevant and beneficial for large-scale systems or complex architectures Part 4: Observability is always expensive In this post, we'll tackle another fallacy that limits the potential of observability—that you can create an observable system without observability driven by automation. Why is this a myth? The notion that…