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.

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.

It is inevitable in big organizations, that there are central processes that are supported by every part of the organization. But at the same time it is desirable, to support individual processes, that respect local specialties. In this case the local units must be given the possibility to plug into the global processes. This can only be done, if the behavior of the local and the central processes is known – and by this the interaction – the choreography between them – can be defined and described. Therefore it is important to have behavior modeling languages for processes of units and of the choreography. Furthermore sometimes it is necessary to allow a local unit to describe their own processes or aspects of their own processes in their own language – a DSL – and plug them into the central processes.

If this is achieved it is a controlled powerful local flexibility with the integration into centrally controlled processes.

All of these articles and also BPMN 2.0 can help to strife towards this goal.

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.

So the paper proposes, that for the purposes of service validation, (automatic) service construction, service composition and service replacement there is not yet a represenations, that allows for a closed theory – i.e. a structured solution in all cases. Actually it is an opening paper that will be later completed by describing “operating guidelines”, which are intended to fulfil this purpose.

My personal opinion is, that is it a good endeavor. Such work is needed to complete the foundation for modeling tools, that allow for more comfortable modeling consistency checks and functionality.
I especially see much benefits in consistency checking. I also have one or two patents in this area. Important in my view in consistency is a clear definition of the goal of the check and a good method to explain consistency errors to the tool user. Consistency checking is in most cases useful. One needs a little bit of patience, to make a service definition fit to another, because there is always this one unwanted execution that needs to be eliminated. But it is worth the effort, because it is better to eliminate these errors in modeling time than in runtime.

Service construction is in my personal opinion difficult. In my view there are always abiguities in such an endeavor. So I prefer “human” design plus consistency check.
Service composition promises some benefit – especially if there is a skeleton composed, which can be further edited by the human designer. Also here it is important to formulate clear goals of the service composition and to have a complete – i.e. without gaps – description of the underlying services. Especially if there is a Business Process Platform that offers services, that need to be composed, and that is model driven, this is very promising. There are also other projects working on this. I may come back to this some other time.
Service Replacement is certainly an interesting application. If a service is changed, then it is certainly worthwhile to know potentially which consuming services might be affected and which not. This may be the outcome of this part of the research.

So good work – keep it going!

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]

There have been complaints, that BPMN 2.0 is only designed with the goal of defining an executable process modeling language and that this impairs the usage of the modeling language for the purposes that it is currently most often used for: documentation.
http://www.brsilver.com/wordpress/2009/01/19/bpmn-20-update/
The complaint is that a model would not be counted as valid, if it is not executable. The demand is that it should also be valid, if it is not executable.
To shed some more light on the issue it is necessary to discuss several aspects. These come to my mind immediately:

1. Choreography Modeling and Execution
2. The concept of enforceability
3. Conformance
4. Abstract Processes

Ad 1) A new feature in BPMN 2.0 is the choreography model. Modeling a choreography model with BPMN 2.0 means modeling an abstract process representing the view of an independent observer on the exchange of the messages that are exchanged between participants. This process is by definition abstract, because it is “in the middle between” the participants. So by definition such a process can never be executed directly or be executable. It can only be realized by means of processes within the participants. But the realization is not necessary for a choreography model to be valid.
Ad 2) Enforceability of a choreography process is an attribute, that holds true, if a choreography model can be realized at all. Not all choreography models are able to be realized. This is completely independent of any technology. It is because of logic only. To make an example If we define this process between John, Mark and Jane, which are in different cities: First John calls Mark and tells him the weather. Then after this Jane calls Mark and they plan the weekend trip. This process is not enforceable. Because Jane cannot know when John has called Mark. So to make the process enforceable, John or Mark need to call Jane to tell her, that John and Mark have phoned. Which of both is better is another thing – but the first process is not enforceable – completely independent of the technology.
So yes, there are some rules in BPMN 2.0 Choreography model that must be kept with a choreography process so that the enforceability is not destroyed. But this has merely logical reasons.
Ad 3) There is a difference between Process Modeling Conformance and Process Execution Conformance. Process Modeling Conformance does explicitly not require that the Process Execution Semantics is kept. However the Process Execution Semantics is most clearly defined. But because this is optional, it is only for those who want to execute. And for those, an execution semantics is very helpful.
Ad 4) Abstract Processes are Processes that have the process type abstract. By definition they are not executed as is, but they are an abstraction of the process, that is really executed.
Good discussion though and I might continue to post on this.