What can we expect from BPMN 2.0?

Posted by Boris Lublinsky on May 04, 2008 06:54 PM

Community

Architecture,

SOA

Topics

Business Process Modeling ,

Workflow / BPM ,

Business Process Management

Tags

Business/IT Alignment ,

BPMN ,

Business Models

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.

1. Back to top

   Great overview

   May 5, 2008 8:33 AM by Tom Baeyens

   Great overview of the current positions towards BPMN 2.0. I have major concerns with the direction that is starting to become clear and I've posted them as a separate blog: Big Problems Ahead For BPMN 2.0 ?

   Reply

2. Back to top

   Re: Great overview

   May 5, 2008 11:00 AM by Boris Lublinsky

   Thanks Tom, and a great blog entry. That is exactly my concern. Should BPMN reflect all nuances of the process execution or be enough of a guide for developers so that they understand precisely the requirements, but are able to optimize implementation based on their technical knowledge.

   Reply

3. Back to top

   More BPMN Blogosphere

   May 7, 2008 6:10 AM by Tom Baeyens

   Here are some more related posts that are fairly recent:
   
   "You can serialize BPMN into BPEL, but BPEL should not be the serialization standard" from Jesper Joergensen
   
   and
   
   John Evdemon's (BPEL Chair) reaction: "If you can do something it doesn't mean that you should..."
   
   regards, tom.

   Reply

• Older >