I want to shortly explain the context of my approach to Business Process and Choreography Modeling Coaching. My guiding philosophy is a full cycle coaching approach. That means, that not only the creation of choreography models is the goal, but the role of them within the context of the preceding and succeeding steps. I intend to explain this in more detail in Webinars and Seminars in the future.

Model Business Process

First of all the Business Process itself is modeled. The focus of this activity is to identify the steps that need to be performed to reach the goal and their dependency. This is done irrespective of the participants, which are not completely clear at this point in time.

Break into Participants

This is a design decision. Often Participants are companies of the business world. Still it is a design decision how fine or coarse granular they are designed and which part of the process is executed in which participant. For example it is possible to define different departments within a company as one or many participants.

Model Choreography

Now the interaction between participants can be modeled by means of the choreography model. This is a top-down approach. Therefore it defines the frame of subsequent detailed process modeling within the participants.

Model Public Processes / Services of Participants

As a next step the public processes and services of the participants can be modeled. It is decisive to model which services which participant exposes and which constraints exist between the service operations (e.g. an order needs to be confirmed, before it can be delivered).

If a complete system is designed from scratch, the public process models and the services are designed as To-Be processes and services. But in most instances the participants will at least in part already exist. Therefore As-Is models will be created and must be aligned with the To-Be model. This is the most challenging part of all. Because if the public process of a participant cannot be freely designed, because the cost to change it is too high, then the choreography must be changed, which in turn means, that the other participant may need to change. This is the most challenging negotiation in the design process.

Derive Business Objects

Before an implementation can start, Business Objects, which implement the behavior of the participants, need to be derived. The behavior of the Business Objects needs to be made consistent with the public behavior of the participant.

In the end the public behavior of the participant will be an abstract process, while the business objects will be concrete. This will also be very clear, when it is time to model correlation rules – i.e. which message instance is processed by which process instance. At this point in time, the most natural process instance will be the business object instance. Remember: The public process is only an abstract process – therefore it does not have instances.

Model Common Monitoring Process

Now the details have been modeled and we want to re-aggregate the execution of the processes into a common process view on instance level. The Monitoring Process View is needed as a re-simplification of the already modeled details. In the optimal case the monitoring process is equal to the original process model which stood at the beginning. Most probably there will be deviations for good reasons. This of course is also a good exercise to re-confirm the original requirements and justify the deviations from it.

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.

Some words about the BPMN 2.0 process as I personally percieved it.

I found the collaboration between the companies very productive. Often some have a hidden agenda or have prejudices. In this case I can testify, that I personally did not perceive such a thing.

Of yourse every company has it’s worldview. I found IBM had the strength in workflow technology and metamodeling. I found, that Oracle had an especially deep knowledge in message exchange. And SAP had extensibe experience in business processes and their modeling.

There were strong contrary positions, due to the fact, that there were two different consortiums that prepared a submission.

• Adaptive, Axway Software, Hewlett-Packard, Lombardi Software, MEGA International, Troux, Unisys.
• IBM, Oracle, SAP AG, and Unisys.

There was a collaboration of project management level and the assessment of a common submission. On the concept level there was the discussion of BPDM (Business Process Definition Metamodel) should be the unterlying meta model or not, a 2007 OMG standard for a general exchange format for processes.For IBM, Oracle, SAP a native BPMN metamodel with possible mapping to BPDM was the course we chose.

But there was a very productive part in this controversy. Because members of the other submission team joined also our discussion, our discussion was much enriched. Especially the contributions of the NIST (National Institute of Standards and Technology of the US) revealed many special cases that can happen during message exchange, that were not previously in the discussion. I found that especially inspiring, because I had encountered many of these special cases previously in my architecture projects. That was about the same time that I joined the discussion in more detail. However within the BPDM approach I found some pre-determinations that I definitely could not follow. For example I could not agree, that temporal relations (i.e. that message has to be earlier/later than that messate) should be the main way to describe relations, because in my opinion mere temporal relations do not sufficiently describe cause/effect relationship or constraints between exchanged messages. However there was a significant openness in the discussion that allowed us to find compromises that could achieve very good advances to adress use cases. I personally had significant objections to the choreography modeling. However they could also be resolved – not so elegantly as I had wished – but resolved.

However this was a very interesting discussion, that was not fully completed within the scope of BPMN 2.0 and that I hope I can follow up in the near future.

In the next blog post I will go into details of the my view on BPMN 2.0 and the new modeling possibilities that it offers.