Definition 1: Orchestration - a diagram depicting a sequence of activities coordinated from a single center of control.

Notes:

• Synonyms to orchestration are workflow and, in fact, process.
• Orchestration is modeled by a white-box pool in BPMN; it may also contain optionally black-box pools presenting external entities.
• The phrase “coordinated from a single center of control” means that even if a process diverges at some point, the branches remain coordinated e.g. they can be synchronized later in a converging fork; the whole process will end when all branches are completed.

Definition 2: Collaboration - a diagram showing interactions between processes.

Notes:

• In BPMN 1.x interprocess communication was called choreography. In BPMN 2.0 choreography is reserved for a totally new type of diagram - what used to be a choreography in BPMN 1.x is called collaboration now. So it goes.
• A collaboration diagram contains more than one white-box pool.
• Some people reduce collaboration to the exchange of messages but generally speaking, processes may communicate via messages, signals and/or data (data store, conditional event).
• Processes on a collaboration diagram are executed independently except specific sync points where messages and signals are sent/received, data read/written.

The big BPMN advantage is its support of collaboration as well as orchestration. This is also a key criterion for choosing a BPMS. Yet as my BPMN training shows, the right balance between orchestration and collaboration is tricky.

There are two common pitfalls:

1. At a first approach to BPMN analysts try to do the job with orchestration only. Yet it works only for very simple processes like vacation request. Cross-functional processes that are of greatest interest for the business are multi-threaded by nature and hence can’t be modeled within orchestration.
2. After getting acquainted with messages and learning that they can only be used between pools, many analysts introduce unnecessary pools into their diagrams. For example they love to use pools and messages where a subprocess would suffice:

Fig.1 Process antipattern: “Messaging instead of subprocess”

The common arguments in favor of this scheme:

• “This process is performed by another entity.” - Use swimlanes not pools to show a performer.
• “The process can be called from several points.” - So do reusable subprocesses.
• “The link between the caller and the calling process becomes visible.” - First of all, expanded subprocesses are transparent, too:

Fig.2 Expanded subprocess

• Secondly, for a well-structured diagram with properly separated abstraction levels collapsed subprocesses are sufficient: when we look at the process top-level, we must understand its logic without knowing the details of subprocesses. The subprocess contents shaill be presented on a separate page:

Fig.3 Collapsed subprocess

It’s a matter of style rather than correctness - the diagram in Figure 1 is formally correct. Yet I recon it’s an antipattern and inventing a wheel because messages are used to model a behaviour witch is already built-in into subprocess invocation:

• when a control flow reaches a subprocess a token emerges with a subprocess and the caller goes into a wait state
• when the subprocess completes the caller continues

In summary, here are my rules for the optimal balance between orchestration and collaboration:

Rule 1. If your attempts to model a process are unsuccessful because some significant aspects are missed repeatedly then stop and think - maybe in fact it’s not a single process but two or more?

Rule 2. Do not overuse collaboration - stay within the orchestration as long as possible. Never introduce collaboration into a diagram just because you’ve recently learned how to do that.

In the following article I’ll share my experience of identifying independent processes during analysis.