Beginners Guide to Business Process Modeling and Notation (BPMN)

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

OCEB 2 Program

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:

• Its use is tied to organizational objectives. In this scenario, your business would require a specific modeling notation language in order to stay consistent, especially if they have international business interests. Out of necessity, this modeling is generally more formal than most.

• You commonly use the same handful of elements in a specific concept. In this scenario, you are able to draw selectively from BPMN as needed, and there is less concern about other users misunderstanding.

• You want to show your breadth of BPM knowledge. Nothing says you are a BPM expert like understanding the modeling language designed specifically for it. When you apply for positions that require BPM expertise, this knowledge and experience could set you apart.

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 1.0, released May 3, 2004

• BPMN 1.1, released January 17, 2008

• BPMN 1.2, released January 3, 2009

• BPMN 2.0, released January 3, 2011

• BPMN 2.0.2, released January 3, 2014

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:

• Semantics: The execution semantics (meanings) for all BPMN elements were formalized.

• Notation: New diagram types were added with new contexts for use. These include choreography and conversation diagrams. Choreography diagrams center on the flow of messages and between-process interactions. These diagrams chiefly focus on the interaction between the pools. There is no central control, responsible entity, or observer. Conversation diagrams focus on conversations between the participants, showing a bird’s-eye view of the information exchange between participants. BPMN 2.0 also made improvements to events, adding non-interrupting events and event subprocesses. We discuss the event improvements in the “Extended BPMN Modeling Elements” section of this guide. With sub-processes, BPMN 2.0 added more than 50 new elements. Elements are the symbols that represent different parts of the process.

• Technical: The formal meta-model was defined.

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:

• Provide a consistent structure.

• Be highly readable throughout all levels of the process.

• Ensure that the model is complete without any additional documentation required.

• Be able to be shared with IT as an executable process.

Your BPMN diagram should represent not only business process activities, but can and should show the following:

• Any information that is exchanged during process implementation.

• Control checkpoints that show the sequence of data exchange and activity implementation.

• Personnel roles and any needed additional personnel.

• What information systems support the process.

• How the process in regulated in the business rules and legal framework.

• The implementation.

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:

• Internal activities

• Departments responsible for each task

• Documentation

• Rules that regulate the processes

• Information systems

Public business processes:

• Concentrate on the interaction between internal processes and those of other organizations

• Do not review organizational structure, information systems, or rules

Collaboration business processes:

• Show all interactions for every organization in the process (two or more businesses)

• Do not provide internal processes for any organization

• Help identify the software that supports the processes

• Contain two or more pools

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:

• Organizational structures and resources

• Functional breakdowns

• Data and information models

• Strategy

• Business rules

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.

• Events: What happens during a process. There are three main types: Start, Intermediate, and End. An event is also what happens during a process. For example, an event could be that “a message is sent,” “an error occurred,” or “cycle is completed.”

• Activities: Work performed in a process; also known as tasks.

• Gateways: These determine the sequence flow path in a process. Gateways have internal markers that give additional detail to show how the flow is controlled. These are decision points in a process. For example, if a condition is true, then processing continues one way; if false, then another.

2. Data: These elements call out information about the activities. Data is either provided or stored for the activity.

• Data objects

• Data inputs

• Data outputs

• Data stores, where processes can either read or write information. A data store continues beyond the life of the process.

3. Connecting Objects: These connect the flow objects to each other or to other information.

• Sequence flows: This element shows the order in which activities are performed.

• Message flows: This displays the messages and the order of flow between participants.

• Associations: This element is used to link information and artifacts (see below).

• Data associations: These have an arrowhead to indicate direction of flow in an association.

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:

• Flow elements are connected differently depending on whether they are in a pool or between pools.

• Only message flows can be used when communicating between pools. Message flows designate the exchange of messages.

• A pool cannot contain more than one process.

• Sequence flows should not be used between pools. Lanes are more appropriate where sequence flows are necessary, not pools.

5. Artifacts: These are used to give extra detail about the process. The two standardized artifacts are:

• Groups: This is a hatched box around a group of elements to designate visually that they are related. This does not affect sequence flows.

• Text Annotations: Extra text, attached with an association, that gives additional information. Also known as a comment.

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.

• Receive waits for a message from an external participant.

• Script is a task executed by the engine.

• Manual is a task the operates without the aid of engines or applications.

• Receive (Instantiated) is a task that is designed to wait for a message to arrive from an external participant. It then instantiates a process.

• Service is a task that uses a web service or automated application.

• User is a human task scheduled through a manager.

• Send is a task that is designed to send a message to an external participant.

• Business Rule is a task that confirms with the business rules engine the input prior to executing.

Three types of markers are specified for a task as well. These include loop, multiple instance, and compensation.

