Among the numerous virtues of BPMN, foremost is vendor independence, giving process modelers many tools to choose from, all describing processes using the same shapes and semantics. That’s huge, since without low-cost (or even free) tools you’ll never establish a culture of process broadly throughout the business. Occasionally, however, a student in my BPMN training will ask the embarrassing question, “So that means I can take the models I create in this class and import them into the BPMN tool we use in our company… Right?” Uh… well, not necessarily.
It seems that the number one reason for creating a standard in the first place – portability and interoperability across tools – was somehow forgotten by the BPMN standards committee in OMG. And a good solution is not yet clearly in sight.
First of all, lest anyone doubt that BPMN has become the de facto standard for process modeling – at least where BPMS-based implementation is contemplated – then consider that Appian, Lombardi, Savvion, Tibco, Intalio, SoftwareAG, and Oracle all use it today, and IBM, SAP, and BEA are planning to move to it soon. If BPMN is not on the analysts’ BPM RFP checklist today, it certainly will be next year. That’s what makes it so unbelievable that we still lack a standard XML interchange format for BPMN models.
There are three potential solutions on the table. All of them have problems, some fundamental, some fixable. But fixing the problems requires pressure from the BPM user community, pressure that so far has been absent. Tool vendors, it seems, like to import from standard formats, but export… not so much.
Solution #1 is to use BPEL as the model interchange format. BPEL is an OASIS standard for executable processes modeled as orchestrations of web services. Among the BPMN vendors, Oracle is perhaps the leading proponent of this approach. BPEL has in its favor the fact that it can handle BPMN’s event and transaction compensation behavior, and is a well-defined standard designed for portability … at least for the parts of the process described by BPEL. The problem, however, is that BPEL 2.0 does not describe human tasks, subprocesses, and other central features of BPMN process models. Also, BPMN’s freeform activity flows do not always map easily to BPEL’s “block-oriented” structure. But one can at least envision how BPEL, enhanced with People and Subprocess extensions, could be used for BPMN interchange, or at least a subset that excludes a few unmappable routing topologies.
Solution #2.is to use XPDL from the Workflow Management Coalition. XPDL was originally created to allow interchange between process modeling and workflow automation tools. Developed in a pre-SOA era, XPEL 1.0 lacked the necessary event-handling features, but version 2.0 was extended to include all of the elements described by BPMN. A lingering problem with XPDL is that it focuses on interchange of the diagrams but not necessarily the underlying process models. Not only does XPDL not demand that “compliant” tools support any particular subset of BPMN semantics, but it does not even insist that all tools serialize the same diagram in the same way. I have urged them to make model portability a priority in the upcoming XPDL 2.1, and I believe they will. I think users want to port the models, not just the pictures. But I believe WfMC is sensing a new opportunity here. Given that most BPMSs today are not BPEL-based, XPDL 2.1 has a much better chance of becoming the accepted interchange standard for BPMN.
Solution #3 is OMG’s own Business Process Definition Metamodel, or BPDM. BPDM has the singular advantage of being the officially sanctioned BPMN interchange standard from the organization that owns BPMN. However, it suffers from some serious problems of its own, not the least of which being that its developers believe they need to “fix” BPMN before they can serialize it, since (they say) the semantics are not precise enough. Precise enough for what? After hours of discussion with these guys, it turns out that they mean precise enough for identical runtime behavior or for exact mapping to UML. For me, that’s when the alarm bells go off, since if you believe that the implementer’s view of a BPMN process is really UML or Java, you’re out of touch with today’s BPM. In any case, the ability to create a BPMN model in tool A and then edit it in tool B is not the same goal as generating unique UML or Java code from a particular BPMN diagram. The former is a real need of process modelers today, as imperfect as BPMN 1.0 is. But OMG’s goal with BPDM appears to be the latter. Whatever merits it may have as a formal metamodel, I just can’t see BPDM succeeding as an interchange format for BPMN process models in the near term.
Each of these “solutions” to BPMN model portability, you may have noticed, is actually a by-product of some other goal of the standards committee, which explains why none hit the mark. But is model portability even an important goal? If so, practitioners need to make that need felt by the standards bodies, the analysts, or someone. And what does portability even mean? Do you need to preserve the exact look of the diagram? Do you need to preserve the same runtime behavior? Is BPMN even about specifying precise runtime behavior? Unfortunately, there is no consensus on these questions.
