I’m back on one of my favorite topics: portability of BPMN from one tool to another. BPMN is a standard so portability is a given, right? Wrong. Not even close. In version 1.x, BPMN didn’t even provide an xml schema to export to, much less a declaration of how much of it needed to be understood by the importing tool.
Oh well. BPMN 2.0 will fix this! Right? Well, not exactly… OK, there is a schema, but until yesterday if your model did not specify service interfaces and data mappings it could not be schema-valid. Yes, really! Fixing this was my first success as part of the IBM-Oracle-SAP (IOS) team working on BPMN 2.0. It only took 3 months of drafting and redrafting language simply to allow these execution-related elements and attributes to be made optional in the xsd.
Mission accomplished? Let’s not put the banner on the aircraft carrier just yet. That’s just half the problem, allowing a non-executable model to be exported to valid xml. Less than half, really…
The hard part is specifying how much of it must be understood by the importing tool. There is a part of the BPMN 2.0 spec called Process Modeling Conformance (as opposed to Process Execution Conformance), but it basically just says a tool claiming this must support the BPMN semantics and shapes in the spec. You could interpret this either as all the semantics and shapes, or some of them. Do you know any BPMN tools – other than those lacking a runtime entirely – that support all of the BPMN 1.1 spec? No, I don’t either. So the current draft of Process Modeling Conformance either defines a club with 0 members or one that anyone can get in. It’s not going to be a reliable measure of model portability.
The second half of my crusade is trying to convince the IOS people responsible for this section of the spec to follow the example of XPDL on this topic. (XPDL 2.1 was specifically designed to support all of BPMN 1.1). Generally speaking, OMG would rather take cyanide than follow WfMC’s lead on anything, so I’m trying to drum up some popular support for the idea. It’s based on levels of conformance. XPDL defines 3, and I think that’s about right. A base level would include the common subset of semantic elements supported by almost all tools, leaving out important BPMN innovations like boundary events. The next level would include all flavors of the important gateway and event types, but leave out rarely implemented ones like compensation event or complex gateway. And there would be a full conformance level meaning everything defined in the spec. If a tool claims a given level of conformance, it means it can import and understand all the elements in that conformance class. Nodes outside of that conformance class could be ignored, mapped to something else, or… well, that’s to be worked out. Ideally the exporting tool can make sure there is nothing that would break the import for a specified conformance class.
If you had this, you could count on developing a non-executable model in BPMN tool A and import it into a different BPMN tool B and continue editing it. Isn’t that what BPMN users expect??
One part of the BPMN 2.0 xsd that is still questionable in my mind is the graphics layout information. OMG opted to follow a generic diagram interchange approach rather than a BPMN-specific one, with the result that the BPMN diagram graphics are not really defined by a schema (it’s a schema plus an M1 library, if you understand what that means). So the graphics part may or may not be to BPMN tool vendors’ liking… or those vendors could elect to graft on XPDL’s more straightforward graphics info to the BPMN 2.0 schema via an extension element.
Model portability is not pie in the sky. XPDL is doing it today, thanks to a lot of hard work by Robert Shapiro of Process Analytica and his colleagues. Here’s how it is explained in the XPDL spec:
BPMN can be used for both ?abstract? activity flow modeling and for complete executable design. Many tools, however, make use of BPMN for the abstract modeling but add executable detail in tool-specific activity properties. One goal of XPDL 2.1 is to promote portability of abstract activity flow models between tools. This requires separating the elements and attributes of BPMN related to activity flow modeling from those related to executable design. The BPMN spec does not define this separation, but XPDL does, in the form of BPMN Model Portability conformance classes.
In broad terms, the ?abstract model? elements are those that represent BPMN constructs that are printable in the business process diagram, such as those defining the flow object type or subtype (e.g., looping User task, collapsed subprocess, exclusive gateway, timer event), including only attributes specifying the subtype, label (Name attribute), and unique identifiers for the object itself and pointers to other identifiers in the diagram. Elements and attributes representing data, messages, or other implementation detail are omitted from the abstract
process model. In other words, the model describes the ?what? and the ?when? of process activity flow, but not the ?how? of flow object implementation.
XPDL defines three Model Portability conformance classes, SIMPLE, STANDARD, and COMPLETE. A modeling tool asserting compliance to one of these classes means that the tool can import and understand all parts of a serialized BPMN instance conformant to the class. All three classes exclude implementation-related XPDL elements and attributes. All three classes exclude vendor specific extensions via the use of Extended Attributes or user name spaces. They differ only in the set of abstract modeling elements supported.
The SIMPLE class includes the following BPMN objects: task, collapsed subprocess, gateway (exclusive data-based, inclusive, parallel), None start and None end events, pool, lane, data object, text annotation, sequence flow (uncontrolled, conditional, default), and association.
The STANDARD class includes the following BPMN objects: task (task type User, Service, Send, Receive); collapsed and expanded sub-process, looping or multiinstance activity, gateway (inclusive, exclusive data-based, exclusive event-based, parallel), start events (None, message, timer), catching intermediate events in sequence flow (timer, message), throwing intermediate events in sequence flow (message), attached intermediate events (timer, message, error), end events (None, error, message, terminate), pool, lane, data object, text annotation, sequence flow (uncontrolled, conditional, default), and association.
The COMPLETE class includes all task types, all event types, and all gateway types described by BPMN 1.1, message flow, transactional sub-process, and ad hoc sub-process.
Each class is described by a filter transform (xslt) that can be applied to the XPDL instance, leaving only the elements and attributes of the class. If the original XPDL is schema-valid, the filtered XPDL will also be schema valid. A second transform provides additional validation rules required for conformance. If the original XPDL is identical to the filtered XPDL and has no validation errors, the original instance is said to be conformant to the class. If the original XPDL is not identical to the filtered XPDL, but the fi ltered XPDL has no validation errors, the filtered XPDL represents the class-conformant portion of the original instance.
We will provide tools for validating BPMN abstract model portability conformance levels. We envision other BPMN portability conformance classes, and other levels of abstract model portability conformance may be introduced in the future.
OK, that’s just a spec. Does it work? Robert Shapiro sent me these examples today of SIMPLE class portability. In all cases, the first diagram in the pair is the exported BPMN diagram and the second is the diagram imported to Global 360 Sketchpad, which is Robert’s tool:
1. BizAGI
2. TIBCO
3. ITP Commerce – Process Modeler for Visio (tool used in BPMessentials training)
4. Fujitsu
I think this is pretty cool! The portability isn’t perfect, but the individual tools’ fidelity to the BPMN standard isn’t perfect, either. And with this kind of interchange, the tools actually get more uniform and the port gets more perfect. Hats off to Robert for this. Now I want to see more… Adobe, Appian, Savvion, IDS Scheer, Mega, Oracle (ALBPM) … any BPMN tool that exports to XPDL. And not just mapping to Sketchpad, but to each other. And let’s not forget roundtripping!!
If you agree this is good stuff, check out the XPDL developer center for more info. If you are at Gartner in San Diego, you may want to stick around to hear Robert talk about this on Thursday of that week. Details are on the WfMC site. In any case, if you think this is valuable work, let me know.
I am not advocating XPDL as an alternative to BPMN 2.0. I think BPMN 2.0 is going to be the serialization of choice, but so far the people defining it don’t fully appreciate the value of non-executable models (!) or of portability between tools (!!). XPDL gives them a good path to follow on these.
Very useful information. I looking for software to design processes in my company. Many Thanks!