Just received a note from Phil Gilbert of Lombardi, a key contributor to the BPDM effort in OMG, that says:
[I] wanted to let you know that the OMG Architecture Board voted to approve the BPDM spec today. There are actually 2 more small hurdles instead of 1 more as I told you earlier. But these are 99.9% certain to approve specs that have passed the Architecture Board review. Apparently these take several weeks calendar time as the boards that approve aren’t on the TC calendar, they have their own.
In any event, it appears that a major milestone for the industry has been passed: a specification for a business process metamodel (as opposed to UML-defined process) is poised to achieve standards status and have the backing (and implementation) of process platform and modeling vendors. This will insure a standards-based way in which BPMN models can be exchanged, and both standards are driven by the same organization, allowing for unprecedented alignment. In fact, at this meeting, the next major version of BPMN is being discussed and it is expected that the focus will be on using that effort to merge the BPMN and BPDM specs, so that there will be one modeling spec, and that spec will have it’s explicit notation and its explicit metamodel.
The first step was to define the notation, and now we’ve defined the metamodel.
I think end-user companies are the winners today. There is now clarity around the implementation of process at the business level, and that clarity is in the form of business-based process notions, not IT- and systems-based notions of process.
This message was an update amplifying a previous one that announced BPDM approval by the Domain Task Force:
… this morning in San Diego at the OMG Technical Meeting, the Domain Task Force voted FOR approval of BPDM! This is the second major hurdle of any spec. The first is the RFP which kicks off the submission team… that was done long ago for BPDM. The second is the DTF vote (which occurred today). The third is the review and vote by the Architecture Board, which will happen Friday of this week. Then the OMG Board ratifies the AB decision within the next 30 days or so.
While it is rare, the AB can reject or send back a spec for more work, but in general the vote of the DTF is the more difficult barrier because of the diversity of companies (and interests). The AB is more focused on the technical implementation of the specification and less concerned with the business issues that may be reflected in the votes of all the member companies.
Phil also replied to my questions with some answers from Lombardi and MEGA representatives on the BPDM submission team:
Q. How would you create serialized BPMN from BPDM?
A. We are updating the EMF plugins. This will allow creation of BPDM models using Java. Additionally there will be a very basic editor (not usable by business people) that will allow a developer to create BPDM models and to look at the produced xml. The goal is to have these plugins updated for Monday 26 March. This will also be discussed on Sunday by the submission team. Most likely we’ll do a presentation about the serialization of BPMN using BPDM and we’ll show the actual XML that is produced.
Q. Could xsd be derived from this xmi document?
A. Yes. EMF provides such capability. XSD most likely will not be part of the submission, but a separate document that will be distributed freely.
Q. Do you expect OMG to provide one?
A. Yes. During the meeting we will create and distribute the XSD.
Q. Can standard xml validation be used?
A. Yes. Using the provided XSD.
Q. Can I use XSLT [to transform and validate models]?
A. Yes. However XSLT is not very suitable for performing model transformations. For object models there are better languages that can transform models. One such example is QVT. On the Eclipse.org you can find other languages also.
Q. Is there some example that can be used to understand BPDM?
A. We are working on an example that demonstrates BPDM features. This is incorporated in the html documentation that is generated. Most likely it will need additional explanations, to be provided after the approvals
March 26th, 2007
My comment on Keith Swenson’s XPDL-BPEL apples-and-oranges post and the failure of XPDL to fill the vacuum left by OMG in the BPMN specification stirred up an interesting response from Keith that reinvigorates the discussion and helps clear the air. But he still frames the discussion in terms of portability of executable designs rather than portability of models (i.e. abstracted from implementation details). In the XPDL vs BPEL discussion, this is appropriate, but in the discussion of BPMN portability it misses a fundamental point.
He says:
Bruce has criticized XPDL for inability to take an executable process from one vendor product, and bring it to another vendor product, and guarantee is it understood. He is right. There is no guarantee that a process drawn in one product, saved in XPDL, will be immediately executable in another product. This is not because XPDL fails to capture the semantics, but instead a failure to (1) be able to unambiguously capture those semantics in standard BPMN, as well as (2) a failure of the receiving tool to understand the same semantics that the sending tool transmitted.
In the first sentence above, replace “an executable process” with “a process model.” And there you have the essential problem, because I would say BPMN is able to capture the semantics adequately, but BPMN tools simply do not adhere to the spec, and users don’t know how to create diagrams correctly. The tool vendors’ own sample diagrams violate the spec time after time, something I’ve blogged about repeatedly in the past, and — more important — the tools (the ones I’ve looked at, at least) do not adequately validate the diagrams against the rules defined in the spec.
In trying to prove his point that the semantics required for model portability are missing from BPMN diagrams, Keith unwittingly proves mine instead, that the problem is diagrams often violate the spec and the tools don’t seem to care. He says:
Lets say there was a product called “Vulcan Mind-Meld” which used BPMN to express the diagrams that have meaning to this product. BPMN defines what each of the symbols mean, but the real meaning, the real semantics comes from the way that the symbols are composed together. Mind-Meld would guide you as you draw this diagram, making sure that you do not put anything together in a way that is nonsensical. The author of this diagram is making an expression that has meaning in Mind-Meld. Here is a possible diagram which is consistent with the BPMN specification:
Now, imagine the Vulcans had followed BPMN best practices and applied user-meaningul labels to the various activities, sequence flows, gateways, and events, so it would be clearer the conditions under which the process followed one path versus another. (In BPMN modeling it is actually these labels, not the attributes — those are mostly for BPEL generation — that clarify the process semantics.) That would go a long way toward clarifying what those Vulcans had in their melded minds. To the extent it’s still unclear, it’s because this diagram, which even a guy as smart as Keith says is perfectly good BPMN, contains at least 3 errors.
1. You have 2 sequence flows coming into Casino from potentially concurrent paths. You need an OR-merge there, or else you potentially have 2 tokens going through the Casino activity for one process instance. Not absolutely forbidden by BPMN, but best practice to avoid this. It will break virtually any simulation engine or process engine, and probably not what the user had in mind.
2. Casino, having no sequence flow out, is what the spec calls an end activity. If start events are used in the diagram (they are here), an end activity must have a sequence flow to an end event.
3. Casino has a Compensation intermediate event with a sequence flow coming out of it. That’s invalid. A Compensation intermediate event has an association to a single compensation activity, not a sequence flow.
If I can spot these things easily, why didn’t Keith’s BPMN tool?
For the past few weeks I have been grading exercises submitted by students in my Process Modeling with BPMN training. My decision to include hands-on with a tool and exercises submitted for grading turned out to be a good one — students say the exercises really drive home how to use BPMN in a way that the lecture material simply can’t. And what I’ve learned from the grading is that students frequently make diagram errors that could, in principle, be caught by a BPMN validator. The tool I use, Process Modeler for Visio from itp commerce, has a modest amount of BPMN validation - just enough to make sure the simulation engine can follow the process — and a stricter validation (overly so I think) of diagrams with BPEL export, reflecting more the constraints of BPEL’s block orientation than anything about BPMN. But almost all the errors I find are allowed by the tool. If I can see them, surely a validation routine should be able to spot them as well. This would change the nature of my training, perhaps, but… that’s another subject.
Finally we get to the real reason for this post, which is the long-awaited BPDM — the official metamodel for BPMN from OMG. You can see it, if you want to, at modeldriven.org. I was looking for a schema, but instead it’s this funky XMI thing. It’s not even schema-valid XMI (that’s ironic, isn’t it?). It fails XMI import as published on modeldriven.org, but if you patch it up with the right root elements — thanks to Marlon Dumas for doing that — you can at least import it into a UML tool. Yes that’s right, UML. The schemas that Marlon was able to generate don’t shed much light on what the structure of a BPMN serialization would look like, and that bugged me last week.
But I think Keith’s post here crystalized the thing that is really bothering me. It’s not portability of models between tools. I suppose whether they have to use Eclipse or whatever, the tool vendors will figure out that piece. What I realize I was actually looking for in BPDM was a more precise statement of the rules of BPMN, so they could be reflected in tool-based validation. I had the feeling that those rules were somehow buried in the XMI, which I can’t decode, unlike schema, which I can. But on further consideration, I see that it’s highly unlikely that a schema could possibly represent all the rules, such as if you have this kind of flow object over here, that constrains what is allowed for this other flow object over there. Of course, if you had a schema you could write XSLT that would do the validation based on rules extracted from the narrative of the metamodel. But that’s a story for another day.
March 26th, 2007