Process Modeling Notation (BPMN) is a prevalent notation to all of the process design tooling today. BPMN is a public standard maintained by OMG and is widely accepted by both commercial and open source BPMS tooling vendors with new implementations continue entering the market, for example AquaLogic BPM 6.1 – BPMN from BEA. See also several BPMN posts on InfoQ. Despite this wide adoption, BPMN tooling is still suffering from many shortcomings:
- BPMN is a graphical notation and does not support standardized metamodel. As a result there is little to none interoperability between BPMN tools. Although it is possible to use XPDL to store and exchange the process diagrams, not every BPMN tool support it.
- BPMN is design language, which is typically translated into Business process execution language (BPEL). As pointed by Bruce Silver,
The mismatch between graph-oriented BPMN models, where you can route the flow just about anywhere, and block-oriented BPEL
creates a fair amount of incompatibility between the two languages, which in many cases makes such translation challenging.In the BPMN specification, there is an attempt to describe simple BPEL mappings for many diagram patterns, but it has been long recognized that certain patterns cannot be mapped in the ways described in the BPMN spec. BPMN tools that validate for BPEL export based on these simple mappings tend to give users a lot of validation errors if the BPMN is not drawn in strict block-oriented fashion.
As a result, majority of implementation provide only BPMN to BPEL translation (no round trips) and even this limited approach rarely provides truly executable code. >
The main objectives of the BPMN 2.0 standard are outlined in Antoine Lonjon’s white paper , which is similar to Bruce Silver’s BPMN Wish List . The most important one is creation of the BPMN interchange format (in addition to existing XPDL). According to Sebastian Stein :
Like back in the days of UML 1.x, there is no exchange format for the graphical models. However, in case of BPMN it is even worst. There is also no exchange format for the content of the models (so no XMI like for UML 1.x). BPMN 2 must address this problem by introducing an exchange format covering model content as well as graphical layout of the diagrams.
One of the possible solutions is to use Business Process Definition Metamodel (BPDM) as a consistent metatmodel for BPMN notation. This will not only solve the interchange format issue, but will also provide explicit definition of the BPMN execution semantics. Although this is a very powerful solution, it will introduce a lot of new concepts Another issues that are going to be addressed by new specification include support for specifying multiple ways to start a process, support for non aborting intermediate events, semi structured behavior, etc., which will potentially make BPMN even more complex
Although OMG is not scheduled to get to BPMN 2.0 until August/September timeframe, these initial announcements have caused a lot of activities on the Web. According to Sebastian Stein
Having more and new concepts might contradict BPMN’s current strength - simplicity. This will increase the learning curve for BPMN modeling and might hinder a further adoption.
Sebastian’s opinion is reiterated by Vishal Saxena who writes:
First let me identify the cool things in BPMN 1.0 (1.1) which made it one of the most popularly adopted spec in the last few years despite other modeling standards being around for a longer time. The first and foremost is that BPMN is simple – or to put it exactly: it keeps simple things simple. If I want to model my quote to cash process, I can do it in very little time with small and not so steep learning curve. Lot of people found it as easy as a flow chart that they otherwise draw on a drawing board, or may I say Visio.
When considering all of these new features, the question that needs to be asked about the role of BPMN. On one hand, some of the vendors, for example Intalio has introduced executable BPMN (a process is designed completely in BPMN and BPEL is generated under the covers as an executable artifact), on another hand Jean-Jacques Dubray argues that the assumption that
Business analysts should be able to create executable solutions from process models
is one of the fallacies of the business process management. With the exception of the most simplistic processes, for example order approval, practical BPM implementation typically requires IT involvement and consequently does not have to (and in most cases does not) directly run BPMN. The more important question, in this case, is how changes made during process implementation can be synchronized with the original BPMN model. So what should the role of BPMN be in future? This question is still discussed by many practitioners, but it seems like it has to be answered before embarking at the new release of BPMN standards.