Bruce Silver has recently posted his latest efforts to perform BPMN model interchange.? It has been a recurring theme on his blog, BPMN 2.0 and its potential for interchange, as well as XPDL's capacity for interchange.? Recently Bruce went on vacation and spent his time in a rather dubious way (just kidding, Bruce!):
On my summer vacation I?ve been thinking a lot about the XML side of BPMN.? While we usually think of BPMN as a diagramming standard, it is also ? in principle ? a model interchange standard, an XML format than can be exported from tool A and imported into tool B.? BPMN 2.0, XPDL 2.1 (for BPMN 1.2), and XPDL 2.2 (for BPMN 2.0) all purport to deliver this.? In reality, however, BPMN model interchange faces serious ? some would say insurmountable ? hurdles.? I have been working on a number of tools to overcome these obstacles.
So the holy grail of model portability isn't fully realized yet.? But BPMN 2.0 does represent progress.? He goes on to outline what has to happen to enable model portability:
1. An explicitly enumerated set of interchangeable model elements and attributes.? The full BPMN 2.0 schema is too open-ended for unrestricted interchange.? Fortunately, we now have such an enumerated list in the Descriptive and Analytic process modeling conformance classes in the BPMN 2.0 spec.
2.? Modeling tools that unambiguously support all the elements and attributes in those conformance classes, meaning the mapping of diagram shapes and labels to the standard is unambiguous.? We have a number of such tools today.? My work has focused on two of them: Process Modeler for Visio by itp commerce, which supports both BPMN 1.2 and 2.0, and native Visio 2010 Premium, which is just BPMN 1.2.
I agree that getting a complete set of BPMN 2.0 elements explicitly enumerated is going to be difficult.? And getting the modeling tools to support all the elements and attributes, not to mention exporting them as XML, is too much to expect from our modeling tool software partners.? I believe the only way we're going to get this kind of interchange is with an open-source project - because open source projects excel at eventually covering wide specifications as people volunteer to fill in the gaps.? Interchange of data, and support for a wide specification, are both well-suited to open source projects - if they have the right framework in place that makes it clear how a newcomer can add to it (by, for example, adding a new exchange adapter).? I can envision a pretty interesting model interchange utility that would read a variant of BPMN2 produced by some tool, and perform a little magic on it to produce "clean" BPMN 2.? Then a second adapter that would produce BPMN 2 that a target BPMS tool expects.? The author (say, Bruce) doesn't have to solve all the possible interchange combinations, just provide a framework and an example, and see what other interchange adapters people will add to it.
That's the beauty of open source - if you build the framework, and make it "accessible" to developers... then if there is a need for something, it will be built.? If not, it won't.? Not too much wasted effort.