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.
Process Model Portability – Does Anybody Care?
[Posted 1 Oct 2007 on BPMInstitute.org]
Share This Story, Choose Your Platform!
About the Author: Bruce Silver
2 Comments
Leave A Comment
You must be logged in to post a comment.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Bruce,
A couple of comments …
1) BEA Aqualogic BPM Suite already provides a BPMN modeling mode although I’m not sure if it is totally compliant with the standard. On thing that is different about it is the use of curved rather than straight flow lines, but that’s probably not contrary to the standard is it?
2) I’m working on a project at the moment where model transportability is important. This is the first BPM project for the Client and while they are making all the right moves to select a suitable BPMS, they understand that each has its own strengths and weaknesses. To mitigate the technology selection risk, the first phase of the project involves only modeling, simulation and pilot implementation. If the initial BPMS were to fall short, they would re-evaluate the technology requirements and look for a more suitable platform. Obviously they would not want to re-develop the model in the new tool.
Warwick
Warwick,
Supporting BPMN is more than using rectangles and diamonds. It means expressing all of the flow semantics using the notation as described in the BPMN spec. This has nothing to do with vertical swimlanes or curved sequence flows or other things that give ALBPM its distinctive “look”. I think BEA actually agrees with this and will gradually move its notation to true BPMN. It would actually give them an advantage, because their engine is one of very few that can handle everything in the BPMN spec.
On the portability front, I am working with the XPDL 2.1 guys to try to define a “model portability conformance class”. The idea is that a conformant abstract model – abstract meaning essentially what prints in the BPMN diagram, not the data or other implementation attributs – would be portable between any 2 compliant tools. That would be HUGE!
Portability conformance would apply to a particular instance document Process.xpdl serialized in XPDL 2.1. My idea is this:
1. Define ClassNFilter.xslt, which applied to Process.xpdl generates ClassNProcess.xpdl. The resulting instance document contains only the elements and attributes required to be portable. This is easy. I’ve already done it.
2. Define ClassNValidator.xslt, which contains the validation rules. Applied to ClassNProcess.xpdl, it generates a list of errors based on the required elements and attributes and links between them. This is a bit of work, but doable. If there are no errors, we say Process.xpdl is ClassN model portability conformant.
There may be multiple conformance classes, depending on how much of BPMN must be supported, e.g. which event types, or compensation, etc.
A modeling tool asserting that it is ClassN compliant means that it can import any ClassN conformant model instance created in another tool and understand its meaning… at least as far as the elements and attributes contained in ClassNProcess.xpdl. The other elements may not be imported successfully but that would not forfeit compliance to ClassN portability. My hope is that a significant number of modeling tools would be base class compliant, and those that weren’t would feel pressure to do so.
I am confident this scheme would work, although it is a lot of work to create ClassNValidator.xslt (mostly a list of XPath expresions for the rules). I’m not sure I’ve convinced Robt Shapiro and the other XPDL guys of the value yet.