It’s conventional wisdom in business that 80% of the problems are caused by 20% of the work – the “exceptions.” In BPM, therefore, you’d think that exception handling would be a critical focus of process modeling and analysis. In most cases you’d be wrong.
Certainly the designers of the Business Process Modeling Notation (BPMN) standard at BPMI (now part of OMG) had exception handling in mind from the start. BPMN introduces to process modeling the notion of intermediate events. It’s a godawful name but an absolutely essential concept for making exception handling visible in the process diagram and understandable to business people. In fact, events are the key difference between BPMN and traditional flowcharting.
In BPMN, intermediate events are drawn as circles with a double border, with a symbol inside denoting the type of event: receipt of an external signal (message), a timeout, a system fault, etc. When drawn attached to the border of a process activity or subprocess, the semantics of BPMN say that the activity or subprocess is interrupted immediately, and the process continues along the flow path leading out from the intermediate event. That path is called “exception flow.” If the event never occurs, the activity or subprocess completes normally and processing continues along the flow path leading out from it. That path is called “normal flow.” Is that hard to understand? No, I didn’t think so.
You’d be surprised, then, to know that a number of modeling tools offered by BPMS vendors that advertise themselves as BPMN-compliant don’t support intermediate events. What those vendors usually say is that the concept is too technical for business analysts to understand. What they really mean, in most cases, is that their process engine – the thing that “executes” the model to automate and monitor the process flow – can’t handle them. The modeling tool’s simulation engine has no idea what to do with them, either. So they’re just left out of the tool. Shame on OMG for allowing this pseudo-BPMN to proliferate as it has.
The traditional alternative to modeling exception handling explicitly in the process diagram is to do it in code, toss it over the wall to IT. Once in a while this might be necessary, but as a general principle it’s just plain wrong. By removing exception handling from the process model and burying it in implementation code, you’ve not only lost visibility into what’s going on, you’ve lost the ability to use it in simulation analysis, you’ve lost agility, reuse, shared best practices, etc. All of those assume exception handling is in the process model.
In addition to intermediate events, BPMN adds another important notion to the process modeler’s vocabulary: business transactions. A transaction here means a collection of activities that must be performed “atomically” – all must complete successfully – or else the system must be “rolled back” to its initial state, as if none of them had ever occurred. Unlike classic transaction protocols like two-phase commit, where the resource performing each part of the transaction must be “locked” until the transaction either commits or rolls back, business transactions are by definition “long-running” – seconds to days – too long to lock the resources, which also means you can’t really roll back to the initial state.
Instead, if any activity in the business transaction cannot complete successfully, any already completed activity must be undone by a compensating activity and any uncompleted activities in the transaction are abandoned. Undoing a debit, for example, might be issuing a credit for the same amount. It’s not a rollback as if neither had happened – both the charge and the credit show up on your Visa bill – but it has equivalent business effect.
Here’s a scenario. You’re booking a trip to Europe online, air and hotel. Neither the airline nor the hotel can guarantee either price or availability until you actually book specific dates with a credit card. Yes, it’s a nasty world we live in. But if you can’t match the dates of both hotel and air, you’re reservation isn’t much good. So consider them part of a single business transaction. Let’s even imagine that you first select your preferred complete itinerary (hotel and air) and then instruct the travel site to book it. Let’s assume the travel site models this as a BPMN business transaction, first booking the hotel (no cancellation fee) and then the air (no avoiding the cancellation fee). The BPMN might look like this:
The subprocess enclosing Book Hotel and Book Air acts as a business transaction. If the hotel is unavailable, the subprocess completes without booking the air. But if the hotel is available, it is booked with a deposit on the credit card. If the air is not available, the subprocess completes with a compensation end event – a call to completed activities to execute their defined compensation activity. For the Book Hotel activity, the compensation activity Cancel Hotel (with compensating credit for the deposit) is identified by its link to the compensation intermediate event on the boundary of Book Hotel. The explanation may be long-winded, but the diagram is concise and explicit.
This is about business semantics, not programming. Business analysts can understand intermediate events, exception flows, and compensation. The problem to date has been a lack of quality training on BPMN supported by a clear methodology for translating process knowledge into diagram correctly. The current state of market education on BPMN is really quite appalling. That’s why I’m putting together my own training materials on Process Modeling with BPMN. Exception handling is too important to be tossed over the wall to the programmers. Real training and a methodology can give process analysts the tools they need to define how exceptions should be handled in their critical business processes.
