I have long railed against OMG’s inexcusable omission of even minimal support for model portability in the BPMN standard. In the forever-stuck-in-final-edit version 1.1, they still haven’t even provided an XML storage format, or serialization, for BPMN, much less a list of the elements and attributes that any “compliant” tool must support. Yet in my BPMN training, students simply assume such portability exists. After all, isn’t that the fundamental purpose of a standard?
OMG is promising to provide an XML schema for BPMN in its forthcoming Business Process Definition Metamodel, or BPDM, expected in March. But I am skeptical that effort will deliver on what my students want, because BPDM’s backers view BPMN portability from the perspective of runtime execution. In the real world, BPMN is not used to define the fully executable semantics of a process. It is just used to define the activity flow, where activities are defined abstractly, essentially just by name, basic type (e.g. human task or automated service), and its control flows (called sequence flows in BPMN) in and out. That’s it.
In BPMN-based BPM suites, the implementation of each activity, including its data and associated logic, is almost always specified in vendor-specific properties, not in attributes defined by the BPMN spec. And that makes complete sense, because BPM Suites have not standardized on a single language or metamodel for process execution. No one expects complete portability at the executable level, but they do at the abstract modeling level.
The use case is basic. Process modelers don’t want to be locked into a runtime before they begin, and they want to be able to reuse their BPMN models in other compliant modeling tools.
Abstract model portability is a lot easier than what BPDM is attempting, since many BPMS-based process engines can handle a core subset of BPMN activity flow semantics. But the BPMN spec offers little help, since it doesn’t distinguish between elements and attributes that belong to the abstract modeling domain versus those in the executable implementation domain. But in fact, that’s not very hard.
As I said earlier, the BPDM people have little interest in abstract business-level modeling in the sense I am talking about. They seem to be more focused on integrating BPMN in its MOF-based model-to-code infrastructure. On the other hand, the editors of the forthcoming XPDL 2.1 standard from WfMC – an update to BPMN 1.1 – were receptive to my ideas about abstract model portability, and have added a section on it to their draft. Here’s how it would work.
Starting with the XPDL produced from a BPMN diagram, the first step is to strip out all but the abstract modeling-related attributes and elements. This is done by a standard XSLT transform applied to the original XPDL, creating a filtered serialization based on the same XPDL schema. If the filtered XPDL is the same as the original, the tool could claim to output portable XPDL, but that’s not necessary. At least initially, most BPMN tools will produce XPDL that contains tool-specific elements and attributes. A tool can still claim to support abstract model portability if it can import and understand the filtered – that is, portable – XPDL.
There are two key issues in making this a reality. One is agreement on which elements of BPMN are included in the filtered diagram. The other is tightening up how diagrams are serialized, so that all BPMN tools convert the same diagram pattern to the same XML.
The abstract modeling part of BPMN is essentially the part that is visible in the process diagram. That includes the flow object type and its basic subtype, typically indicated by an icon inside; its name or label in the diagram; and its unique ID, important for holding the elements together in a model. That’s pretty much it.
The hard part is agreeing on which subtypes of activities, gateways, and events must be supported for compliance. Modeling tools with no runtime engine may support the full BPMN spec, but BPM Suites typically support just a subset. In my experience, tools fall into three categories, which in principle define three model portability conformance classes. The first, the bare minimum, includes human and automated activities (User and Service tasks in BPMN), lanes, reusable subprocesses, exclusive and parallel gateways, and None start and end events. Almost any BPM tool supports this SimpleConformance class, but without events it’s not particularly interesting.
The next level encompasses tools that have made a serious attempt to follow the BPMN standard. This class, what I call StandardConformance, includes also timer, message, and error events, Send and Receive tasks, embedded subprocesses, looping and multi-instance activities, event gateways, inclusive gateways and conditional sequence flow, and multi-pool choreography. This is the class of real interest, because it includes the most important elements of BPMN.
And there is also FullConformance, which means everything defined in the BPMN spec, including transaction compensation.
The hardest part may be getting tool vendors to serialize the same diagram in the same way. I did a simple experiment, looking at serializations of the Voting Process diagram from the BPMN spec. I compared the XPDL produced by two tools that both support the StandardConformance elements: TIBCO Business Studio and ITP Commerce Process Modeler for Visio.
The results were a bit disheartening, as there were significant differences in three areas: subprocesses, gateways, and implicit splits and merges when multiple sequence flows go into or out of an activity. My takeaway is that the XPDL spec needs to be more prescriptive on serialization of core patterns, as both tools can’t be “right” when the same diagram pattern generates different XPDL. That means that vendors will have to change their tools – and some vendors will have to change more than others.
So WfMC is at least opening the door to BPMN portability at the abstract modeling level. There is a definite upside for them, as I think they could offer a more practical approach to diagram interchange between tools than OMG’s own BPDM. But getting there will be painful for XPDL-based tool vendors, and to make model portability a reality, I think they need to see a demand for it.
