It's been a while since we were graced with a blog post from John Reynolds, but as always, his latest post was both thoughtful and thought provoking. In his post, John maintains that:
"Directly executing BPMN makes no more nor less sense than directly executing insert your favorite programming language here."
To a point I have to agree.
As with any completed software project, performance implications notwithstanding, it makes very little difference what language a program is written in since it will usually be compiled into an executable form. I have memories of being involved in a project that (successfully) combined Java, Groovy and Scala into one source tree.
John makes this point quite well:
The norm in Software Engineering is to write applications in the programming language that most closely maps to the problem domain, and then compile the results to the common primitives (assembly language/machine code). This allows authors to use a wide range of programming languages - yet execute all of the resulting programs on the same "engine".
However, BPMN projects are a little different than typical software development projects, at least here at BP3.
One of the major value propositions of a process implementation is the discovery process. Often (read almost always) customers have differing views of the same process and a huge amount of value is taken from simply documenting the process.
"True," I hear you say, "but so what?"
Well, the value of being able to instantly model, update and execute a process during discovery offers tremendous value. This is not something you can really do if you go through a compile phase. Anyone who has modeled with the old Websphere Process Server can attest to this.
There is also the problem of "fidelity".
I have personally had issues in the past with an unnamed tool that modeled processes in BPMN but then translated this model to XPDL for execution. As it turned out, the translation wasn't perfect and what was executed was not in fact the same as the original model. I have heard stories of similar issue when converting BPMN to BPEL.
And what about "round-tripping".
If you "run what you brung", there is no need for round tripping, but what happens if a change is made directly to the resulting process definition? How do you get this back into the original model definition in BPMN? The tool may provide a translation (though this is not common), but we are again faced with the fidelity issue.
In short, the value of "run what you brung" goes far beyond the technical model definition, it significantly simplifies the discovery and implementation process, it prevents problems of loss of fidelity and simplifies governance.