Business Processes might start out as easy-to-diagram simple processes. Over time, these processes get more complex, as they have to deal with real-world considerations and unanticipated situations. Things can go wrong. Classical flow diagramming gets complex when dealing with errors or exceptions in a process, while BPMN modeling keeps things simple.
Background
We presented an introduction to BPMN diagrams in July. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.
The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).
Intermediate events are one of the more unfamiliar items in the BPMN language. They also allow for some of the cleanest, unambiguous expressions of steps in business processes.
Before Intermediate Error Events
Before we look at intermediate error events, we will take a look at how the same situation would be handled with classical flow-charting.
Original Plan
Consider a classical flow chart model of a bank robber’s original plan for robbing a bank.
The bank robber announces that he is robbing the bank, steals the money from the vault, and runs away. The only problem is that the process is too simplistic. If it were this easy, everyone would be robbing banks. The robber needs to improve his plan. Business process modeling is trivial with simplistic processes, and interesting with interesting processes.
Improved Plan
We can redesign the bank-robbery process to account for contingencies and mistakes. The bank robber realizes that he might accidentally set of an alarm. Further, the robber realizes that it takes time to steal the cash from the vault. If he trips the alarm, he can still get away, if he’s already done stealing the cash. If he’s still inside the vault when the alarm goes off, he knows he will be arrested. And if he trips the alarm before he even gets into the vault, he can still escape, but without any money.
This improved plan is more representative of an actual bank heist. It also looks a lot more like a real-world business process than the original plan. Unfortunately, the classical flow chart diagram of this process is pretty convoluted. We have to create two parallel flows, one for possibly triggering the alarm and one for robbing the bank. Since triggering the alarm may or may not happen, we need to represent it with two entities – a decision entity and a task. We also have to use a combination of three entities to represent that stealing cash from the vault takes time, and if he’s still in the vault when the alarm goes off he will get arrested.
This business process model of a heist is more complex than it needs to be, but as simple as it can be using classical flowcharting techniques.
Using Intermediate Error Events
We can use BPMN intermediate error events to simplify the diagram, while describing the intent of the robber more explicitly. For people who were following BPMN when it was still a draft proposal, the error intermediate event is the updated name for the exception intermediate event. When you see references to ‘exception‘ in older documents, replace them with ‘error‘.
Interpreting the Intermediate Error Events
BPMN intermediate error events can be used in two ways – either as elements in the sequence flow of the process, or as boundary events attached to an activity. We have an example of each in this example.
An intermediate error event in the sequence flow (or normal flow) throws an error. An intermediate error event attached to the boundary of an activity catches an error. If the robber triggers the alarm (an optional path coming out of the gateway), it throws an error. The error may or may not get caught.
An intermediate error event attached to the boundary of an activity (either a task or a subprocess) will catch an error if that activity is being processed when the error is thrown. If the error is thrown after the activity has been completed, then it will not be caught.
Interpreting the BPMN Diagram of a Bank Robbery
Our robber will announce that he is robbing the bank, and by default will begin stealing cash from the vault (although he may not). He may or may not also follow the path of triggering the alarm. To put it another way, there are three possibilities for what happens in the gateway when the robber reaches it (after announcing that he is robbing the bank):
- The robber starts stealing cash from the vault without triggering the alarm.
- The robber triggers the alarm but does not start stealing cash from the vault (he panics and runs away).
- The robber starts both triggers the alarm and starts stealing cash from the vault.
The interesting thing about the parallel processes is that the relative timing of tasks on each thread is not specified. The robber could trigger the alarm before or after stealing the cash, or could trigger the alarm from inside the vault. This is where the intermediate events help us determine what happens.
If the robber triggers the alarm, an error is thrown by the intermediate error event in the sequence flow following the “Trigger Alarm” task. The only activity in the diagram that can catch the error is the “Steal Cash From Vault” task. Technically, the intermediate error event attached to the boundary of the activity catches the error (not the activity itself).
If the robber is currently in the vault when the alarm is triggered and the error is thrown, the boundary intermediate error event with catch the error and divert the flow. The current task (“Steal Cash From Vault”) will be interrupted, and the process will move to the “Get Arrested” task.
If the robber has completed the “Steal Cash From Vault” task when the error is thrown, he will not change his plans – he will still escape with the money.
If the robber triggers the alarm before starting the “Steal Cash From Vault” task, he would presumably elect to not try and steal the cash, but just run away. It isn’t clear (to me) what the BPMN standard would specify in this circumstance – if the error isn’t immediately caught, does it continue to exist until it is caught, or does it dissappear? Using this example, if the alarm is tripped first, and the robber still chooses to steal the cash from the bank, would the boundary intermediate error event catch the error (because it is still out there, waiting) and get the robber arrested? Or would the robber run away with the money?
In the absence of an answer to this question, we could insert a gateway immediately prior to the “Steal Cash From Vault” task, that makes the robber’s choice explicit – if the alarm has been triggered already, he runs away.
Benefits of the BPMN Approach
This business process modeling diagram has several benefits over the classical flowcharting approach.
- Using intermediate error events simplifies the representation of a task that takes a while but might be interrupted.
- The flow of the process (as drawn) is easier to visualize and understand.
- The “get arrested” branch of the process is clearly identified as an error and not just an alternative branch. This makes the desired process easier to distinguish from the contingency paths.
Summary
Using intermediate error events to throw and catch errors greatly simplifies the expression of real-world processes that have contingency plans. And most real-world processes do have backups, error-handling, and other forms of alternative flow.
