Other than most graphical process notations, BPMN provides special means for modeling collaborations. A collaboration is a synchronized interaction of two or more processes without central control. The processes communicate by exchanging messages.
Such an interaction is also called “choreography”. There is also a specific BPMN diagram type, the choreography diagram. Such a diagram also shows the interaction of several partners, but in a different way. In order to distinguish the two possible representations of interactions, the modeling style introduced in this chapter will always be referred to as “collaboration”. Choreography diagrams will be presented in chapter 11.
Collaboration diagrams are especially useful for documenting the co-operation of several companies. The purchasing process of a customer and the order fulfillment process of a supplier are two independent processes. However, they are connected. In the purchasing process, an order is sent which triggers the supplier’s order fulfillment process. Then this process sends an order confirmation as a reply, and so on.
Collaborations are modeled with two or more pools. Each pool contains a separate process. Between the processes, message flows are modeled. A pool does not need to represent a company, but it can also stand for a computer program or a technical system, for example. Therefore, not all collaborations represent interactions between enterprises. It is also possible to model something like a collaboration in which several independent computer programs exchange data.
Figure 51 shows an example of a model with a collaboration. It presents the interaction between an applicant and an enterprise in the process of a job application.
Separate pools are used for applicant and enterprise. By this, it is expressed that both participants of the collaboration are independent of each other. The applicant cannot influence the enterprise’s way of processing a job application, nor can the enterprise determine what the applicant does concerning the application. And, of course, there is no central authority that would define and control the entire process that spans the two participants.
Therefore, each pool contains a complete process with a start event and an end event, with activities and the sequence flow. However, the two processes are not entirely independent, because messages are interchanged. As a part of the activity “Write Job Application”, the applicant sends a message to the enterprise, containing his application. The enterprise takes this message in the activity “Receive Application”. The following activity “Confirm Receipt” sends a message with a confirmation of receipt to the applicant.
On the applicant’s side, the writing of an application is followed by the activity “Receive Confirmation of Receipt”. This activity has an incoming message flow, i.e. it can only be completed when the message with the confirmation has been received.
As long as no confirmation of receipt has arrived, the applicant’s process does not continue. This behavior is unfavorable because it may happen that an invitation to an interview arrives without a prior confirmation of receipt. The process cannot react to that invitation because it still waits for the confirmation of receipt. A better process would handle this possibility correctly, and also other alternatives, such as a rejection by the enterprise, would be considered. These cases have not been included in figure 51, to keep the model simple.
In the job posting process in chapter 2, the pool was labeled with the name of the process (figure 1). In figure 51, the labels do not contain the process names, but the partners’ roles. This is typical for collaboration diagrams. In this example, both partners, applicant and enterprise, are displayed in the same way. The diagram could have been created both from the applicant’s perspective and from the enterprise’s perspective.
In practice, a collaboration diagram is often created by only one of the partners. In this case, the own pool can be labeled with the name of the process. The other pools are
Figure 52: The company’s own pool (bottom) is labeled with the name of the process
labeled with the partners’ roles. In that way, it is clear which process is shown in the model, and also which partners are involved. If the above collaboration diagram is created by the enterprise, it may label its own pool with the process name “Recruit Employee” (figure 52).
Often, the own process is contained in an implicit pool which is not displayed in the diagram (cf. figure 53). A collaboration diagram may contain not more than one implicit pool.
A message flow can represent any kind of information exchange, for example a phone call or the sending of an e-mail, a fax, or a letter. Messages can also be connected to physical objects, e.g. a delivery of goods can be modeled as a message flow in a collaboration. Of course, every kind of electronic data exchange can be shown as message flow, such as downloading a file or the call of another system’s function, e.g. via a web service.
Figure 54: Message flows are only allowed between pools, not within a pool
In contrast to the solid lines of the sequence flows, message flows are drawn with dashed lines. The start is marked with a little circle, the inside of the arrowhead is blank. In BPMN, message flows are only used for the communication of independent processes, which are in different pools. Thus, message flows are only allowed between different pools, but not within one pool (figure 54).
Sequence flows, on the other hand, are used for modeling the flow of an independent process within one pool. Therefore, sequence flows must not cross borders of pools (figure 55).
Lanes are subdivisions of pools. From the perspective of the BPMN specification, lanes rather provide supplementary information to a model, i.e. they do not influence the logic of the sequence flow. Therefore, sequence flows can cross the borders between lanes. Message flows between different lanes within the same pool are not allowed because start and end of a message flow must be in different pools (figure 56).
Figure 55: Sequence flows are only allowed within a pool, not between pools
Figure 56: Sequence flows can cross the borders of lanes within a pool. The message flow on the right is still within one pool, and is therefore not allowed.
Correctly modeled message flows, i.e. message flows between different pools, can cross the borders between lanes without any problems. Examples are shown in figure 57.
The collaboration in figure 51 shows the internal processes of both involved partners. In many cases, however, only the internal processes of the own enterprise are known, but not the partner’s processes. Only the messages are known which have to be exchanged with that partner during the process.
In such a case, this partner’s pool is drawn without the process. The message flows then simply start and end at the borders of the pool (figure 58).
Figure 57: Message flows can cross the borders of lanes, but they must start and end in different pools
Figure 58: Message flow to a pool without modeling its internal details
If only the exchanged messages and their order are relevant, both pools can be drawn without their processes, as in figure 59. In that way, the exchange protocol of the collaboration can be documented. The partners need to agree on the content of this protocol so that the entire scenario will work. In this model, both pools are labeled with the names of the partners, since in contrast to figure 58 this model does not represent the specific view of one partner.
If an applicant asks the enterprise how a job application is handled, the content of figure 59 will be explained to him: First he needs to send an application; then he gets a confirmation of receipt, and so on. Thus, the message exchange protocol of the job application process represents the enterprise’s interface to the applicant.
However, in that way no complex dependencies can be modeled regarding message exchange. It is not possible to model, for example, that after the confirmation of receipt, the applicant will either receive an invitation or a rejection. Nor can the fact be expressed that the questions and answers of the interview will only be exchanged after an invitation has been sent. Such dependencies can be modeled in choreography diagrams (cf. chapter 11).
In collaborations, it often makes sense not only to provide the partner with a black box representation of the own process but to disclose the process details as far as it is necessary for the co-operation. Thus, the partner can view the process and, for example, realize that a certain message is only sent under certain conditions.
A process may contain details which are not relevant to the partner, or which the company wants to keep secret. This can be achieved by providing a simplified view of the process to the partner. Such a simplified external view is also called “public process”. Consequently, an internal process with all its details is called “private process”.
Figure 60 shows an example of a private process. It presents in detail how an advertising agency produces an advertisement, and which messages it exchanges in doing so. This process contains a number of activities and loops which are not interesting to the customer, such as archiving, reviewing, and reworking.
The exchanged messages, on the other hand, are interesting for the customer. However, if the model contained only the pure message exchange without the process, the customer would not see, that after the feedback to the proof, another proof may be sent, for which feedback is required again, and so forth.
The public process in figure 61 does not present the details that are irrelevant for the customer. It only contains those activities that influence the collaboration. It is therefore the customer’s view of the process from figure 60.
There are no defined rules for creating a public process out of a private process or vice versa. It is only required that the external behavior concerning the message exchange must be the same.
Typical actions during the transition from a private process to a public process include the combination of several elements into aggregated activities, as well as the removal of elements not required. In the above example, several elements have been removed from the public process: The two parallel loops for ensuring the quality of the text and the layout, as well as the activity “Archive Advertisement”.
According to the BPMN 2.0 specification, an extended process “supports” a simpler process, if the entire process logic of the simple process is completely contained in the extended process. In this case, the simple (i.e. the supported) process can be replaced without any problems by the extended (i.e. the supporting) one. This is also true for private and public processes. The private process from figure 60 can be used instead of the public process from figure 61 without changing the externally visible process logic.
Figure 60: Example of a private process
Figure 61: The public process related to the private process of figure 60
Concerning content, of course, there is a difference, because the resulting advertisement will be different, e.g. when the text is proof-read and corrected.
In the previous examples, every pool represented exactly one participant. How can the interaction with a group of partners be modeled? If a company sends an inquiry to ten suppliers, it would be rather laborious to model ten pools. What is more, the exact number of partners is different in every process instance, and not yet known at modeling time.
In the example of hiring an employee (figure 51), the interaction of the enterprise with only one applicant was modeled. In practice, there are usually several applicants, one of whom is selected. Therefore, in figure 62 the applicant’s pool is marked with three lines as a multi-instance participant. It stands for a group of applicants.
The messages are exchanged with each individual participant. For this, two loops have been included into the enterprise’s process. In each cycle, the messages are exchanged with another applicant – until there is no applicant left. Each applicant’s process is the same, shown in the pool on top.
Some interesting steps from the original hiring process are missing in the presented collaboration, especially the sending of the contract to the selected applicant. Consequently, the other applicants receive a rejection. The applicant’s process then needs to react differently to different message flows. Either the signed contract is sent back, or the process is finished without further activities. Suitable modeling constructs for such a case are presented in the following chapter.
As shown in figure 63, the pool of a multi-instance participant can also be drawn as a black box.
It is obvious that collaboration diagrams are useful for modeling the interactions of several companies. However, pools need not necessarily represent companies. Instead, they can also stand for divisions or technical systems. A process that spans several units is usually modeled in one pool with several lanes, but it is also possible to model it with several pools. Each division then has its own pool, and the divisions’ processes use message flows for communicating.
In which cases should a modeler use several distinct pools and message flows? Which cases, on the other hand, are better represented by a single pool with several lanes?
The deciding criterion for using a pool is, whether the process is defined or controlled entirely within that pool. For a process that is executed by a process engine of a workflow or business process management system, this is easy to decide. The sequence that is controlled by the process engine should be within one pool. If the process interacts with another, separately controlled process, this other process is in another pool. The communication between them is modeled with message flows. Everything that is inside one pool is controlled by the process engine as a central unit.
Figure 63: Multi-instance participants with black box pool
Several different processes within one process engine are also shown in separate pools if they run in the form of separately controlled process instances which only communicate by exchanging data.
A process which is not – or only partially – executed by a process engine usually does not have such a central unit that controls every step in the process. However, for such a process it is still possible to identify a surrounding entity which provides a scope for defining and controlling the process, typically an enterprise or an organizational unit.
If a company defines processes that span several divisions, it is suitable to use one company pool with a lane for each division. On the other hand, there may be companies in which all divisions define their own independent processes, and they only agree on the information to be exchanged. In this case, it is also possible to model separate pools for the divisions, connected via message flows. However, this is inconsistent with the process management idea, according to which entire end-to-end processes should be analyzed and improved, rather than small processes within single divisions. If unchangeable interfaces between divisions are defined at the beginning, process improvements across divisional borders are almost completely prevented.
Within inter-company processes, each participating company usually retains the sovereignty of its own internal process. Therefore, using a collaboration diagram seems obvious.
On the other hand, there are also cases in which it makes sense to model an inter-company process completely with sequence flows inside one pool. In such a case, the pool represents the network of co-operating partners. This is reasonable when there is a very close co-operation, and the partners define the entire processes together. Examples for such close co-operations are the integration of suppliers in the automotive industry, enterprise consortia, and virtual enterprises. Since the partners work together in creating the process, they share the sovereignty over the process.
If the partners define their processes independently of each other, this may lead to the following situation. A supplier performs a quality control before shipping goods. When the customer receives the goods, he performs a quality control for the same goods again. If only the collaboration and each partner’s individual process are analyzed, it cannot be detected that the same activity is performed twice. If the partners agree to jointly optimize the entire process, a model with one pool and sequence flows clearly shows the duplicate work. In the optimized process, only one partner performs the quality control. This, of course, is only possible if the customer can rely on the supplier.
In a second step, the partial processes of each partner need to be detailed and supported by information systems. For this step, modeling different pools and message flows may be appropriate again.
So there is no general answer to the question whether to use one pool with sequence flows, or several pools with message flows. For different situations and modeling purposes, this question will be answered differently.
Message flows carry content, such as documents, data sets or even physical objects. In the previous examples, the type of message content was indicated by the names of the message flows. However, BPMN distinguishes between the message flow and the message itself, i.e. the transmitted content. For business-oriented models, this differentiation is not that significant. For executable models, however, it may be important. The message flow involves the transmission and the receipt of defined messages. The message itself may contain a data structure, or the like, which may be stored or provided to a service.
Messages are displayed as envelope symbols (figure 64). There are blank envelope symbols, as well as shaded symbols. A shaded symbols usually stands for a message that is sent as an answer to a previous message. Blank symbols mark messages that initiate a message exchange. The benefit of these different colors becomes clear in the context of choreography diagrams (chapter 11). In a pure collaboration diagram, blank envelope symbols are sufficient. Alternatively, the message flows can be drawn entirely without envelopes. Modeling teams should decide for one style and use it consistently.
Figure 64: Use of envelope icons for message content
