Because BPMN 2.0 is a standard and defines an XML serialization, you can create a model in tool A and import it into tool B. Right? Umm, actually no. Well, isn’t that what a standard is supposed to do? Yes. And isn’t that what OMG has been claiming for years that BPMN 2.0 will do? Yes again. So once BPMN 2.0 is finalized in June, we still won’t have tool interoperability? Well, there is a chance, but if you want it you will need to make your voice heard, and soon.
The problem is that BPMN 2.0 is a massive spec, and it’s no longer just about the diagram shapes and symbols. In BPMN 1.x the acronym stood for Business Process Modeling Notation, and it really was about the diagram. In BPMN 2.0 they changed it to Business Process Model and Notation. Changing the “ing” to “and” was significant. The model is not just what is in the diagram, but all the semantic detail underneath each shape and symbol.
In fact, in BPMN 2.0 the parts that show in the diagram are just the tip of the iceberg. Most of BPMN 2.0 is below the waterline. What is all that stuff for? It’s to make BPMN not just a diagramming standard but an executable process design language, essentially a BPEL replacement. Will BPMS vendors adopt that? Some will, like IBM and Oracle. Many probably won’t. They will continue to use the notation part of BPMN, what you can see in the diagram, but will likely to continue to model executable design details in their own vendor-proprietary ways. Their tools will probably never support that below-the-waterline BPMN.
In my experience the vast majority of BPMN users are not doing executable process design, but simply describing and analyzing their as-is and to-be processes. You would think that the BPMN spec would distinguish between the “process modeling” part of the XML serialization and the “executable design” part. But then you would be wrong. It does not. Here is what the beta BPMN 2.0 spec says about “process modeling conformance”:
The implementations claiming Process Modeling Conformance must support the following BPMN packages:
- The BPMN core elements, which include those defined in the Infrastructure, Foundation, Common, and Service packages.
- Process diagrams, which include the elements defined in the Process, Activities, Data, and Human Interaction packages.
- Collaboration diagrams, which include Pools and Message Flow.
- Conversation diagrams, which include Pools, Communications, and Communication Links
In other words, a tool claiming process modeling conformance must support all of the spec except for choreography. All the details about how data, services, messages, and events are modeled. And not just for some of the types of activities, gateways, and events, but all of them.
That’s just silly, because almost any BPMN tool associated with either a BPMS execution environment or a real BPA metamodel is not going to support every bit of BPMN 2.0. The text in the draft BPMN 2.0 spec is a cynical attempt to assure no practical test of BPMN conformance is possible.
A practical test of BPMN conformance requires calling out a subset of diagram elements (and of the XML underneath each one) and stating what tool “support” of that subset actually means. Tools aimed at simplifying BPMN for certain business users might want a smaller subset than those aimed at analysts and architects, so to do this right you need multiple conformance classes defined in the spec. Tool vendors could assert compliance with one or more of those classes, and testing that compliance (by third parties, as OMG has no interest in this) would be fairly straightforward.
I tried to get such a proposal into the draft BPMN 2.0 spec. I failed, but Robert Shapiro has carried that effort forward in the Finalization Task Force phase, and today he succeeded in getting it on the ballot. You can see the proposal here. What that means is that in a few days, FTF members will vote to either approve the inclusion of these process modeling conformance classes in the final specification, or not. There is still some opposition to the idea, mostly from vendors who may not be able to claim conformance with all of the classes in their first BPMN 2.0 release. So there is a chance, maybe a good chance, that this will not pass.
So… If you want to see interchange of BPMN 2.0 models between tools, you need to make your voice heard, and quickly. There are twenty-some voting members of the FTF, including IBM, Oracle, Lombardi, Tibco, Global 360, Fujitsu, SAP, Cordys, Red Hat, CA, HP, BizAGI, iGrafx, Camunda, Trisotech, NIST, and MITRE. If you are a customer or partner of any of these organizations, please urge them to support the BPMN2.0 Process Modeling Conformance Class proposal. Time is of the essence, as the vote is in the next few days!
You can send email to ivana.trickovic@sap.com (the project manager of the BPMN 2.0 effort), and ask her to forward your message to one or all of the FTF voting members. This is important. Please send the email.
Tags: BPMN, bpmn 2.0, model interchange, model interoperability, process modeling conformance
Conformance classes are ABSOLUTELY CRITICAL to the adoption of the spec. The good work that you and Robert Shapiro have done leading this has been a great service to the BPM community.
I understand today a straw poll was held, and a decisions to drop SIMPLE from the conformance classes. That is too bad. The original design of BPMN (from the BPMI days) was a notation can could be used in a variety of different specific languages. It is too bad that the OMG only sees modeling for BPEL as the purpose of BPMN. The purposeful exclusion of all other uses of BPMN is not doing them any good. They are going to lose a lot of support.
It is entirely possible the BPMN will go the same way that CORBA did. We will just have to see.
[...] Silver macht sich in seinem Blog Sorgen um die BPMN 2.0. Der BPMN-Spezifikationsentwurf sieht verschiedene Konformitätsklassen für Modellierungstools [...]
[...] BPMN Tool Interoperability ? Make Your Voice Heard! « BPMS Watch Why it's important to support the BPMN2.0 Process Modeling Conformance Class proposal by lobbying the vendors involved in the vote. Otherwise, all that interoperability that you think is coming with BPMN 2.0 might not actually be there. (tags: bpmn) Posted by Sandy Kemsley on Tuesday, March 30, 2010, at 8:02 am. Filed under Links. Follow any responses to this post with its comments RSS feed. You can post a comment or trackback from your blog. [...]
Keith, I’m not sure that removing the simple class is so bad: it was almost too simple, and didn’t include some elements that are likely understandable to most business people, such as swimlanes, and some things that make the models much more useful, such as basic message and timer events. I find it hard to believe that any tool vendor would have implemented only the simple subclass, but most would have gone for the descriptive class in any case. As you might guess from my post on the BPMN update from last month, I’m glad to see the DoDAF subclass renamed to something that is more meaningful to the rest of us.
[...] 8. BPMN Tool Interoperability ? Make Your Voice Heard! [...]
[...] Bruce Silver writes: I failed, but Robert Shapiro has carried that effort forward in the Finalization Task Force phase, and today he succeeded in getting it on the ballot. You can see the proposal here. What that means is that in a few days, FTF members will vote to either approve the inclusion of these process modeling conformance classes in the final specification, or not. There is still some opposition to the idea, mostly from vendors who may not be able to claim conformance with all of the classes in their first BPMN 2.0 release. So there is a chance, maybe a good chance, that this will not pass. [...]
[...] On BPMN ? Bruce Silver The problem is that BPMN 2.0 is a massive spec, and it?s no longer just about the diagram shapes a… [...]
[...] people don’t need that complexity. Some, like Bruce Silver and Robert Shapiro are trying to rescue the situation, but the mere fact that committee has to argue over this case tells me that BPMN 2.0 is being taken [...]
[...] with a tool supporting the same conformance class. Bruce Silver has spelled this problem out in a recent blog post and I couldn’t agree more with his sentiment. The BPMN 2.0 Finalization Task Force needs to [...]
[...] adoption by tools vendors, consultants and trainers of a set of BPMN conformance classes (Bruce Silver has some good analysis of these) that were introduced at the late stage of 2.0 standardisation. So [...]