There's no denying that BPMN is gaining traction in the marketplace. I see it in my training. I see it in BPMS and BPA vendors getting on board. But what's amazing about this is that it's happening without a standard way to store and interchange BPMN between tools. It almost boggles the mind that the creators of BPMN "forgot" about this when they started, and its current owners place model interchange far down the priority list...

Bruce Silver, Contributor

July 31, 2007

3 Min Read

There's no denying that BPMN is gaining traction in the marketplace. I see it in my training. I see it in BPMS and BPA vendors getting on board. But what's amazing about this is that it's happening without a standard way to store and interchange BPMN between tools. It almost boggles the mind that the creators of BPMN "forgot" about this when they started, and its current owners place model interchange so far down the priority list (it's still not in the draft BPMN 1.1 spec, not yet released).

At the OMG Think Tank last week, I had a small roundtable on "what should be the purpose of BPM standards?" Not well attended, but it was the afternoon of the last day, and half the audience had left for home already. Besides, the topic was sort of a subtext for the conference as a whole, already beaten to death. But clearly there is no unanimity on the subject.BPDM is OMG's long-promised metamodel (and derived serialization) for BPMN. Its advocates, like Phil Gilbert of Lombardi and Antoine Lonjon of MEGA, are clearly driven by the need to make process models precise in their execution semantics. Advocates for XPDL, such as Keith Swenson of Fujitsu (who was there) and Jon Pyke, now of Cordys (who was not), focus on the diagram as a picture of the process, i.e. the graphical layout, in a machine-consumable form. I think both of those camps are wrong, or at least out of touch with the majority of BPMN users, who want nothing more than to be able to model - at a business level, not in full executable detail - their business process in tool A and be able to open it, edit it, or simulate it in tool B.

At our table I took a poll on these three meanings of what a portability standard for BPMN should provide. You could vote more than once:

▪ Business-level model in tool A can be opened, edited, etc in tool B. 100% ▪ All of the above, plus preserving the diagram layout (xy coordinates of shapes, fonts etc). 50% ▪ Model created in tool A runs identically on system B, C, etc. 0% The first bullet (my definition) also implies (to me at least, although maybe not made explicit in our poll) that tool B should understand all of the standard BPMN elements from tool A, not just some of them.

The second bullet is essentially XPDL's definition, with the understanding that tool B is free to support only a subset of BPMN.

The third bullet is essentially BPDM's definition, in a sense the answer to a question that few people are asking.

Dr. Bruce Silver is an independent analyst, consultant and author of the BPMS Watch blog. Write him at [email protected]There's no denying that BPMN is gaining traction in the marketplace. I see it in my training. I see it in BPMS and BPA vendors getting on board. But what's amazing about this is that it's happening without a standard way to store and interchange BPMN between tools. It almost boggles the mind that the creators of BPMN "forgot" about this when they started, and its current owners place model interchange far down the priority list...

About the Author(s)

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights