Business Process Modeling Notation (BPMN) addresses the need for a standard notation that business process experts can use to model business processes. Today, most business process management and enterprise architecture suites and tools support BPMN.
BPMN was originally defined by the Business Process Management Initiative (BPMI.org). In June 2005, BPMI.org merged with the Object Management Group (OMG), a mature standards body best known in the enterprise computing world for its stewardship of the Unified Modeling Language (UML), XMI, MOF, and other Model Driven Architecture standards. OMG also manages an active community around the CORBA standards, which have a significant presence in realtime and embedded systems.
The OMG is close to releasing its official version 1 of the BPMN standard, which will be publicly available for download and use. In the meantime, OMG members can get a preview by downloading the Beta 2 version of the BPMN 1.0 specification.
As BPMN became entrenched in the market, inevitably its users identified improvements that could enhance its value. Some of the main issues with the BPMN version 1 specification are:
- It does not define a format for interchanging business process models among tools
- It has no formal metamodel for BPMN
- It does not specify a means for interchanging diagrams among tools
- The semantics of the various modeling constructs are not well defined
- Its facilities for expressing choreographies are limited
A standardized interchange format enables a BPMN tool that complies with the standard to import a business process model that was created by another compliant BPMN tool. Today, some tools use the Workflow Management Coalition’s XPDL as a BPMN interchange format, but XPDL is not truly based on BPMN’s modeling constructs, and thus the mapping to XPDL is not as direct as many would like.
Furthermore, companies who are investing in model-driven metadata management supported by the Eclipse Modeling Framework (EMF) (EMF) and the OMG’s Meta Object Facility (MOF) need an XMI-based interchange format.
The BPMN version 1 specification does not provide an interchange format, nor does it codify any other interchange format as the official BPMN interchange format.
In order to define an interchange format that is well-aligned with BPMN’s modeling constructs, it is necessary to define a metamodel. One of the things that a metamodel does is to define the (meta)data structures that a tool uses to capture the content of a business process model. In essence, a business process model is a set of metadata. Each modeling construct has a corresponding metadata structure that captures its content. An XML-based interchange format is an XML Schema that has slots that correspond to these metadata structures.
For example, BPMN defines a modeling construct called a Gateway. There are four kinds of gateways: Exclusive, Inclusive, Complex, and Parallel. There are two kinds of Exclusive gateways: Data-Based and Event-Based. A metamodel defines a schema of some sort that has the structure needed to capture this information. It might define a Gateway metadata structure that has a property that indicates which kind of Gateway is being captured; or it might define a separate metadata structure for each kind of Gateway. These are different ways that the metadata could be structured.
When a modeling tool stores or transmits a business process model, it stores or transmits metadata that is structured in accordance with the the metadata schema that the metamodel defines.
The metamodel’s definition of the structure of the metadata is called the abstract syntax. Different concrete syntaxes, such as a relational schema or an XML schema, can be generated from the abstract syntax. EMF and MOF typically use UML class models to express the abstract syntax, and use the abstract syntax to automatically generate XMI-compatible XML schemas, and to generate Java structures for APIs. EMF can also accept an XML schema as a representation of the abstract syntax.
For storage on disk, the tool may use a relational database with a relational schema that corresponds to the abstract syntax, while using an XML schema (derived from the same abstract syntax) as the format for interchange with other tools.
Today, BPMN does not define a metamodel.
A diagram is a window for viewing a model’s metadata, and the same metadata can be portrayed differently by different diagrams. A diagram often suppresses and displays certain elements of a model in order to focus on a specific concern, and, in so doing, arranges the visual representation of the metadata in a certain way. Another diagram working off the same metadata base may suppress and display different parts of the metadata. For example, a diagram may show only part of a business process, even though the metadata captures all the elements of the full process model.
So it is not enough to simply exchange the metadata among tools. An interchange format also must define how to exchange model diagrams. It is also not sufficient to exchange jpg files or similar kinds of graphic files, because, to the tool that imports the model, such a file is just an undifferentiated blob whose parts cannot be aligned with the structured metadata.
Therefore, an interchange format defines data structures that capture the relative positions of the different boxes and lines that appear in a diagram. Combining this interchange format with the interchange format for exchanging the metadata yields a really complete interchange format. Once again, some tools use XPDL to exchange diagrams, but the BPMN specification is silent on the subject.
Although a complete, standardized interchange format allows tools to exchange and align the metadata and diagrams that constitute a business process model, standardization of the interchange format does not guarantee that the tools will interpret the meaning of the same model in the same way. When multiple companies want to combine parts of their business processes to form a value chain, it helps if they can exchange their process models among the various business process management suites that they use; but if the suites do not agree on the semantics of those models, then it is difficult to use the suites to automate the execution of the value chain.
Thus, the fact that BPMN’s definition of semantics is neither complete nor rigorous creates head winds as companies pursue growing economic imperatives to dynamically form value chains and complex value networks. BPMN needs a metamodel that includes precise definitions of semantics.
Many people in the business process management field use the terms choreography and orchestration to distinguish between B2B and internal business processes, respectively. The term “orchestration” originates from the idea that, in a business process management environment, a business process execution engine orchestrates internal processes by executing a business process model, whereas in a B2B scenario there can be no central execution orchestrator. The term is somewhat misleading in that there are other modalities for executing internal business processes besides centralized orchestration, but we are stuck with this term nonetheless.
Models of B2B business processes hide the business partners’ internal processes while exposing a common model of a choreographed exchange of messages among the partners.
A business process expert can use BPMN today to model orchestration and choreography via the concepts of swimlanes and pools, but, overall BPMN’s support for choreography is weaker than its support for orchestration. It also is rather weak in allowing a modeler to express how her company’s internal processes relate to B2B choreographies being used for commerce in value chains.
The BPMN 2.0 RFP
The OMG issued the RFP for BPMN 2.0 in June 2007. It more or less covers the requirements outlined in this blog.
The RFP document contains a lot of boilerplate text that appears in all OMG RFPs. Skip over sections 1 through 5 to avoid plowing through a lot of information that is not specific to BPMN 2.0.
What You Can Do Now
If you are not familiar with BPMN, and you wish to advance your skills in business process modeling, you should learn it. BPMN has strong traction in the marketplace and will be important for years to come.
If you are an OMG member, you can download the beta 2 official specification and study it. You can also determine the business process management and/or enterprise architecture tools for which your company has licenses, and, if they support BPMN, you can read the documentation and start experimenting with BPMN.