Model Portability in BPMN 2.0

This post is the third in a series of comments on the BPMN 2.0 submission by IBM et al to OMG.

For me, process model portability is such an obvious goal of a notation standard like BPMN that it almost goes without saying. But we cannot take it for granted, because since BPMN 1.0 in 2004 the standard has not even provided an XML schema for the serialization. BPMN 2.0 was supposed to address this issue head-on at last. While it does offer a schema, it still lacks critical elements needed for model portability. I would be very disappointed if these were not addressed in the final version.

First, it's important to note that the proposal opens with a strong statement in favor of the notion of portability, saying:

There is a human level of ?inter-operability? or ?portability? that is not addressed by... web service-based XML execution languages [such as BPEL].... Inter-operation of business processes at the human level, rather than the software engine level, can be solved with standardization of the Business Process Modeling Notation (BPMN).... Currently, there are scores of process modeling tools and methodologies. Given that individuals will move from one company to another and that companies will merge and diverge, it is likely that business analysts are required to understand multiple representations of business processes.... A standard graphical notation will facilitate the understanding of the performance collaborations and business transactions within and between the organizations.
Providing an XML schema and relating its elements to the semantics of the notation is a key contribution. We've been waiting for this since 2004, and the proposal delivers on that score (in a far superior way to the rival BPDM submission). But this is nowhere near enough to provide assurance that if you create a valid BPMN diagram in tool A, you can reliably import and edit it in tool B. Not only does this assurance fall short of the modeler's needs, the spec does not even give tool vendors A and B adequate instructions for fulfilling the portability vision.

So what else does the BPMN spec need to provide model portability? Four things:

1. Assignment of MUST-SUPPORT requirements to a subset of flow elements and semantics. More likely we are talking about various tiers of flow elements, with a bare minimum in the base tier restricted to familiar flowcharting symbols, and other tiers that add things like pools, events, and message flows. Model portability would be defined as follows: A BPD belongs to the portability class of tier N if it contains only flow elements and semantics described by that tier. Then, a modeling tool can claim it supports tier N model portability if it can import (and continue to edit) the serialization of any model conformant with that class, in particular those created with other tools. The BPMN 2.0 proposal does not require tools to support any particular subset of elements, nor does it define tiers of portability.

2. Beyond restriction to the subset of elements defined in a tier, in order for a tool to "understand" the serialization provided by another tool, the rules for the serialization must be precisely defined. Ideally there would be only one way a particular diagram fragment could be serialized. If there were more than one, a tool claiming portability would have to be able to understand all of them upon import. The BPMN 2.0 proposal fails to provide this, at least explicitly.

3. BPDs can only be considered portable if they are valid. That requires BPD validation rules. Most real BPMN tools today can validate models, but they do not all use the same tests because the current spec does not enumerate the rules. Sad to say, neither does the BPMN 2.0 submission. As with BPMN 1.x, they are buried in the narrative. If such a list of rules were enumerated in the spec, I have no doubt that you would see open source validation routines (xslt, web services, etc) available. It would be very easy to test the validity of any diagram, and consequently you would see far fewer invalid ones.

4. The fourth missing piece is something that allows users to know which tools comply with the portability provisions of the spec. One of the problems with BPMN today is that any tool that includes boxes, arrows, and diamonds can claim to be BPMN... and usually does. There should be some facility for testing compliance and for publicizing tools that meet the requirements. I have no expectation this would ever be in the BPMN 2.0 spec. But I can dream.