Elaborating more on what I said before about loosely coupled processes, I want to emphasize today, that the cut of the processes is of major importance – i.e. which parts are loosely coupled and which parts are tightly coupled. Furthermore if process parts are loosely coupled, it is of big importance which process parts are public and which are private. Public process parts constitute a contract, that the other participant can rely on (when to request, when to confirm), while private processes are only needed within the operations of one participant’s organization – for example an approval or a special form of approval that is irrelevant to the other partner. This has these benefits:

• Flexibility: It is possible for one participant to adapt the private process to changes as business requires it without the need to negotiate with the other partner, as long as the change still complies to the public process.
• Stability: The participant can rely on the behavior of the opposite participant, even when the opposite participant makes changes that comply to the public process.
• Visibility: In Process Monitoring internals are not visibible because they should not. It is a decision of discretion which parts of the process should be visible to other partners. However I believe that BPMN 2.0 might be amended for this purpose, because for this it might be necessary that also non-communication activities can be part of a public process.
• Decoupling: The number of private processes that comply to a public process needs not to be multiplied with the number of choreographies, that comply to a public process. Say you have 3 choreographies that you want to combine with 3 private processes. Then without decoupling you have 3*3=9 process models. With decoupling you have 3 + 1 + 3 = 7 process models.

It is important to understand, that the Choreography is an abstract process while the private process is a concrete process – i.e. can be executed by a process engine and has process instances. So the Choreography Model will never be executed by a process engine. It is the summary view of the participants. It never proceeds on it’s own. It proceeds, if one of the participants proceed (as far as the public process is concerned).

If you ever tried to build a central process with process instances that decide about the message flow, you might have tasted how difficult that is. For simple processes this might still be possible. However you always find these difficulties:

• Either the central process does not have enought information to decide – and that are business decisions in the end – or
• The central process needs to know nearly everything.
• As soon as information reaches the central process by means of messages, it is already outdated (because the sender might have evolved in the mean time).
• Also in many decisions it is necessary to involve humans, not just rules.
• If humans are involved, they might not only to decide left-right, but regroup – solve differently (e.g. create return instead of lowering delivery quantity).

This all leads to the conlusion, that I have made for myself: If there is a middle tier, it needs to be a full fledged business application in the end. With business objects, UIs and the like.

Then we have 3 partipants instead of 2 – which is fine. Then we have 2 Choreographies between them, which are still abstract.

Why I am looking at these MDA papers?

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.

Reframing the BPMN vs BPEL Debate poses some interesting questions. I took from it:

1. Is BPM a business Discipline or software engineering?
2. Whose responsibility is it to implement (automate) a business process?
3. Should we aim to move from design to deployment with no programming?
4. Whose responsibility is it to maintain a business process?

I have some opinions on these questions.

Is BPM a business Discipline or software engineering?

In my opinion it is foremost a business discipline. It  is about managing business processes, as the term says. It is identifying processes, understand them (model them), define a roadmap for process changes, design new processes, implement and monitor then. This all can – theoretically – be done without IT. Actually most of our day to day processes (drive to work, go to the supermarket on saturdays) are without an electronic workflow (well – some might have . Also the people of old had very much the same principles when they organized their kingdoms and businesses – without IT. They weren’t sending XML messages back and forth – but herolds and messengers on a horse and the like. This of course were also business processes which were also managed and clearly defined. They did not call it BPM back then, but it was in it’s essence.

But is it a question of scale and speed. In practical today’s business life it is inevitable to use IT to reach the needed performance of the business process execution and the needed information pool for the monitoring of it. Therefore the question of how to transfer modeled business processes from the business discipline of BPM to IT is crucial.

Whose responsibility is it to implement (automate) a business process?

In my opinion it is the responsibility of the process owner. The process owner in my opionion is foremost a business person. He is responsible to design and implement the business process. Design – I don’t mean necessarily the modeling with BPMN for example. This of course can be delegated. But the process owner is in the end responsible for the performance of the process and the profit it yields.

If the process owner decides, that a particular part of the process or the whole process should be supported by automation, then of course this part can be delegated.

Should we aim to move from design to deployment with no programming?

This is in my opinion unrealistic. Also it is a question of definition. What is programming and what is not programming? Typically people associate programming with imperative programming (like in C#) or with character based input. Modeling is on the other side which is more declarative and more graphical. But what about rules for example? They are character based and declarative. Also they can usually call subroutines, which are imperative. In some sense a BPMN model is also imperative. So what does this question mean? Probably it is, that it must be made easier for business experts to express which process they have and which they want. Of course it is a big benefit, if these models can be used in runtime or transformed in some canonical way into runtime. The success depend on if it is possible to express the process in the languange of the domain of the business process owner. This is why I think that Domain Specific Languages must be desiged with the greatest care and intelligence. And I think that this area is much less expoited than it could be. In my opinion much more is possible that we have achieved on the great scale already.

Whose responsibility is it to maintain a business process?

In my opinion it is the Business Process owners responsibility, who is a business person. And he might delegate it to someone of IT. However the model is the common communication channel between the two. So the model must be accurate, understandable, detailed, summary, and optimally simulateable. Especially the part of  interactive simulation has been much underestimated in my opinion, because it is able to show the behavior of a system implementation of a business process before it is implemented.