The Case for Conformance
It is hard to call the Business Process Modeling Notation anything but a success. Stephen White and the other members of the BPMN standardization group have spent nearly 10 years developing and fine-tuning a common graphical representation for business processes, and both tool support and user uptake have been heartening. But BPMN never had one critical element – a stepwise path for users and vendors that allowed them to phase in the use of individual symbols while making sure that the resulting models could be moved between tools. The original BPMN specification had the distinction between a simple subset of the language and the full set, but nobody I know found the simple set sufficient to do any meaningful modeling.
The new revision of BPMN, 2.0 has more than 50 symbols in its full set. For users and vendors alike, it is unlikely that we will see support for and use of every language element out of the gate (notwithstanding the BPMN 2.0 support in modeling tools like Signavio). So, vendors will phase in new symbols over time, and users will extend their models with these symbols as they become available (and are deemed useful). But if there are no milestones on the way from what is supported today to the full BPMN 2.0 symbol set, we will see varying subsets by vendors, which will make interoperability difficult to impossible. Conformance classes provide these important milestones – they are targets that vendors and users alike can rally around, with a reasonable expectation that a tool that supports the symbols of a conformance class will be interoperable with a tool supporting the same conformance class. Bruce Silver has spelled this problem out in a recent blog post and I couldn’t agree more with his sentiment. The BPMN 2.0 Finalization Task Force needs to see this through. A standard specification by itself is not sufficient to ensure that the standard will be usable – and who has more authority to put forward such guidelines than the BPMN standardization group itself?