This is my BPMN 2.0 Overview Map.

It shows a Choreography model in the middle, Orchestration with public Processes and private Processes, that belong to the public Processes.

Systems integration is the realization of the underlying business processes. This sounds so simple. But in reality there is often a misalignment between the business process design and the systems design. It is the wrong way to just implement business processes, that are as they are today or that are designed without discretion of the principles of loose coupling.

Often system designers need knowledge about how business processes work, but on the other hand business process designers need knowledge about how system integration works. As long as both sides are willing to learn and willing to share the knowledge, it is possible to come up with common principles of modeling, that avoid the most common mistakes, that lead to project cost overrun or failure.  I say it clearly what I mean: using BPMN 2.0 choreography modeling language in itself is no gurantee for success. But: It is a VERY useful tool for the communication between the business and system experts, which is a necessary condition of success.

So in other words, it is necessary, that the process design follows the principles of loose coupling of business processes. That is no design task, that can be solved by system designers alone, if the business process is modeled in a tightly coupled way. In other words: If the business process is designed in the right way – in the loosely coupled way – then the system design is without a hitch. If the business process is designed in the wrong way – there is no way to save the project on the system design level.

So are business experts forced to design business processes different, just to make the job of system designers easier? No. If it is designed that way, it is a better business process. It would work even better even if there was no system, but just paper and phone. It is more tolerant to errors. It gives the individual more freedom to decide. It makes it easier to reach the goal. Yes, it requires a little bit more brain power than just modeling the sunny day case. But in the end it pays off abundantly.

And in my eyes this is good news. It is NOT the system programming that dominates the design and dictates the constraints. It can be the business process needs again, that prescribe the way to go. And that is why BPMN 2.0 is so helpful, because it starts with the business process model.

If you are german speaking, you might like this short video explaning the new possibilities of BPMN 2.0.

Neue Möglichkeiten mit BPMN 2.0 from AdaPro GmbH on Vimeo.

Models must have a meaning within a context in the end, otherwise they are useless. For example what does a model mean, where there are acitivies like “go to the shop” and “buy some milk” and “pay”? It is a modeled description of what a person sometimes does, if he needs milk. But nothing else. The process model is to be used as documentation only. This is the context of the model. Such a model can not be used as a workflow. There is no need to create a workitem “pay” for buying milk. This is done by the shop’s design anyway. Also it can not be a web service orchestration description, because there is no web service “go to the shop”.

Modeling a process makes sense, if the context is know, in which the process will be embedded. The context is what I call an architecture. An architecture is a set of rules that determine under which boundary conditions a software system is to be designed. As part of such a design the design of a process makes sense. For example the architecture could be to design a system that is capable of performing the functionality of a milk web shop, that milk order and milk delivery are business objects that expose web services like “order” and “pay”, that there will be a workflow system that is able to compose these services – for example. The architecture are the rules that describe the creation of the system, the business objects, the web services and the workflow. These first need to be professionally defined and confirmed. They need to be obligatory for the whole project.

Only after that it makes sense to create models, which then will have a meaning within the context of the defined architecture. And therefore it is of very limited merit to “just model” or to train or coach modeling of a modeling language without a reference to a defined architecture or without the preceding process of professionally defining the reference architecture before. On the contrary – if the architecture is defined, then it perfectly makes sense to coach and govern a modeling process, because then there are the rules, that are needed for coaching and governance.

This is my opinion.

In my personal opinion the use of preconditions is a good thing in general. However in my opinion the splitting up of the whole behavior into different scenarios has also disadvantages. For example that it is not so clear, if one scenario is changed, which side effects this has on other scenarios. Also one transition for example can occur in different scenarios. Thereby probably many scenarios need to be changed, if the behavior of one transition needs to be changed. Also a problem is, that it is not so clear how to model differen alternative behaviors. If the union set of all scenarios describes the behavior of the service, it is all one. So for example if there is one big service, but the behavior can be different – for example in one case with confirmation, in another without confirmation – this is not possible to be modeled. It is just a “confirmation” scenario in the set, but it is not modeled, that is sometimes must be used, sometimes not.

Good is that in the end of the paper it is proposed to integrate the scenarios into one view. This I agree upon. My personal opinion is, that I would rather start with the integrated view. Because all the mentioned disadvantages are not there in this case.

But I admit, that the use case proposed in the paper may still be valid in a consulting experince, where the client already has described the behavior of his services in the form of scenarios. Then, the method proposed is a good way to unify them into the desired integrated view. This may also be supported by tools, which gives an additional value add.

Also notbody should be distracted by the notion of the modeling language. This is just the underlying logic. The same method can as well be transferred to industrial languages, as is proposed in the paper and as I believe. For example I see no reason why this should not be useable in a BPMN 2.0 orchestration model environment.

In our time of electronic message exchange over the internet between participants of a business process one question becomes more and more pressing: “How do I design a business process orchestration?”
This is the right question. The not so good question would be: “How do I design message exchange?”. Designing message exchange in itself is nothing wrong. And most probably this is the first question that is asked at the beginning. And it needs to be asked at the end as well. But at the core of it is the question, how the business process shall be orchestrated. The reason is, because the degree of freedom one has to orchestrate messages is predetermined by the business process orchestration.
It is a major difference, if there are two given systems that implement given business processes and they shall be connected by designing messages versus having the freedom to design the business process in itself to be loosely coupled to another business process that can as well be designed.
One approach to designing business process orchestration is modeling it top down. This possibility is offered with BPMN 2.0. This is done in at least two steps.
The first step is to step back for a moment and take the view of a global observer on the business process. This it what it means to design a choreography model, or in BPMN 2.0 terminology a Choreography.
A Choreography describes the sequence of interactions between participants as it is observed by a global observer. The global observer has an overview over all participants and interactions at the same time. However the observer does not influence the interactions. The message sequence is completely enforced by the participants. A Choreography task represents an interaction between two or more participants in the scope of the model.
So even if there is no global process implementation in the end, it makes sense to design a process top-down bay taking a birds-eye view.
In a second step this process needs to be broken down into the processes that are relevant for each participant – i.e. that each of the participants need to respectively can implement.
The compelling benefit of the method is the simplicity of the first design as is can be done by using the Choreography. Also it makes it easier to design the processes of the participants with reference to an already predefined design – the Choreography.