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.