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.

Compatibility of the services is not so obvious in the first place. The question to be answered is, if for all possible sent messages the other participant (or service) is ready to process it, and if both can complete their control flow in all cases. For example if one participants sends an order cancellation, but the other participant cannot process it, because the order is already delivered, and it has no control flow to deal with the late cancellation, then the services are not compatible.

Typically this can be checked by comparing all possible states of all participants and all messages. However this brute force method consumes much memory and computing time. Probably this is one reason, why it is not yet offered in so many or even a modeling product at all – which I do not exactly know. The proposed method in (An efficient necessary condition for compatibility, 2009) is to use a method known from petri nets: to convert them into matrices (state equation) and use the matrices to determine the compatibility in a much more efficient way. This is definitely interesting to consider.

The paper states, that this can be used for service discovery and mediator construction. In my personal opinion these use cases are very advanced research use cases, which are not yet so relevant in the practical industry application. Even the mediator construction I have severe doubts, if this is a way that will lead to somewhere at all. But I might be convinced later.

But very relevant is to support the design process of services which need to interact. If there were a repository, that would contain such compatibility determination method – that would be a great step forward. Furthermore it would provide the industry use cases that are needed for further research on the matter.

References

An efficient necessary condition for compatibility. Oanea, Olivia und Wolf, Karsten. 2009. [Hrsg.] Oliver Kopp und Niels Lohmann. Stuttgart : Universität Stuttgart, Fakultät Informatik, Elektrotechnik und Informationstechnik, 2009. Services und ihre Komposition, Erster zentraleuropäischer Workshop, ZEUS 2009. Bd. CEUR Workshop Proceedings Vol. 438, S. 81-87. http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-438/paper13.pdf.

Problems, that occur in the area of message exchange often have their reason in the designed Business Processes or – lack of design of them.

For example, there might be a Purchase Order Request message and a Purchase Order Confirmation Message. Then after a while the buyer sends a Purchase Order cancellation. But at the same time the seller has sent the message, that the Purchase Order now has been delivered. Therefore there might be a problem.

However in my opinion the business process is not designed flexible enough. For example the Business Process should also be designed for cancellation rejection. For example if the Purchase Order has already been delivered. So if the Business Process is designed flexibly enough, then the problems, that can occur in message exchange also are able of being resolved.

Therefore designing public processes gives flexibility within Participants to change processes as necessary – often without or with reduced side effects to the interation to the other Participant. This reduces cost in Process adaptations.

Integration of Software Systems is the realization of the underlying Business Processes. Realizing As-Is Processes often leads to suboptimal results. No doubt – As-Is processes Analysis needs to be done. But Process Design is ImhO the decisive part.

It must be absolutely clear, which parts of a process are tightly coupled and which parts are loosely coupled. Tightly coupled means for example: A Customer Order can not be created unless the price determination is done. Loosely coupled means: A Customer Order can be created independent from the creation of the Delivery. The delivery creation is a loosely coupled followon process.

However, of course there are interaction between loosely coupled process parts. These need to be defined – i.e. designed. BPMN 2.0 gives the possibility to model them in a way never possible before.

In BPMN 2.0 tightly coupled process parts are those within a pool. Loosely coupled process parts are those that are modeled cross pools in Collaborations or in Choreographies.

The cut of the process – thightly or loosely coupled – is decisive for success. It is not only a system modeling or implementation question. It is also a business process question. Or why do companies outsource parts of their operations? Because they want to loosely couple, what was tightly coupled earlier. This principle makes sense within companies as well, because of enhanced flexibility.

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.

This is a first Choreograpy model. It consists of two Choreography Tasks.

The first Choreography Task is  Request Booking as an interaction between two participants – the Runway Show Management and the Venue Provider. We know from the coloring that the Runway Show Management is the initiator of this interaction. We also know, that at least one message must be exchanged between the participants in the course of the interaction, maybe more.

The second Choreography Task is Confirm Booking. Here the same participants are interacting as before. So we see, that the participants are part of the Choreography model and can be referenced by different Choreography Tasks. However in the second Choreography Task the Venue provider is the initiator of the interation.

We know from the sequence flows between the Choreography Tasks, that the Confirm Booking Task follows after the Request Booking Task.

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.

My answer would be, that the Pi Calculus is a Low Level desription calculus for processes that communicate with each other, messages and message channels. This serves the simulation and analysis. The choreography model and the collaboration model are more like a notation with metamodel covering the processes and the messages, but not the message channels. It is more for modeling than for analysis, although the model can be input to the analysis and the simulation.
Also every BPMN choreography model or collaboration model can be mapped to a Pi Calculus description, but not vice versa. Pi calculus is more general and has no notation. BPMN is guiding the modeling process and therefore easier to understand.

When one want to use the BPMN choreography model or collaboration model as input to a pi calculus conversion or a simulation and analysis, the quality of service contract needs to be specified before.

http://www.bpmnforum.net/blog/bpmn/bpmn-in-research/quality-of-service-contracts/
[ad]

Bibliography

1. Beugnard, Antoine, et al. Making Components Contract Aware. Computer. 1999, Vol. 32, 7, pp. 38 – 45. http://portal.acm.org/citation.cfm?id=621275.
2. Lecture Notes in Computer Science: Non-desynchronizable Service Choreographies. Decker, Gero and Alistair Barros, Frank Michael Kraft and Niels Lohmann. Berlin / Heidelberg : Springer, 2008. Service-Oriented Computing – ICSOC 2008. Vol. 5364/2008, pp. 331-346. http://www.springerlink.com/content/9055736715131767/. ISSN 0302-9743 (Print) 1611-3349 (Online).