Compliance for the BPMN Specification… Shooting the Moon?
- October 28, 2008
- 0 Comments
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.