Aug 25, 2010 (11:08 AM EDT)
BPMN Model Interchange: Clearing the Hurdles
Read the Original Article at InformationWeek
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.
To achieve BPMN model interchange, you need the following:
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.
3. XML export (as BPMN 2.0 or XPDL) from those tools. Process Modeler exports either BPMN 2.0 or (in the Pro edition) XPDL 2.1 for BPMN 1.2. There are a couple problems with it in the current build, but I expect those to be fixed shortly. Visio 2010 Premium has no native XPDL or BPMN export. (Global 360′s analystView add-in provides XPDL 2.o but does not fully support either the Descriptive or Analytic conformance classes.) The good news is I have developed a tool that produces either XPDL 2.2 or BPMN 2.0 from Visio 2010 Premium, absent a few BPMN 2.0 shapes missing from the palette: non-interrupting events, escalation, CallActivity, etc.
4. Validation of user-created models to support effective interchange. Four distinct types of validation are required:
3. Schema validation of the exported XML, either XPDL or BPMN 2.0. You might think that tools would always produce schema-valid XML, but they don't, for two reasons: First, they either ignore the published xsd or reference an outdated version. Second, the user-created diagram may be inherently invalid. For example, if one end of a message flow is drawn dangling in space (or is improperly connected to a flow object), its required sourceRef or targetRef attribute in the XML will be missing.
4. Adherence to certain conventions that allow unambiguous serialization of the diagram. These conventions go beyond the requirements in the BPMN spec, and they could be thought of as "style rules." Many of them are also important for human readability of the diagrams and are identical to rules I require in my BPMN Method and Style certification exercises. I have created a validation tool that looks at exported BPMN 2.0 and lists violations of both BPMN rules (4.1 above) and these conventions/style rules. I originally built the tool to automate examination of student certification exercises, but it turns out to have broader value. A fundamental Method and Style principle is that the process logic should be evident from the diagram itself -- the shapes and labels, nothing more, no reference to BPMN details with no visual representation. That is consistent with the information contained in the BPMN 2.0 conformance classes, which explains the alignment of Method and Style conventions with diagram conventions needed for proper serialization.