Can Business Analysts Model Exception Handling?

[Preview of next week's BPMS Watch column on BPMInstitute.org]

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.  Drawn attached to the border of a process activity or subprocess, the semantics of BPMN say that when the event occurs, 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 the most critical part of your process, 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 surfaced 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 is “locked” until the transaction either commits or rolls back, business transactions are by definition “long-running” – lasting seconds to days, too long to lock the resources – which also means you can’t truly restore the initial state as if nothing ever happened. 

Instead, if an activity in the business transaction cannot complete successfully, already completed activities must be undone by their compensating activities, 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 the debit never 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 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.  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:

 (click to enlarge)

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 (with the rewind symbol inside) 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.  (If you don’t believe me, look here .)  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.

Tags: BPMN