« Diamonds, decisions and processes | Main | Business users can (and should) maintain rules »

I saw this post last week by Jesper Joergensen - Can business processes and business rules be too loosely coupled? - in which he discusses one of Sandy's posts from the Forrester conference - Forrester Day 2: The three B’s. Jesper takes issue with Sandy's comment about the value of loosely coupling processes and decisions. Now I agree with Sandy on this so I thought I would address Jesper's points one at a time:

• How do you control where your changes to a business rule apply if it is only loosely coupled to your processes?
  Well you use decisions, and decision services, as I discussed last week. There is a difference between rules-driven decisions, which should be loosely coupled and rules used to control the process, which should not be. The difference is crucial as business decisions are, in fact, completely independent of the processes that use them and so must be loosely coupled while routing rules, for instance, are integral to the process and must not be.
• How do you know after the fact, which rule version was applied during which process execution?
  The same way you know, after the fact, what process version was applied. The decision logs which rules executed just like the process logs what steps were executed. The process should care what version of the decision was executed - the specific rules are relevant to the decision, not to the process.
• I am sure an insurance customer would prefer *not* to have the rules changed in mid-process, say affecting the price of the policy after you have agreed to purchase it.
  Well duh! The agreement to purchase it on the part of the customer would come after the underwriting decision was made. However, if the law changed while the process was waiting for a report, say, then the insurance company had better be sure that the underwriting decision was taken with the rules that were supposed to be in force then, not the ones in force when the process started! Again, the lack of a clear distinction between rules that are part of the process and those that drive business decisions accounts for the disagreement Jesper has.
• And how do I find out during an audit, which version of the pricing rule was applied to which customer on-boarding process?
  See above - by logging it, of course.
• There are two ways to solve this. You can provide an external governance mechanism that restricts certain changes to rules, or manages the correlations of different rule versions with process instances.
  Well you had better do this no matter what! Tightly coupled or not, the rules about how you treat customers, how you enforce regulations etc. had better be properly governed! As for coupling the process version and the decision version, why? The way I take a decision can change even if my process does not and the way I handle a process might change even though my core business decisions do not. I can change the pricing rules I use in my pricing decision without changing my order fulfillment process, for instance.
• Or even better, the BPM and BRE are sufficiently well-integrated to manage this for you.
  Integration is not the answer here. None of his issues would be solved by integration. Proper rule design, a proper logging approach, good governance etc are what's needed and they are needed if you smush your decisions into your processes or manage them properly.

• Decisioning in a loosely coupled process
• SOA, EDA and decisioning
• BPM in 2007 and beyond
• A BPMS is not enough to deliver agility
• Process transformation and decision management
• Business Rules, Business Decisions, Intelligent Processes, Enterprise Decision Management
• Decision Services

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/2366