• Loop will continue as long as the condition is true; a numeric cap may be specified.

• Multiple instance may execute in parallel or sequentially. An expression or a data-driven setup can be used to determine the number of instances.

• Compensation tasks specify some type of recompense or payment, either into or out of the process.

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.

Source: OMG

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.

• Exclusive gateways are the main type. They may have the X in the middle, or they may be empty. They model alternative paths and are where the diversion takes place.

• Event-based gateways are used to model the alternative paths, but are based on events that occur, not the expression of flow.

• Inclusive gateways can be used to model alternative and parallel paths. They evaluate all condition expressions and take paths with a positive result.

• Complex gateways model complex synchronization behavior.

• Parallel gateways create and join parallel flows. They check no conditions.

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 are used in merging and branching in place of a gateway. A conditional expression is defined at its origin.

• Default flows are only selected if no other sequence flows available. Conditions on a default sequence flow are always ignored. There may be only one default flow per object.

• Exception flows occur outside of the normal flow of the process and are based on an intermediate event on the boundary.

• Compensation associations are used when an activity is canceled, and the process must be set to its original state.

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:

• Mistakes in the Modeling Elements: This would decrease the clarity of process flows, rather than increase the communication.

• Increased Complexity in Modeling: With more time required for analysis, the value of the product decreases.

• Lack of Stakeholder Understanding: If stakeholders need everything explained, it could introduce errors and incorrect information.

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:

1. Use as few elements as possible in the model. This aids readability and decreases errors.

2. Minimize the routing paths per element. BPMN regulates routing paths via gateways.

3. Use one start event and one end event. BPMN requires this, and depending on the software it does not allow more than one. BPMN does give intermediate events where required.

4. Model as structured as possible. This means that the diagrams are balanced. In BPMN, gateways should not be used to join and split at the same time; they should be balanced and joined equivalently. Further, the same type of gateway should be used to split and join the flow.

5. Avoid or routing elements. This means that elements in models should not be an either/or question, but modeled such that the decision is an and or an xor. An xor gives mutually exclusive answers. In BPMN, gateways are not capable of being and.

6. Use verb-object activity labels in your naming convention. This decreases ambiguity.

7. Draw your models left to right (not top to bottom) unless the bulk of your stakeholders write ideographic languages (such as Japanese, Chinese, etc.) for easier understanding.

8. Decompose the model if it has more than 50 elements. That is, break a system into its component subsystems, processes, and subprocesses. This is related to guideline number one, in that having the least amount of elements keeps the errors low. BPMN has sub-processes that can decompose a model.

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:

1. Process Modeling Conformance supports the elements and attributes of three subclasses: the descriptive, analytical, and common executable. The descriptive and analytical subclasses provide the information necessary to visually represent the diagrams. The common executable is the description of the data for the XML and meta-model.

2. Process Execution Conformance tools must fully support the import of process diagrams. This is the support and interpretation of the meta-model via the semantics and activity lifecycle.

3. BPEL Process Execution Conformance supports full mapping, from BPMN models to BPEL.

4. Choreography Modeling Conformance tools provide elements, appearance, semantics, and interchange, as well as BPMN choreography types.

Aside from actual BPMN conformance, one method to choosing a modeling tool is as follows:

1. Define your business objectives and requirements. Know ahead of time what functional and nonfunctional requirements your business will have for BPMN.

2. Define the selection criteria and the weight of each. Do your users need syntax checks? Do they need pop-up menus? Do they need help in documentation? Develop a chart that delineates your business’s required criteria, so you can pick a program that meets your needs.

3. Identify some candidate tools. With as many tools available to date, it is impossible to test-drive all of them. Once you delineate and weight your selection criteria, some of the potential tools will not be feasible. From there, if demos are available, order them. Evaluate how easy it is to install, identify any operability problems, and explore the support in the BPMN tool.

4. Test-drive one model. Once you discover the best candidates, use a consistent model that represents your company to test across the remaining applications.

5. Select your winner. Once you have multiple examples of the same model, you will have notes on each program, how easy the model was to develop, and the end look and feel. This should lead to your choice of BPMN tool.

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:

Download Mapping Processes Checklist

Download Optimizing a Process  Checklist

There is little doubt that learning BPMN is complicated, but it appears to be a worthwhile venture. Some BPMN experts have formal education, and some do not. Reading the current specification manual from OMG is not considered the best way to learn to model BPMN. Most, if not all, experts agree that learning through doing is best, putting the elements into understandable context.

1. Model with a top-down approach. According to Stephen White in an interview on the Leonardo Blog, “The top-down approach will ensure that the depth of modeling is consistent throughout the effort of process modeling in your organization. I'm not saying that every single process model needs to be the same amount of granularity. It depends on the purpose.”

