I am watching a number of comments being placed about a new effort for BPMN 2.0. Vishal Saxena says that the BPMN 2.0 metamodel should maintain this flexibility that BPMN 1.0/1.1 has. No argument there. Sebastian Stein says that BPMN is missing an exchange format, and clearly he does not know about XPDL. He goes on to say that the real problem is a lack of clear execution semantics. He points out that the OMG discusses two approaches: BPMN defines the semantics, and BPDM defines the semantics. Bruce Silver comments that the first approach would be the most value to the BPM community. We seem to agree that BPMN needs more clarity in expression. I suggest that there is a third approach that the OMG should consider.
My concern is that the BPMN committee is heading down a blind alley: One part design-by-committee, and two parts not-invented-here. It might be expressed as something like this: “Products can’t completely agree on the semantics of the drawings, so let’s just make up some new semantics, and everyone can just use that.” As if the problem was that products simply can’t define precisely what they mean, so the standards committee needs to define it for them.
The issue is NOT that existing products have undefined semantics! There are many products on the market, every one with precisely defined semantics of what they want to, and need to, express. The fact that products have inconsistent implementations of BPMN is not because they don’t know what to say. Instead it is because BPMN is not good enough at expressing precisely what that product needs to say.
Let me give you a concise example. In BPMN you can define an activity to have multiple outgoing arrows. Does this mean that all, some, or one arrow will be activated when the activity is completed? There are three cases to consider:
If you leave the tails of the arrows unembellished, it indicates AND split semantics and all arrows will be taken. If you put diamonds on the tails of the arrow, it means Inclusive Or semantics: one or both of the arrows will be taken dependent upon conditions within the diagram logic. The other normal case would be “Exclusive-OR Split” semantics, which means exactly one of the arrows will be taken. There is NO WAY to indicate in BPMN that the outbound arrows from an activity have exclusive-OR split semantics. It is simply missing from the standard.
This is surprising because so many products out there have traditionally made use of exclusive-OR. Traditional “flow chart” modeling uses exclusive-OR predominantly. Of course, there are other ways to draw it: I can make a single arrow go to a gateway, and there is an exclusive-OR gateway, so it is a logically equivalent way to draw it, but it is different drawing, and significantly more cluttered one at that. Not every product needs exclusive-or in this case, but some do, and we all would benefit if there was a standard way to express this.
Products are inventing extensions to BPMN because BPMN does not have the power to express precisely what they need to express. BPMN is the best standard notation we have, but it is not finished, and there are still many limitations. Now that we know there is a “meaning” to be expressed, and no way to express it, the BPMN committee should focus on extending BPMN with a way to express this. Don’t waste time developing a visionary model of a new non-existent product. Instead, the committee should be looking at existing products, and observing how they have used BPMN inconsistently, in order to figure out what gaps exist in BPMN today. Then come up with a clear expression so that when we see the diagram, we know what it means.
Many of the successful products today are based on years of research and customer trials which have directed the products to become very very effective at some particular segment of the market. How naive it is to believe that the difference between products are accidental and inconsequential differences. How arrogant it is to think that any group of experts can simply invent a new approach which is universally better than one that has already been proven successful. But this may be precisely what the committee tries to do.
The purpose of a notation is to clearly and unambiguously express something about the world as it is. It is NOT the purpose of a notation to redefine the world as we would like it to be, regardless of how attractive that idea might be.
If we think for a moment about the “musical notation” analogy (my previous entry) it would be a bit like the committee saying: “now that we have defined the musical notation, let us define instruments that can play such notes. We have a staff that goes from E to G, so I need an instrument that goes exactly from E to G”. The reason this is so laughable is that the sound of a musical instrument is infinitely richer than what is expressed in the notation. Reading the score of Beethoven’s 9th would be meaningless without having a familiarity with the different sounds of the instruments that are playing the various parts. The notation does not define the sound that is made, but it does express exactly what the musician needs to know in order to play along.
The best way to arrive at a more precise definition of the execution semantics of BPMN, is to look at existing successful products today, that already have precisely defined semantics. Examine how well these products are able to use BPMN, and particularly at how BPMN falls short of being able to precisely express what such a product needs. Then extend BPMN so that each product can clearly, and unambiguously, express what it needs to say. In this way, the BPMN standard would gain from all the best ideas which have been developed over the past 20 years.
Thinking Matters 
Hi Keith,
I’m pretty aware of XPDL and I’m also pretty aware of that you are a strong proponent of XPDL. The use of XPDL as interchange format was also pointed out by another blogger as a reaction to my original post. I will post an answer to that next week in the ARIS BPM Blog.
Hi Keith,
I read your post again and I think you got something completely wrong about the posts you cite. You are saying someone should not add external semantics to BPMN, but make the semantics explicit. You are right here and if you re-read the posts by Vishal, Bruce and me you will notice that we completely agree and that we are not in favor of adding BPDM as the meta model. Instead, we just want to explicitly define the semantics already used today by many BPMN users.
Yes, I realized that none of you were in favor of adding BPDM to BPMN (myself as well). Also, we all want better definition of the semantics of BPMN. My point is BPMN should not define such semantics abstractly and independently from actual products. Instead, well defined semantics can be found by looking at actual successful products, and identifying gaps in the ability to express product semantics. After re-reading the post, I realize that the wording I chose implies something that I did not mean, so I may try to make a small edit to address that.
Keith,
You make an interesting point. In my training I fret about the fact that BPMN allows multiple ways to draw the same semantics, e.g. AND-split vs uncontrolled flow out of activity; OR-split vs conditional sequence flow; etc. And I recommend that students try to standardize on one pattern per semantic and use it consistently. So your suggestion re some extension of conditional sequence flow to suggest XOR seems to be adding fuel to the fire. But I have also found in my training that, as you say, many students are conditioned to drawing XOR behavior without a gateway, and if BPMN added this it would make the notation simpler for some to grasp. I think this is a good suggestion, and one the BPMN TC should consider. But I disagree that its absence today signifies something wrong with OMG’s approach.
[…] Besides this problem of undefined execution semantics, another major problem is the missing file format to exchange BPMN models between different tools. People like Keith Swenson wonder, why XPDL is not used for this purpose? […]
Keith,
The purpose of incorporating the BPDM metamodel is NOT to change the semantics of the BPMN notation, but rather to provide precise and consistent specifications.
The BPDM metamodel defines a factoring of modeling concepts into basic concepts that are brought together to define the composite semantics of the concrete modeling elements (i.e., BPMN). This ensures that the basic concepts are defined in the same way when they occur in different concrete elements. For example, some of the same concepts occur in the process/orchestration elements as in the choreograpy elements although those concrete elements differ.
The metamodel also establishes these basic concepts for use in other business models, where they apply, so we can achieve consistency across these different models. This is important because we expect that these separate models should express the same business concepts in the same way (e.g., a person in a process is the same as a person in an organization), and that the separate models will eventually become integrated.
Since there are different interpretations and uses of the BPMN graphics in different products, it is necessary that the resulting semantics will not represent the semantics implied in every product that implements BPMN today. In addition, as you analyze the semantics using the basic concepts, you discover inconsistencies and limitations of the current BPMN semantics, particularly when dealing with the relationship to choreography.
The resolution of these differences is why we have open standards processes. It is not for the submitters to discover what each vendor is doing, but for each vendor to represent its product in the process.
The BPDM metamodel, except for its impact on integrity of model exchange and semantic precision and consistency, should not be of concern to the BPMN user. It is, of course, a concern for BPMN product vendors.