Go Flow

I attended the keynote by Dennis Wisnosky, CTO of Dept Of Defense, today at the Architecture & Process conference. He is currently on a campaign to get vendors to make truly interoperable implementations of BPM technology. He has been testing implementations of BPMN, and found disparity.

A notation is…

He feels that the most important thing is a standard notation for business processes. What do you get with a standard notation? You can have a document that displays something, and everyone should be able to read it, and agree on what it means. He gave two examples of notations.

First, he showed an electronics schematic. He pointed out the resistor symbol, the capacitor symbol, and the ground symbol, included in a simple filter circuit. You go to any electrical engineer, in any country of the world, and they can read this diagram. It is a standard notation that works.

Second, he showed musical notation. Again, this is a world-wide standard which consists of notes on the staff, as well as a collection of other notation. Again, you can take a piece of music to any musician in the world, and have agreement on what the notation means. It is clear what notes are to be played, when they should be played, and for how long.

He is absolutely right. You should be able to take a BPMN digram from any product, and show it to a person who is trained in BPMN, and there should be an unambiguous interpretation of what the diagram means. That is the goal of BPMN.

But a notation is not…

The analogy with music is a very good one, because it exposes some other properties of a notation that people find non-intuitive. For example, you can write a jumble of notes on a staff, but that does not mean that any given instrument can play it. A tuba player can read the piccolo part, and agree what the notes mean, but that does not mean that the part can be played on a tuba.

A standard notation does not imply that all legal notation can be played. Each instrument has allowable parameters around what you can and can not play, limited certainly by range, but also other factors: a piano can play chords while a wind instrument can not. (Please, no smart comments about bag pipes, OK?) A composer does not write a piece of music as an “abstract” composition of notes. A composer considers each instrument, and writes music that that instrument can play. This is expressed as standard notation, which anyone can read, but there is a lot more composition than simply creating the notation.

It is really important to keep this in mind for BPMN. When a process analyst creates a process diagram, that analyst must keep in mind the capabilities of the process engine that will be executing the process. The process should be designed specifically to run on that engine. But then the process can be expressed in a standard notation that we all can read and agree on the meaning of.

Conversely, this means that when an engine imports an XPDL file containing a BPMN diagram, the BPMN and XPDL standards do not, by themselves, guarantee that the engine will be able to execute it. The best we can hope for is that the engine tells you when there is something “out of its range” and can not perform.

Don’t confuse notation with universal language…

Imagine a universal instrument that could play any combination of notes for any duration, but there are other considerations beyond simply being able to throw any notation at an instrument. A trumpet and an oboe may play the same notes, but they are qualitatively different instruments in a way that transcends the notation. The notation communicates certain important things, but it is not the full embodiment of the music.

Some people jump to the conclusion that all process engines should have a “complete” implementation of BPMN — whatever that means. Having all process engines with exactly the same capability would mean stopping all innovation on support for business process, and limiting all engines to a least-common-denominator approach. It has been my experience that each engine offers new and unique difference that are good for supporting particular kinds of processes. Stifling innovation for the sake of universality is a short sighted goal. The fact that the engines are different is not a bad thing. Yet we still can expect, and must demand, that the notation be consistent.

Dennis Wisnosky represents a very large and powerful customer of process technology, with influence across the industry. Watch what he does, because I think he is in a position to have a profound effect on the BPM marketplace this coming year — and he is on the right track.

I just want to highlight an excellent post by William Vambenepe on the subject of BPMN to BPEL: going to battle with one hand tied? He does a very simple experiment: draw a meaningful diagram in BPMN, in this case a fairly simple one involving an Inclusive-OR branch, and then attempt to convert this to BPEL. He does this conversion and presents the results is quite obviously a diagram that fails in fact to capture the exact meaning. He says he has no solution to this problem.

William, I have your answer, but it is kind of cheating: “WYDIWYE” The solution is to NOT convert to BPEL at all. Why can’t the engine take the BPMN diagram directly? Why does it have to be converted at all?

Think about it: if you can draw a diagram that is unambiguous and the rules are clear, why not simply transfer that entire diagram to the engine, and let the engine execute it exactly? A conversion always involves loss of information, or at best, retaining the same information, and the problems of “round-tripping” conversions are widely discussed. What would be the advantage in converting the diagram to BPEL?

Internally, the engine can convert to anything it wants. If it is internally a BPEL engine, then it can convert to its own brand of BPEL. If it is Ruby based, it can convert to Ruby. As users, why should we care what it converts to for execution?

There are a number of engines that interpret the diagram directly without needing translation. WYDIWYE: What You Draw Is What You Execute. This is exactly what Interstage BPM does, but Fujitsu is not the only BPM vendor out there that does this. (Others can chime in, please.) I often get asked: “do you convert this diagram to BPEL?” My response is “Why should we want to do that?” We send the entire diagram, unconverted, to the engine, where it is executed directly. There is no benefit I can see to stripping the process down to the executable part for giving it to an engine.

There are several clear advantages of WYDIWYE:

• The additional non-executable information (graphics, etc) as useful in order to display the running process to a user.
• If you offer on-the-fly modification, then you have the entire process to start modifying. Not possible if you have only a BPEL extraction.
• If it fails to execute the BPMN diagram that I drew, then the engine can explain to me on that diagram what is wrong. It is difficult to communicate problems back to the user if the form is changed from the original.
• You can always convert it later to BPEL if you wish, given that you have the complete diagram.

Seriously: what do you gain by converting to BPEL before giving it to the engine? BPEL strips out non-executable aspects of the BPMN diagram. Even those that claim all is preserved do not deny that often the form is changed to be unrecognizable. Also, consider that the Diagram is the Meaning in many cases.

WYDIWYE: What You Draw Is What You Execute. Why does the diagram have to be stripped down to the executable part before giving it to the engine?