A post by Ken Swenson titled “BPM 2.0: no longer for Business Professionals” (http://kswenson.wordpress.com/2010/09/01/bpmn-2-0-no-longer-for-business-professionals/) contains the following interesting observation on BPMN
“Experience in the following 17 years convinces me that even though it is graphical, there is abstractness & formality that non-programmers find uncomfortable”
Ken’s post is a reaction to Jim Sinur’s post stating that BPMN is not suited for business users (http://blogs.gartner.com/jim_sinur/2010/08/30/bpmn-for-business-professionals-burn-baby-burn/) – a provocative short piece that was sure to create some noise.
While I agree with both Jim and Ken on the points they make, I would like to widen the scope beyond BPMN to process and logic representation in general, and add the key issue of how business exceptions are managed.
In Decision Management, getting the business analyst interactions right is at the core of what makes the effort a success or not. Without that piece in place, Decision Management efforts quickly degenerate in essentially slightly less rigid typical IT-managed processes. Carole-Ann has blogged about this earlier, and I have written something about it earlier too (http://architectguy.blogspot.com/2010/02/importance-of-business-analyst.html).
However, one key aspect that most logic representation efforts – including standardization efforts – forget is gracefully handling business exceptions.
Think about your typical form oriented or table oriented logic representation. They do a great work in presenting a very compact and business friendly view of the decision logic, but as soon as there is an exception to the logic in question, the business analyst is left with no real answer. The form is not enough – there is little chance the form designer anticipated the exceptions, and in years in this business, I’ve rarely seen it even considered. The table either is not enough, or quickly degenerates into something that is not manageable – frequently, it ends with lots of empty cells, forcing the user to “look” for the logic, and totally defeating its purpose.
This is not an academic problem. Business exceptions are not only an everyday occurrence in real life, they are also largely where a business can succeed or fail, where a business finds its differentiation.
I am certain vendors will tell me their respective representations solve the problem – but I have yet to see a systematic standardized approach that lets the business analyst work like he/she is used to and accommodates exceptions gracefully, with little degradation of the ability to do his/her work. In general, multi-representations help – but only to the extent that navigation through the logic is extremely well thought out, which is rare both in terms of design and in terms of tools support to implement it.
And we end in this: when the standard wants to be generic enough so that it covers most cases and gives flexibility for exceptions, it ends up being quite technical and out of reach of business users (as is the case for BPMN).
I do believe in the power of well targeted logic representations. The winners will be those that let the business users works as they usually do, including handling business exceptions in a graceful, non degraded way.
What do you think?
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
