Home > Blogs > Why you should loosely couple processes and rules

Why you should loosely couple processes and rules

There is some debate about the value of loosely coupling business processes and business rules. Most of the objections, however, don't stand up to scrutiny.

  • 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. 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.
  • 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.
  • 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.
  • Doesn't loose coupling mean you have to 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.
  • Shouldn't the BPM and BRE be 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.

Become an InformIT Member

Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.