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.
Great thoughts as always, Bruce.
Unfortunately BPMN will take some time to get to the specification standard of an old language like FORTRAN but we can at least divide the tool builders into two camps … those that care about compliance with the spec and portability and those that are simply ticking boxes on a tool purchaser’s RFP. Even if the spec does not enumerate the rules, a tool builder can produce an explicit compliance list and over a few iterations of a few tools we (as users) might see a composite set of rules. Perhaps at BPMN 2.1 that composite set will be an annex to the spec.
[…] Model Portability in BPMN 2.0 – BPMS Watch – Bruce Silver's continuing commentary on the new BPMN 2.0 submission. Today: how portable are these models, anyway? […]
Hi Bruce,
Good piece although, as you might expect, we have different perspectives on the requirements. There is no need for “human readable XML” which, in any human-friendly world is an oxymoron. What is required are, certainly, your #1 and #2 above, at a minimum. Even the specification’s statement that you quote puts the human in the graphical notation… not the XML.
We need to develop BPMN tools that are so good (and so interoperable, with deterministic interpretation of the diagrams) that humans-reading-XML isn’t required. That’s a BPEL-like answer… we need to move forward in the power of graphical interfaces. XML is the MS-DOS of model-driven computing.
Phil
ps – of course, there is disagreement on this within the BPMN spec-writing community at large. Some vendors are quite happy to require that BPMS users be able to read XML. I disagree. We have the capability to make the notation rich enough… why don’t we focus on that? Could it be that there’s corporate strategy involved… http://blog.lombardicto.com/2008/07/waiting-until-y.html
Honestly, Phil, I did not expect we would have different perspectives on the need for model portability. And I don’t recall saying anything about human-readable XML in this piece, either. I do have a preference for XML based on schemas and that works with regular XML tools, which would favor the IBM submission over BPDM. Not sure what you mean by XML is the MS-DOS of whatever, Is the issue that it has tags and is “unfriendly” to view in text format? I guess then HTML is the MS-DOS of the web.
[…] Model Portability in BPMN 2.0 – BPMS Watch (tags: bpmn bpmn2.0) […]
[…] Silver asked the question, “What do you really need for model portability?” He points to four key […]
[…] Model Portability in BPMN 2.0 « BPMS Watch […]