There has been a flurry of discussion around compliance for BPMN specifications, particularly on Bruce Silver’s blog, and with additional commentary from Ismael’s blog.

Bruce makes some great points about why BPMN is catching on in the marketplace.  It is (relatively) intuitive, it represents most of the really important ideas that need to be expressed in the Business Processes, and I’ll add another thought:  you can actually draw it on the whiteboard pretty accurately.  Some people think that is silly, but I think it matters that you can sketch it out pretty faithfully on a whiteboard or piece of paper as well as in software.  A great many people still think most freely on whiteboard/paper rather than on a computer screen.

Bruce also makes a great point about BPMN to BPEL mappings:

“A key reason for that is it is graph-oriented like a flowchart, not block-oriented like a structured program, or more to the point, like BPEL.  For example, you can loop back to some previous step with a BPMN gateway, but BPEL places severe restrictions on that.  What that means is you can draw BPMN diagrams that cannot be mapped to BPEL, or at least to “roundtrippable” BPEL that preserves the BPMN view after even minimal tweaking in the BPEL environment.”

Personally, I don’t even want “roundtrippable” I want “native” - meaning, a representation specifically designed to store BPMN.  Whether it is “custom” XML or “standards-based” XML, I want it to be targeted so that roundtripping simply isn’t an issue - the diagram is the xml/data and the xml/data is the diagram.  Otherwise, how can the business ever be sure that they’re BPMN diagram is being accurately executed?  If the representation isn’t roundtrippable or native, then it undermines faith that the process works as designed.  One of the key problems with all the previous software systems I’ve used and built prior to BPM is the separation between requirements and the finished solution (or, put another way, between the business and IT delivery).

Ismael of Intalio gives this response in his blog:

“Do not worry about round-tripping between BPMN and BPEL
Round-tripping is a futile and wasteful exercise when attempted between two languages or notations that have a significant semantic gap between them, and so is the case for BPMN and any process execution language optimized for computers (like BPEL). The same is true between UML and Java by the way. Round-tripping should be set as a goal only between two languages or notations that are essentially representing the same thing, such as BPMN and its future serialization format for example. What this means is that there must exist a way to fully serialize BPMN diagrams on one hand, and a way to graphically display serialized BPMN on the other. And all this should work in a deterministic and predictable way, uniformly across tools.”

I find the assertion that round-tripping is irrelevant to be a bit startling.  The problem is, if the translation from BPMN to BPEL representation is wrong, we’ll have a hard time detecting that.  And then how would it help with compliance? I can’t take the BPEL representation and load it in another BPMN tool and see the model… so we haven’t achieved the interchange that Bruce Silver is looking for, nor proven compliance…

Personally, I’d start with the following:

1. can i MODEL the specification model (ie, can i draw it in this tooling with standard components).  By this definition of compliance, a visio stencil may do the trick…
2. can the target environment EXECUTE the model.  the compliance model can describe the expected behavior of the model especially illuminating areas that might be up for debate (presently) but which should be standard (near future) interpretation.  Execution should be separated from modeling - from a compliance perspective - because BPMN does not exist solely for execution purposes.

Next, additional models could be provided that describe “illegal” models. If you model these in a compliant environment, it should, in some fashion, warn you that the model is not correct (either by throwing an informative error when you run/test the model, or by showing validation errors at design time).

Granted, testing compliance gets easier once BPMN 2 style storage spec gets released, but til then, there’s no reason we can’t have a representative model - it will just be harder to confirm compliance because we’ll have to actually do the work to model something.

Bruce points out that without the data storage spec, he’s not satisfied with the results - and I can’t blame him - but I think defining what would be a representative model to exercise the specification for a given tool is something that has to be done regardless of the storage medium.  And in the meantime, even the visual representation of such a model could help customers and consultants evaluate BPMN tooling appropriately for compliance.  Currently there’s just too much distance between here and there if we have to have a portable data schema before we can have a model (or set of models) that exhibits all the features of compliance.

Recently there has been quite an interesting discussion around Pi Calculus vs. Petri-Nets, and between BPEL and other implementations of BPMN.  The real discussion thread (consolidated place to read) is here.  The start of this discussion appears to be Ismael’s post on BPEL/Pi-Calculus vs. BPMN engines that use Petri-Nets.  This is pretty esoteric stuff to the average person, but it has sparked quite the debate.

You can find Ismael’s original post here.

If you’re technical, and you’re curious about what’s going on inside the black box BPMS you’re using, this is a great debate to read through.  The basic point made by Arthur and others is that BPEL is an implementation detail, and that BPMN is the most important standard because it represents the process, and as we all should know, representation affects how we think about process.  Arthur’s basic point is not that BPEL is deficient, but merely that it is like arguing about whether we should compile to Java bytecode or C-sharp byte code.  Or native machine code… do we really care as long as the code runs well on our target platform? :)

The victim in the debate is often “petri-nets” as compared to “pi-calculus”. Ismael makes the argument that BPEL is superior to the other approaches out there, partly because it is standards-based, and partly because it employs pi-calculus and that that is superior to petri nets for parallel processes. A great debate over whether BPEL really implements pi-calculus ensues, missing that the key point Arthur was making is that either a pi-calculus model or a petri-net model could represent parallel processing of BPMN models well. My personal experience reflects this as well, as I’ve participated in projects that leveraged both technologies and they both work… moreover, they don’t appear to be entirely mutually exclusive.

Lost in all of this debate is the B in BPMN:  The Business.  The Business doesn’t care as much about the specific technical differences of these approaches under the hood, so long as they execute the process faithfully.  Personally I just want to use the best tool for the job.  I’m going to “write” processes in BPMN.  I’m going to execute them and deal with differences in interpretation of the spec when BPMN is married up to execution engines, regardless of whether they are BPEL or other technologies (and the fact that it goes to BPEL doesn’t get me away from interpretation issues, because the issue is how is BPMN “interpreted” into BPEL just as much as it is an issue of interpreting BPMN into some other exeuction form).