The big feature coming in BPMN 2.0 is the ability to serialize the model into a form that is portable between tools.  Regular readers of this blog will know that we have this today with XPDL, but those responsible for the future of BPMN say “We are going to give you something better.”  OK, I am all for progress to something better, but are they really going to achieve this?

Bruce Silver asked the question, “What do you really need for model portability?” He points to four key principles:

1. Assignment of MUST-SUPPORT requirements to a subset of flow elements and semantics.

2. The rules for the serialization must be precisely defined.

3. BPD validation rules.

4. There should be some facility for testing compliance and for publicizing tools that meet the requirements.

This is all good common sense.  For #1, we remember that BPMN is designed to be “Methodology Agnostic“.  This means that there are a variety of different shapes and symbols, the meaning of which is clear, but are not necessarily all required to implement a particular method.  This agnosticism is absolutely essential to the broad adoption of the standard, but it flies in the face of model interchange.  Since the BPMN dictionary includes a wide range of symbols for any occasions, it is neither expected nor reasonable to expect all tools to cover all cases.  Studies are being done today at the Department of Defense and universities on what symbols are needed most often, and what can be left out.  We know that some symbols are redundant, and that there are multiple ways to do things.  It is critical then that the standard specify a MUST-SUPPORT subset, which represents the least common denominator of all process modeling programs.

Items #2, #3 and #4 should not be controversial.  The definition for serialization must be reduced to a form equivalent to programming logic, with all ambiguities removed.  If there are ambiguities, it means that different packages might interpret the parts differently, and you will fail to have portability.  This goes hand in hand with validation rules.  And if you are going to specify this precisely, you might as well provide a validation facility, at a very minimum to prove that the specification is complete enough to produce such a test.  In many ways, if this validation program does not exist, then the specification is “untested” in any real sense.  I am not from Missouri, but I still want to see that such a program exists, before I believe that it is possible to build one.

Comments on his post suggest that this goal might have to wait for BPMN 2.1.  If you release a serialization spec that is ambiguous without formal validation criteria, then you are inviting vendors to implement it, and risk the very real possibility that when the validation rules are finally published, that their original interpretation might be wrong.  There might be multiple products out there that interpret the ambiguous aspects differently, and no matter what you do, some of them are going to “lose”.  It is even worse for consumers: you might designing processes and save them in a format which ends up being a dead end.  It seems strange to be suggesting that you wait for 2.1 before 2.0 is even out.

Making a solid standard that will stand the test of time is hard work.  I applaud the goals of the BPMN group to attempt to make something better than has existed before, but going only half-way to a broad scope can be worse than nothing at all.  It is certainly less attractive than doing a good job on a diminished scope.  Bruce ends his post in a resigned tone: “I have no expectation this would ever be in the BPMN 2.0 spec.  But I can dream.”

And so we all must dream.  If you know someone involved in BPMN work, please ask them about what is being done to insure BPMN “Model Portability”.  And then ask them to prove it.