1. Introduction
The Business Process Model and Notation (BPMN) is the leading standard for modeling business processes. One of its goals is providing business professionals with a standard notation allowing not only internal communication of the business procedures, but also business-IT alignment2 and collaboration between business partners3.
BPMN is developed by the Object Management Group (OMG) which also manages the highly popular Unified Modeling Language (UML) and Model Driven Architecture (MDA). In July 2013, the International Organization for Standardization (ISO) adopted BPMN and published it as ISO/IEC 19510:2013, which is identical to version 2.0.1 of the OMG.
As of May, 2014 there are over 70 tools (focusing on modeling or analysis as well as execution) listed on www.bpmn.org claiming BPMN support and over 300 books on Amazon related to BPMN in the latest version 2.0. On LinkedIn there are over 44 000 professionals referencing BPMN in their skill set.
Moreover, BPMN is now taught worldwide at universities and management schools as a de facto standard for communication of business processes.
Due to its popularity, BPMN is considered to be the lingua franca (a language which is spoken by a vast number of people and used to communicate among different groups not sharing a common language) of business process management (BPM). By allowing BPM practitioners to create business process models using a common graphical notation, BPMN makes it easier to communicate processes in a compact way across companies and continents.
Since there are more and more BPM software suites supporting BPMN, BPM practitioners finally have a chance to exchange process models between software suites from different vendors – e.g. when a company has a BPA (Business Process Analysis) tool used for process documentation or optimization and a BPMS engine used for process automation or when common initiative aimed at process improvement requires exchanging models with a partner company using different BPA tool.
Cross-organizational process initiatives such as the National Process Library in Germany (NPB4) and Switzerland (eCH5) are examples where hundreds of organizations, each with their own BPA or BPMS of choice, exchange process models through a shared platform.
This Article describes the joint effort of vendors working in BPMN Model Interchange Working Group aimed at facilitation of interchange of BPMN models among tools.
For those interested in a more in-depth introduction, best practices and case studies, multiple BPMN references are available at the end of this document.
2. A Common Language for Humans
For many years there was no single language allowing business and IT users share their insights about processes. Business users could use more or less formalized notations for documenting their processes (e.g. IDEF, LOVEM, EPC, Flowcharts), while IT users focusing more on software development related usage of processes preferred UML6.
BPMN changed this situation offering all groups of users a notation that on the one hand looked familiar to business users acquainted with flowcharts, while on the other hand provided mechanisms for describing more complex aspects such as e.g. error handling7.
Version 2.0 of the BPMN specification added the concept of the process modeling conformance with levels defining subsets of elements to use for different purposes (reduced set of objects and attributes in “descriptive” level for users looking for flowchart-like modeling, more advanced “analytic” level and “common executable” – with all attributes needed for executable modeling). The result is that BPMN now fully supports different levels of description (or modeling views) for business processes, which allows for a “fit-for-purpose” modeling approach to be followed, albeit any approach using the same modeling language.
One of these levels (or views) can apply to the “system” that automates a business process, wherein system behaviors can also be described by the system analyst using the same language as that used by the business analyst for describing operational behaviors. There is no longer a shift in modeling languages, with associated changes in notation and modeling semantics, from one phase of the software development to the next.
Because of this new richness in BPMN, it can now support a more robust alignment of business understanding of the processes with the IT-related views through the created models.
3. A Common Language for Systems8
The BPMN versions prior to BPMN 2.0 provided no standardized mechanisms for exchanging BPMN diagrams. Instead, the BPMN 1.2 specification suggests a non-normative mapping from BPMN to WS-BPEL 2.0, which in turn has a standardized exchange format. With BPMN 1.2 and WS-BPEL 2.0 having different capabilities, the lossless interchange of BPMN 1.2 models between various tools was not possible (especially in roundtrip scenarios).
This was partially alleviated by the existence of the XPDL standard. However mapping to XPDL was not part of the BPMN specification and the standard itself was maintained by an external entity (WfMC), so there was no sure solution.
In order to resolve this, BPMN 2.0 introduced its own XML-based interchange format for BPMN processes.
Any BPM tool properly implementing requirements of BPMN 2.0 specification should support constructions and attributes defined by appropriate BPMN conformance classes. For BPM tools focused on execution, this means that any BPMN-compliant BPM system should be able to take over process definitions from another tool9, and potentially directly execute the diagram if the necessary information is set properly.
4. BPMN 2.0 Interchange Capabilities
In BPMN 2.0, processes comprise two aspects:
- Process models contain the semantics.
- Process diagrams store the visual representation of the process models.
Let us consider an example process comprising a start event, a single task, and an end event along with two sequence flows connecting the events with the task. The corresponding process diagram is depicted in Figure 1. The process model contains only the semantics, but not the graphical visualization. For example, the model has no information about whether the task should be to the right of the start event or below it. For storing the graphical visualizations, diagrams refine the model with information about the layout of the shapes.
Figure 1: Example process diagram
Beyond the semantic richness introduced with the latest version, BPMN 2.0 defines standardized formats for creating XML files which contain both aspects. This allows exchanging BPMN processes between tools of different vendors. Mirroring the two aspects of BPMN processes, these XML BPMN files comprise two parts:
- One or more process models contain the semantics.
- One or more process diagrams store the visual representation of the process models. In the BPMN specification, this part is referred to as BPMN Diagram Interchange (BPMN DI).
BPMN 2.0 offers two XML formats for storing BPMN processes:
- A format defined using XML Schema Definition (XSD).
- A format defined using XML Metadata Interchange (XMI).
Both formats provide the same expressive power10. The OMG provides tools for the lossless transformation between these two formats. However, with the XSD-based format being more popular, this transformation is only occasionally used in practice. From a user point of view, BPMN diagram interchange capable tools typically allow exporting the processes modelled in BPMN 2.0 to XML files (usually with the extension .bpmn) and importing processes from these files in such a way that the model content (i.e., events, tasks, etc.) and layout are preserved, so that there is no need to re-draw the processes manually.
5. Why a Working Group for BPMN Model Interchange?
Even though the BPMN 2.0 specification contains definitions for the diagram interchange, practice showed that in some cases there are ambiguities or even contradictions in the specification document, and there was no “single source of truth”. Because of this, various tool vendors may interpret parts of the specification differently and thus tool implementations of the BPMN standard could vary significantly. Also, different vendors choose to implement different subsets, without a commonly agreed upon “basic subset” of BPMN.
Obviously, this made the interchange of models between various tools very difficult as each vendor would need to handle exports from other tools, trying to be able to import them. That kind of “catching the moving target” led to high efforts and in the best case caused that a tool vendor do tests with 2-3 other popular tools.
In order to resolve this problem, the BPMN Model Interchange Working Group (BPMN MIWG11) was set up as a part of OMG. Being a joint effort of vendors interested in diagram interchange, the initiative's goal is to guide and support vendors in creating standard-compliant BPMN tools, identify issues in the BPMN specification, and facilitate model interchange. The group's guiding principles are: transparency, inclusion, collaboration, and openness.
In order to contribute real-world results, the BPMN MIWG – chaired by Denis Gagné – used the practical approach and started with a test suite comprising several BPMN models that are used as reference points, both for the import and export functionality of various tools. Test cases check various aspects of BPMN modeling – ranging from the most basic layout aspects to the more advanced BPMN attributes and support for importing/exporting sub-models.
Figure 2. Test case B2.0 used for checking whether all BPMN object types are preserved properly
Currently new test cases are being added, in order to cover the more advanced aspects of model interchange as well.
As an addition to the test cases, a special mechanism for the automated comparison of the test results provided by vendors assists in identifying interoperability issues of the BPMN tools. The latest version of results is available via the BPMN MIWG website.
Figure 3. Page showing results of automated tests (as of May 2014)
6. Interchange Demonstrations
The first results of the BPMN MIWG efforts were shown as “chained demonstration” during OMG's quarterly technical meeting in Berlin, Germany on Wednesday, June 19th 2013.
Figure 4: Flow of business process diagrams between the BPMN tools during the Berlin demonstration
Starting from a simple business process model, more and more details were added using various tools. Then the process was executed with camunda BPM platform and moved back to ADONIS, proving that full roundtrip retaining technical attributes is possible thanks to the BPMN Diagram Interchange (for more information on this aspect see section 7.3).
During the demonstration, the model went through tools from BOC Group, Signavio, Trisotech, Yaoqiang, camunda services, and W4 Software.
Figure 5. Test BPMN model after full roundtrip shown in ADONIS
The demonstration proved to be very successful resulting in comments such like the one from Dennis Wisnosky, Senior Advisor and Consultant at the EDM Council: “What has been accomplished is truly impressive. It is the answer to lossless data interchange between BPM tools that has been only a dream for decades.”
For more information about the demo (including a step-by-step description with model screenshots from the various tools and an embedded link to the full coverage on YouTube) visit:
The second public demonstration showcasing the smooth interchange between 15 BPMN tools which was organized by the BPMN MIWG group took place on March 26th 2014. This demonstration was a truly global effort with participants being dispersed between OMG's technical meeting in Reston, VA, the bpmNEXT conference in California, France, and Poland.
This time 15 tools12 took part in the demonstration showcasing collaborative work on various parts of business process diagram, integrating the final model and simulating it to show its completeness.
Figure 6. Flow of business process diagrams between the BPMN tools during the second public demonstration
Figure 7. Final version of the model being verified with process animation feature of Trisotech Web Modeler
This demo proved much better support for complex scenarios of BPMN interchange in tools participating in BPMN MIWG effort and also gained much interest13.
To learn more about the demo, visit: https://github.com/bpmn-miwg/bpmn-miwg-demos/tree/master/2014-03-26-omg-reston-bpmnext-california. This site contains the results as well as a link to the full coverage on YouTube.
7. Interchange Limitations (as of May 2014)
Even though the BPMN 2 Diagram Interchange supports exchanging BPMN process models, there are still currently some limitations on the success on interchange, which may be broadly defined as:
- Visual aspects of process diagrams
- Semantic aspects of process models
- Vendor-specific extensions
- Preservation of IDs for roundtrip
The following sections will examine these current limitations in more detail.
7.1 Visuals
The BPMN Diagram Interchange (BPMN DI) provides mechanisms for specifying the basic layout of BPMN diagrams. However, the BPMN DI provides no mechanisms for the following aspects of a BPMN diagram (as they are intentionally not covered by BPMN 2.0 specification):
- Colors of shapes and text
- Shape decorations like shadows, gradients, or backgrounds
- Text wrapping
- Thickness (in pixels) and style of the lines
Therefore, the same BPMN diagram may be rendered differently in different tools without violating BPMN compliance. Figures below depict such two correct renderings of the same BPMN diagram14. Both renderings have several little differences although they are based on the same diagram:
- The pools and lanes have different colors
- The shapes have different backgrounds
- The message flow is dashed using different styles
- The borders of the pools have different thicknesses
Figure 8: First rendering of an example diagram
Figure 9: Second rendering of an example diagram
A common problem in diagram interchange is word wrapping. With text size and style not being part of BPMN DI, BPMN tools may use different text sizes when rendering a BPMN diagram. This may lead to different word wrapping, e.g., even if a diagram has adequate text wrapping in tool A, the same diagram may be sub optimally rendered in tool B.
Figure 10: Different word wrapping in tools A and B
However these differences between tools do not affect the global shape of the diagrams. Users will not be disappointed in the positioning of the different objects if the graph has been made following the designer's idea and logic.
7.2 Semantics
Besides the visual aspects of process diagrams, there are some semantic aspects (i.e. places where BPMN specification left room for selecting way to add implementation related details e.g. several languages with different semantics can be used) which are also not covered by BPMN interchangeability. First, elements that are specified in BPMN models using non-standardized notations may cause problems when exchanging these models between tools. This includes the following BPMN elements:
- Script of a script task
- Implementation of a user task
- Implementation of a global user task
Furthermore, elements that are not contained within but referred to by a process model are not guaranteed to be interchangeable. This primarily applies to web services which are referenced by service tasks, send tasks and receive tasks.
The interchangeability of such elements is limited because (1) the web services may not be available to the recipient of a process model and (2) the web service may use a proprietary implementation which is not supported by the tool used by the recipient.
However, with the XML serialization, concepts represented in BPMN models can now be mapped in a consistent way to other business concepts, such as those defined via a framework in a business or enterprise architecture. For example, business goals or KPIs can be mapped at an architectural level to elements represented in BPMN models, as long as the mapping does not violate the semantics of the modeled elements. This capability and the interchange format now permit BPMN modeling tools to co-exist and interact effectively with architectural modeling tools.
7.3 Vendor-specific Extensions
BPMN models and diagrams allow tool vendors to add proprietary information to the XML serialization of a BPMN process model. This is particularly useful for business process management systems (BPMS) that may require additional information (e.g. information about forms shown to users for a specific task, scripts to be called etc.15), but also for BPA tools that allow modeling in BPMN with additional “business related” attributes (e.g. times, costs, risks) and constructs.
Although extension elements are a standard way to add proprietary information to a BPMN file, this added information is vendor-specific. Therefore, users cannot expect that information contained in extension elements can always be exchanged between different tools without losses.
Tools should ignore the extension elements they do not support, while still keeping them in the exported BPMN, so that a round-trip is possible (as it was already demonstrated during the Berlin demo described in section 5).
strong>7.4 Preservation of IDs for Roundtrip
The BPMN standard does not prescribe that elements having a certain ID upon import must preserve that ID also during export. In reality, many tools override IDs in order to apply their internal ID scheme.
While this is not a limitation for pure import / export scenarios, it becomes a limitation for roundtrip scenarios. Consider the following example: a BPMN model is created in a BPA tool, then transported over to a BPMS, subsequently refined for implementation, fed back to the BPA tool, modified and again synchronized back to the BPMS. Version change tracing and merge algorithms heavily rely on being able to relate previous elements to the elements present in the current model. This is only elegantly possible when preserving at least the IDs in that model.
8. Outlook
The BPMN Model Interchange Working Group (BPMN MIWG) is constantly working on identifying and clarifying potentially misleading elements of the BPMN specification and improving the BPMN interoperability among various tools.
Even though the group's results are already significant, there is still much to do – both in terms of the number of tools that are developed with model interchange in mind and using the reference models as well as in terms of extending the scope of the reference models, so that they cover more and more sophisticated aspects of BPMN modeling. Current areas of work are related with the interchange of executable models e.g. preservation of IDs and proposal of uniform way to store information about calling Java classes, REST services etc.
Vendors, practitioners, and other parties interested in improving BPMN process interchange are encouraged to join the weekly web conference and participate in testing their tools using the BPMN MIWG test suite and / or the automated tests.
To learn more and join the BPMN MIWG visit: http://www.omgwiki.org/bpmn-miwg
References
Business Process Model and Notation (BPMN), http://www.omg.org/spec/BPMN/
ISO/IEC 19510:2013 BPMN, http://www.iso.org/iso/catalogue_detail.htm?csnumber=62652
OMG BPMN FTF, BPMN 2.0 by Example, http://www.omg.org/spec/BPMN/20100601/10-06-02.pdf
BPMN 2.0 Handbook, Second Edition, L. Fischer Editor, Future Strategies, 2012. www.BPMNHandbook.com
http://camunda.org/bpmn/reference.html
http://www.bpmnquickguide.com/
Thomas Allweyer, BPMN 2.0 Introduction to the Standard for Business Process Modeling, BoD, 2010.
http://www.bpmn-introduction.com/
Jakob Freud and Bernd Rücker, Real-Life BPMN, CreateSpace Independent Publishing Platform, 2012
Alexander Grosskopf, Gero Decker, Mathias Weske, The Process: Business Process Modeling using BPMN, Meghan-Kiffer Press, 2009.
Paul Harmon, Business Process Change: A Guide for Business Managers and BPM and Six Sigma Professionals, Morgan Kaufmann, 2010
Paul Harmon, Celia Wolf, Business Process Modeling Survey, https://www.bptrends.com/bpt/wp-content/surveys/Process_Modeling_Survey-Dec_11_FINAL.pdf
Matthias Kurz, Falko Menge, Zbigniew Misiak, Diagram Interchangeability in BPMN 2, http://www.omg.org/oceb-2/documents/BPMN_Interchange.pdf
Bruce Silver, BPMN Method and Style, 2nd Edition, with BPMN Implementer's Guide: A structured approach for business process modeling and implementation using BPMN 2.0, Cody-Cassidy Press, 2011
Stephen White, Introduction to BPMN, http://www.omg.org/bpmn/Documents/Introduction_to_BPMN.pdf
1The authors would like to thank the whole BPMN MIWG group, especially Denis Gagné and Falko Menge for their valuable comments and suggestions.
2This is possible because BPMN supports modelling more technical details that allow process execution as well.
3BPMN simplifies collaboration because the same models can be used between business partners – possibly using different tools.
4http://www.prozessbibliothek.de
5http://www.ech.ch
6For more background information see BP Trends “Business Process Modeling Survey” https://www.bptrends.com/bpt/wp-content/surveys/Process_Modeling_Survey-Dec_11_FINAL.pdf. Nice overview of the modelling standards history can be found e.g. in Business Process Change: A Guide for Business Managers and BPM and Six Sigma Professionals
7Introduction to BPMN (http://www.omg.org/bpmn/Documents/Introduction_to_BPMN.pdf), provides more insight into the vision of the BPMN specification authors.
8Following parts of the article are based on – extended and updated – article Diagram Interchangeability in BPMN 2 being part of the OMG Certified Expert in BPMN reference materials.
9It does not mean however that the process can be executed right away since different tools use various ways to add technical details for the execution such as forms, scripts to be executed, web-services to be invoked etc. For more on this topic see section 7.3.
10There is one exception to this rule: The XMI-based format may hold incomplete process models (i.e., process models where required attributes are not set or required associations are missing).
11To learn more about BPMN MIWG visit: http://www.omgwiki.org/bpmn-miwg
1212 tools creating the model and 3 tools opening the results.
13For an example, see the coverage from Sandy Kemsley (http://www.column2.com/2014/03/bpmnext-2014-bpmn-miwg-demo/)
14This diagram originates from test A.4.0 of the OMG BPMN Model Interchange Working Group (OMG BPMN MIWG) test suite.
15Currently BPMN MIWG is starting work on proposal of the standard for exchanging the way BPMN diagrams store information about called Java classes, REST services etc.