2. Every BPMN symbol should have a label.   

   1. Events should be labeled object + past participle. For example, “Process started.”

      1. Start events should have how the process is activated.
      2. End events should have the process “end state.”

   2. The pool should always be labeled with the process name and role (for lanes).

   3. Tasks should be labeled as verb + object. For example, “Eat lunch.”

   4. Gateways should be labeled with a question. For example, “Packaging complete?”

   5. Outgoing sequence flows should be labeled with answers to the gateway questions. For example, “yes” or “no.”

3. Avoid crossing flows as much as possible. A good process layout with few crossing lines is easier to read.

4. Symmetric structures are easier for the human brain to understand.

5. Draw equal task sizes. However, the size of the task element does not indicate the size of the task in BPMN.

6. Show exception handling explicitly.

7. Use message flows consistently. Attach the message flows to the boundary of the process pool at all levels of the diagram to add to your business context.

8. Consider using sub-processes to define scope. Sub-processes can be wrapped around part of your sequence when exceptions occur without penalty.

9. Limit the number of concepts in the model. Since most BPMN users are describing business processes, users should keep it simple and only use the required elements for maximum readability.

10. Set standards for your organization. Clear, regularly used conventions, such as elements, naming, methodology, and layout should be developed per business so that there is additional consistency for stakeholders.

11. Consider using a legend that explains the symbols for stakeholders who are not often exposed to BPMN.

12. Try not to simply send diagrams out to stakeholders, but take the time to explain the processes to those not trained in BPMN.

13. Consider making two models of the same process if you have a large number of stakeholders without BPMN experience: one model for business users (with less elements), and one executable model.

BPMN Diagram Samples

The following models are from OMG, and they represent most of the elements described in this guide. This should give you an understanding of how a BPMN diagram looks.

The Pizza Collaboration

Shipment process of a hardware retailer

No discussion of BPMN would be complete without reviewing other modeling languages, such as BPEL, YAWL, and UML. These languages have been used in the evolution of BPMN, to make it more applicable and garner wider use in the industry.

Business Process Execution Language (BPEL) and BPMN

BPEL (officially known as web services - business process execution language, WS-BPEL) is an XML-based orchestration language that allows companies to seamlessly work together by using web services to share data. It was created to standardize how processes are executed. Generally, it is meant for completely automated processes, especially when companies want to turn processes into XML for automation, even robotic process automation (RPA).

BPEL is based on web services in that each of the business processes involved are considered to be a web service. BPEL specifies the order in which web services should be invoked. An orchestration language identifies the executable process of message exchanges with other systems. BPEL supports two types of business processes: executable and abstract processes. BPEL is mainly meant to be employed by IT users, primarily because there is no graphical notation associated with it. BPEL is not meant to be accessed by business analysts or end users.

BPEL was often used in conjunction with earlier versions of BPMN. Users wrote BPMN notation, and BPEL was the execution language. Although there was and currently is a very high degree of correlation between BPMN and BPEL, there is no perfect system for one-to-one mapping between them. Some business processes may map in a way that is not executable. With the release of BPMN 2.0, BPEL was no longer necessary as the core XML language. BPMN 2.0 came with its own XML specification language.

Current trends in the industry suggest that more businesses are leaning toward using BPMN 2.0, and BPEL adoption has decreased considerably since 2007. According to “The State of Business Process Management 2016 Report,” only 8 percent of businesses are interested in adopting BPEL.

There are arguments within the industry that revolve around when to use BPEL vs. BPMN, especially since there is overlap between the two, and many problems could be solved using either BPMN or BPEL. Most large enterprises do not consider using only BPMN or BPEL; instead, they use both, depending on the scenario. Experts recommend that if your organization needs both, keep the BPEL worker processes in separate composites from the BPMN business processes. The following is a chart, culled from countless sources around the web, that details different scenarios where either BPMN or BPEL are recommended.

Yet Another Modeling Language (YAWL)

YAWL (yet another modeling language) may be considered an alternative language to BPEL. YAWL is based on Petri nets, which are part of a mathematical modeling and reasoning language. It is also open source, which means that the original source code is available to anyone to change and use. YAWL is considered easier in communicating to stakeholders than BPEL because of the intuitive user interface. YAWL and BPMN have some concepts in common — namely, tasks, gateways (as a decorator in YAWL), and flow.

Unified Modeling Language (UML)

Unified Modeling Language (UML) is a general-purpose modeling language also managed by OMG and published by the International Organization for Standardization (ISO) as an approved language standard. UML is similar to BPMN in that it is an open source modeling language. Whereas the whole of BPMN is devoted to business process modeling, only UML’s activity diagram is suitable for business process modeling. Overall, UML is object-oriented, while BPMN is process-oriented.

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.