BPMN 2.0 Update

Last month, Robert Shapiro of XPDL 2.x fame, also a member of the BPMN 2.0 Finalization Task Force in OMG, delivered an update on progress toward completing both XPDL 2.2 and BPMN 2.0. Here is the link to the unedited replay. Also, Sandy Kemsley does her usual fine job of summarizing the high points here.

I would just add a couple points to the discussion. The first regards an explicit sorting of BPMN 2.0 shapes and symbols into subclasses for the purpose of enabling tool interoperability. I tried hard to get this into the draft last May, but IBM, Oracle, and SAP didn't want to commit to anything specific at that time regarding their initial "BPMN 2.0″-branded offerings. Apparently they are feeling more comfortable about it now, as Robert believes there is a chance this could make the final draft.Even though BPMN defines only three basic flow elements -- activity, gateway and event -- counting all the variants defined by border style, icons inside, markers, and diagram placement means there are dozens and dozens of semantically distinct shapes. No tool vendor with an associated BPMN engine, even a simulation engine, is going to support every single one. And that's just the part of BPMN above the waterline. Beneath each element are countless sub-elements and attributes required to define executable detail.

So if you create a model in tool A and expect to import it to tool B, both of those tools have to support a common subset of elements. That's what the subclasses are all about. Here is my view of them. The Simple class is setting the bar essentially at floor level. It is meant purely as a lowest common denominator. If a tool cannot support these shapes and serialize to BPMN 2.0, it should not be allowed to call itself a BPMN 2.0 tool, period. The Descriptive class corresponds to the Level 1 palette of my book BPMN Method and Style. It reflects what I believe are the shapes and symbols that should be understood by any business user who wants to read or write BPMN effectively. It is a challenge for tool vendors because it includes collaboration (pools, message flows, message start and end events). I hope those things stay in.

What used to be called the Analytical class, corresponding to my Level 2 "core" palette, got renamed DODAF in Robert's preso. It is very close to the element set standardized by Michael zur Muehlen in working with the DODAF people. I agree with Sandy that calling this BPMN class DODAF is maybe not the best for an international standard, but realistically it's all about user buy-in, and DODAF means a lot there. I suspect if OMG goes for it, they will change the name. This class includes the most commonly used intermediate events -- Message, Timer, Error -- plus a few more -- Escalation, Signal, Conditional. And additional gateway types, iteration markers, and other things. It sets the bar a bit high for tool vendors, but on the other hand, elements outside of the Analytical/DODAF class are unimportant, almost never used, and stand very little chance of ever being interoperable between tools.

OMG has studiously avoided any actual test of compliance for BPMN 2.0, so getting these subclasses into the final spec would be a major leap. Yes it's true that most users simply assume that a "standard" implies tool interoperability, but that has been mostly a fake objective in this case. I think there is hope this time. I've seen a beta of IBM's Compass BPMN editor, and it is very close to the Descriptive level, maybe a bit more. And I expect Oracle will have something similar.

But you have to understand that these standards are inherently very conservative, and always favor tool vendor "adoption" -- even in a proprietary way -- over constraints assuring interoperability. That's why it's important for OMG to hear from users telling them they demand some level of practical tool interoperability, such as this subclass proposal. If you agree, please email the BPMN group and tell them. The address is [email protected].

The second point concerns Robert's comments on the graphics information in BPMN. I wrote about this previously (The DI Mess), and in the end even the BPMN team managers in OMG admitted that what they put forward in the draft spec was unworkable. The new directives were to make the graphics interchange model a real BPMN-specific xsd and eliminate redundancy with the associated semantic model. Scott Schanel and I put forward a BPMNDI.xsd proposal that does this, and Robert's preso says that the official OMG effort here carries forward our ideas. Having seen a draft of it, I would dispute that -- it's still too much like the old one for my taste -- but the good news is that there seems to be forward movement at last on it. More good news is that Denis Gagne is driving the xsd side there (still the tail on the UML dog unfortunately), and since he is launching the Process Incubator tool referenced by Robert -- mappings between Visio, BPMN2.0, and XPDL 2.2 representations -- he will ultimately force himself to see which parts of BPMNDI are practical in real tools. That's always helpful.

There is a lot still to do on BPMN 2.0 before the final vote, but all of it "under the covers" so to speak. Nothing significant in the notation or semantics is going to change.Last month, Robert Shapiro delivered an update on progress toward completing both XPDL 2.2 and BPMN 2.0... I would just add a couple points to the discussion. The first regards an explicit sorting of BPMN 2.0 shapes and symbols into subclasses...