Instance Alignment in BPMN
Blog: Method & Style (Bruce Silver)
One of the most common mistakes beginners make with BPMN stems from lack of clarity as to what exactly BPMN means by a process. A BPMN process is a defined set of sequences of activities, performed repeatedly in the course of business, starting from some triggering event and leading to some final state. The key word here is “repeatedly”. The same process definition is followed by each instance of the process. Not all instances follow the same sequence of activities, but all follow some sequence allowed by the process definition. That’s not Method and Style, that’s from the spec. The spec just doesn’t say that very clearly.
Each process instance has a defined start and end. The start is the triggering event, a BPMN start event. The end occurs when the instance reaches an end state of the process instance, which in Method and Style is an end event. It helps to have a concrete idea of what the process instance represents, but I have found in my BPMN Method and Style training that most students starting out cannot tell you. Actually it’s very easy: It is the handling of the triggering event, which in Method and Style is one of only three kinds: a Message event, representing an external request; a Timer event, representing a scheduled recurring process; or a None start event, representing manual start by an activity performer in the process, which you could call an internal request. Of these three, Message start is by far the most common. That request message could take the form of a loan application, a vacation request, or an alarm sent by some system. The process instance in that case is then essentially the loan application, the vacation request, or the alarm. In Method and Style, it’s the label of the message flow into the process start event. With a Timer start event, the instance is that particular occurrence of the process, as indicated by the label of the start event.
Here is why knowing what the process instance represents is important. The instance of every activity in the process must have one-to-one correspondence with the process instance! Of course, there are a few exceptions, but failure to understand this fundamental point leads to structural errors in your BPMN model. And those structural errors are commonplace in beginner models, because other corners of the BPM universe don’t apply that constraint to what they call “processes”.
Take, for example, the Process Classification Framework of APQC, a well-known BPM Architecture organization. It is a catalog of processes and process activities commonly found in organizations. But these frequently are not what BPMN would call processes. Even those that qualify as BPMN processes may contain activities that are not performed repeatedly on instances or whose instances are not aligned with the process instance. Here is one called Process Expense Reimbursements, listing five activities.
But notice that two of the five (8.6.2.1 and 8.6.2.5) are not activities aligned one-to-one with the process instance. That is, they are not performed once for each expense report. That means that if we were to model 8.6.2 Process Expense Reimbursements in BPMN, activities 8.6.2.1 and 8.6.2.5 could not be BPMN activities in that BPMN process. So where do they go? They need to be modeled in separate processes… if they can be modeled as BPMN activities at all! Take 8.6.2.1 Establish and communicate policies and limits. For simplicity, let’s assume that establishing and communicating have one-to-one correspondence, so they could be part of a single process. How does an instance of that process start? It could be a recurring process – that’s Timer start – performed annually. Or it could be triggered occasionally on demand – Message or None start. The point is that 8.6.2.1 needs to be modeled as a process separate from Process Expense Reimbursements. The result of that process, the policy and limits information, is accessible to Process Expense Reimbursements through shared data, such as a datastore.
Activity 8.6.2.5 Manage personal accounts is not a BPMN activity at all. It cannot be a subprocess, because there is no specified set of activity sequences from start to end. To me it is an instance of a case in CMMN, not an activity in this BPMN process.
All this is simply to point out that instance alignment is a problem specific to BPMN because other parts of BPM do not require it.
Since “business processes” in the real world often involve actions that are not one-to-one aligned with the main BPMN process instance, how do we handle them? We’ve already seen one way: Put the non-aligned activity in a separate process – or possibly case. Communication of data and state between the main process and the external process or case is achieved by a combination of messages and shared data.
Repeating activities are another way to achieve instance alignment.
- A loop activity can be used when an activity must be performed an unknown number of times until it completes successfully. Its behavior is the same as a non-loop activity followed by a gateway that either exits or loops back to execute the activity again. Iterations of a loop activity are always sequential, and you don’t know when you begin the first one how many iterations will be required. Method and Style requires a text annotation on a loop activity, “Loop until [condition]”.
- A multi-instance activity is used when the process instance involves a list and the activity must be performed once for each item in the list. Method and Style requires a text annotation “For each [item]”. The activity is not complete until all its instances are complete. Iterations of a multi-instance activity may be specified as parallel or sequential. With a parallel multi-instance activity, all instances start at the same time. A sequential multi-instance activity is not the same as a loop, since you know at the start how many iterations are performed.
When instance alignment requires two BPMN processes working in concert, it is often helpful to draw the top level of both processes in the same diagram. This can clarify the relationship between the instances as well as the coordination mechanism, a combination of messages and shared data. You can indicate a one-to-N relationship between instances of Process A and Process B by placing a multi-instance marker on the pool of Process B.
An example of this we use in the BPMN Method and Style training is a hiring process. The instance of the main process is a job opening to be filled. It starts when the job is posted and ends when it is filled or the posting is withdrawn. So it qualifies as a BPMN process. But most of the work is dealing with each individual applicant. You don’t know how many applications you will need to process. You want processing of multiple applicants to overlap in time, but they don’t start simultaneously; each starts when the application is received. So repeating activities don’t work here. One possible solution is shown below.
Here there is one instance of Hiring Process for N instances of Evaluate Candidate, so the latter has the multi-participant marker. Hiring Process starts manually when the job is posted and ends when either the job is filled or the posting expires unfilled after three months. Each instance of Evaluate Candidate starts when the application is received, and there are various ways it could end. It could end right at the start if the job is already filled, since before the instance is routed to any person, the process checks a datastore for the current status of the job opening. It could end after Screen and interview if the candidate is rejected. If an offer is extended, it could end if the candidate rejects the offer, or successfully if the offer is accepted. And there is one more way: Each running instance could be terminated in a Message event subprocess upon receiving notice from Hiring Process that the posting is either filled or canceled. While not perfect, this BPMN model illustrates instance alignment between multiple processes working in concert, including how information is communicated between them via messages and shared data.
There is yet another way to do it… all in a single process! It uses a non-interrupting Message event subprocess, and is an exception to the rule that all process activities must align one=to-one with the process instance. It looks like this:
Now instead of being a separate process, Evaluate Applicant is a Message event subprocess. Each Application message creates a new instance of Evaluate Applicant. You don’t know how many will be received, and they can overlap in time. As before, each instance checks the datastore Job status. Since everything is now in one process, we can no longer use messages to communicate between Evaluate Applicant and the main process. Here we have a second datastore, candidates, updated by Evaluate Applicant and queried by Get shortlist to find newly passed applicants. Instead of an interrupting event subprocess to end the instance, we use a Terminate event after notifying all in-process candidates.
If you are just creating descriptive, i.e., non-executable, BPMN models, you may wonder why instance alignment matters. It certainly can make your models more complicated. But even in descriptive models, in order for the process logic to be clear and complete from the printed diagrams alone – the basic Method and Style principle – the BPMN must be structurally correct. If it is not, the other details of the model cannot be trusted. If you want to get your whole team on board with BPMN Method and Style, check out my training. The course includes 60-day use of Trisotech Workflow Modeler, lots of hands-on exercises, and post-class certification.
Leave a Comment
You must be logged in to post a comment.
