Why you may want a Mapping in your BPMN roundtrip
With the BPMN 2.0 getting more and more attention I recognize one trend in perception: BPMN allows you to have the same model for business and technical people. The idea of the roundtrip seems to be replaced by a “one for all” model. Actually I don’t really believe in one model! Or put it another way: we need a better definition of what “one model” exactly means. In this blog entry I want to give more insight in my line of thinking on this.
The important goal we should target is, that business and technical model can be kept consistent and in sync. The first is obvious I hope and the second turns out to be really important if you want to keep your BPM efforts alive and the business models up to date. Jakob pointed to correct usage of BPMN pools in his blog entry “BPMN – just DO it!”, this is already the first important step from our experience in the last customer projects we did. This allows you to model “the process of different roles”, e.g. the account manager responsible to talk to the customer for incidents, not knowing what the second level support is doing exactly (please have a look at this process model if you have no clue about what I am talking).
This results in having an own Pool for the Process Engine. And this can be directly automated, right? In principal: Yes! And this is the good news
But I have some remarks on this. First: You normally don’t want your developers “messing around” in the business process model in your repository directly. Hint: Obviously this is the description from the business perspective. “Messing around” really means: Making the hard work to make a process really executable :-). And the developers need additional tooling for development, as I already described in my last post. So the best approach we tried in our projects is to copy the Process Engine pool into an own repository, typically SVN or the like. So we copied one pool of the process model and have a development version of it. Now tell me: Is that one single model or are these two models? Typically I get different answers to that question from different people! I would argue: It is just another version of the same model!
In the developers wording this is just some kind of branching. There is one challenge which comes with branching, which is merging! Think about a developer now changing the model, e.g. a new service task must be introduced to query informations required to do an automated decision. Something business modeling often forgets. This changes must be merged back to the business model at one point in time. To be honest: This is tricky part, especially because showing differences on a graphical level is a hard requirement for tools! Let’s hope some may come up with a solution on that level, we addressed it already to some of them. So long merging in our pilot projects will basically mean: Overwriting the Engine Pool in the BPMN model.
But there is one low hanging fruit I want to point out with the whole approach of copying the model: On this step we can add additional functionality easily, I call it “enrichment” as you can see in a realistic example on the left In camunda fox we added the possibility to hook in mapping or enrichment steps at this phase, meaning we are really flexible. Let me give you some examples of what we can do here:
- In the business model a Service call may just be the name of the service in the Service Repository. In the executable model we need complete technical details that it may be a WebService call or “just” an EJB.
- Blanko intermediate events in the business model mark “business milestones” with a simple name. They are monitored. In the technical model, this must be enriched to be able to send an event to the monitoring software.
- We did some easy translation, since the process model of our projects is typically German for the business department, but the development is English speaking and maybe outsourced.
- At the moment we even do a Mapping to JBoss jBPM 3 process models, since BPMN 2.0 execution is not yet stable.
The enrichment can be even exchanged later on, if your software infrastructure changes. One use case we had in the past was for example a company switching from a too limited UDDI repository to a much more powerful own one, supporting EJB and JMS as well. But this is basically a generic advantage of model driven approaches.
This are just a few examples. Now, is that still one model? Is that correct BPMN 2.0 if some technical details are “just” added in the enrichment phase? Actually I think yes, since there is one really good argument: In reality, it works pretty good! And I don’t mind if you call it “one model” or “roundtrip”, as long as you get a development approach in place, which works for your company! Don’t stick too hard to the believe, that one model means one file, and don’t get scared if you hear the word Roundtrip, actually that seams to work pretty well if you have “compatible” languages on both sides, e.g. BPMN and BPMN. It was just broken with BPEL