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:

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 [email protected] (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.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.