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.

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.

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.

The business processes are reflected by business objects themselves, which are linked with each other. Events are correlated to the business objects. This makes sense, because the business objects are clearly identifiable, because they are related to a concrete business transaction. There are concrete customers related with it, suppliers, products, dates – the things that make them easy to identify and find.

In contrast, if there are process instances, which have only an anonymous ID, like a Globally Unique Identifier (GUID), then the relationship to a concrete business transaction is rather loosely. Therefore it is hard to manage them. Furthermore if there are business attributes inside of the process instance, typically they are in generic containers (not always) and therefore difficult to use in queries.

So which process instances are needed within a Business Process Platform beside the business objects themselves? Probably some for approval. Some for ad-hoc processes. Not much more comes to my mind.

Monitoring a business process itself is a different story. For this not process instances are needed, but chains of business objects that are actually process objects and some process instances – that I already mentioned.

The more process instances are created in the system, the more care needs to be taken that they all are managed correctly. Some unwanted effects may occur:

• An event is not correlated to the process instance it should have been correlated to (e.g. because of wrong correlation rules)
  • As a effect the event disappears without any effect.
  • As another effect the process instance, that the event should have been correlated to is stuck in an unwanted state.
    • A subsequent event, that is correlated again to this process instance, may find the process in the wrong state, causing more problems.
• An event is correlated to a process, that it should not have been correlated to.
  • As an effect the event is consumed and may not be correlated to the process instance, that it correctly should have been correlated to.
  • As another effect, the event will cause a problem in the wrong target process.
• Process instances may be started, even if there is already a process for the same thing, because of wrong correlation rules.
  • This may lead to starvation of other processes.
• There is no guarantee, that an event is correlated to any process.

So in the end there may be a system with many problematic process instances. Especially if not care is taken, that the correlation rules are absolutely consistent. This is difficult to achieve, especially if they can be maintained independently from each other.

So many problems? Well, at least problem recognition is the first step to the cure.

In Procedure vs. Process it is discussed from the angle of if it is a sequence or order of action or not sequence or order. Also Merriam-Webster dictionary is cited to say that a process is

a series of actions or operations conducing to an end ; especially : a continuous operation or treatment especially in manufacture

I fundamentally disagree with this definition. In my opinion the series of action is only one half of a process. The state is the other half. A process must always have a defined state. Either it is not started, it is finished or in the middle – in process. If it is in process, it needs to be further defined, what the detailed state is. So if a process is modeled in terms of actions, then the question is, which state do the individual actions have.

In the Blog Column 2 – links for 2009-02-02 we see the statement that refutes the difference between process and procedure as claimed by Procedure vs. Process . For my taste this is a little bit a too technical discussion.

I rather approach it from a little bit different angle. For me a busines process is the sum of all business objects and process objects that are needed to achieve a common busines goal, their state, their actions and the constraints between the actions and the state.

You might argue, that I define process by process – i.e. business process by process object. But they are different. Process objects are like workflows and have a rather small business goal , but a business process has a much broader scope. All process objects are small business processes, but not vice versa.

By such a definition I exclude such things like interactions with the system, because they do not have a state. So adding a sales order, saving it, adding another sales order and saving it is no business process by this definition, because it has not state and it does not achieve a common business goal. A business process would be to deliver goods which have been ordered by customer orders and bill them, and collect payments for them. This is a common business goal and the whole process has a state which is reflected in the state of it’s business objects, namely the customer order, the delivery, the invoice and the payment.

It is a trend to offer tooling that supports BPMN modeling together with model syntax checking and model simulation. For example see BPMN simulation and syntax checking in ARIS.

Model syntax checking can make sure, that modeling rules, that are statically checkable are kept. It is definitely a help. Especially beginners do not know all of the syntax rules and are guided by the checks. Also experts might find this feature helpful.

Model simulation can be distiguished into

1. Interactive simulation of a single process instance and
2. Cumulative simulation, where many process instances are created and throughput and latency are determined

Especially the ineractive simulation of a single process instance can also be a great help in understanding the model and even the modeling elements and it’s semantics.

The cumulative modeling itself is more like a determination, if the underlying business process is optimal or not.

Another category is thinkable: The verification. While cumulative simulation or single model instance simulation can not ensure, that certain attributes for a process hold, like the absence of deadlocks, verification can. Here it is decisive to find the right attributes of a process that shall be tested.

All of this are technical means to achieve better model quality, and all of these are useful. But none of these is so useful as a governance process. Just because humans can without all of these means do the same thing and they can do even more. They find problems, that even the most sophisticated syntax checker, simulator or verification routine will never find. Also what all of these methods can only find is the consistency of the model in itself (or with another model), but never can test the correspondence of the model with the real world process. This will still be left for humans for all times.

Therefore while all of these means of checking and testing are useful, because they are comfortable, they can or should never substitute a governance process.

This may happen: The right means are used for the wrong purpose, and the result is a disaster.

I have already discussed, that the modeling purpose does determine the outcome of a modeling exercise.

So what happens, if you use the right modeling language for the wrong purpose? It ends up in spaghetti models.

If you try to use a BPMN model for the purpose of model driven development – as mentioned in the blog (i.e. to generate coding) – for a business process with many special cases, then the result can be a spaghetti model. But this is not because BPMN is not good, it is because the right means for the wrong purpose has been used.

What is the level of detail that should be modeled? By which modeling technique it should be modeled? These difficult questions are best solved within the scope of a model governance process. As soon as a model become a subsitute for coding only – i.e. it is not human readable any more – it misses it’s purpose. Then it would be better to code. A governance process makes sure, that it is still human readable.

Furthermore it needs to be considered, that BPMN is not the only modeling language in the world and should not be used for purposes, where other means are better. I will elaborate on this later.

In itself this is not sufficient to achieve a consistent model quality in designing BPMN models. More is needed. The missing element is a governance process.

What is a governance process in this context?

What you need to design high quality (BPMN) models is experience. It is always possible to solve a certain modeling problem is different ways. Which is the best way for which kind of modeling problem? Unter which circumstances is which solution better? Is a certain solution consistently applied across a large set of models, if the underlying modeling problem is the same? What are the modeling rules, what are the patterns?

Theoretically it is possible, that a single person has all the experience needed. But still then this single persons approach differs from an approach of another single person. Also it is not clear if this single person is always available. Furthermore we are humans and we err.

So the elements of a governance process, that produces consistently high quality in modeling are these:

1. A defined number of modeling experts with different background, which collaborate over a long period of time with some, but little fluctuation.
2. A defined review process with enought time to study a model for all reviewers (experts) and the possibility to accept or reject a model.
3. The possibility to raise issues, discuss pros and cons and find solutions.
4. A list of quality criteria, patterns and modeling guidelines which each model needs to fulfill. This grows over time by common action of the experts.

Each expert that takes part in such a governance expert council will learn from each new model review and the common expertise will rise. The quality level of models can be held consistently high. Futhermore is the feedback of such an governance expert council to the standard – in this case BPMN – invaluable, because they are those who find out even the subtle weaknesses of the standard over time. Each modeler, that commits to the governance process learns more than any theoretical class can ever teach him.

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]