≡ Menu

Here’s how you know you need business rules


Jim Sinur asked (and answered) a similar question on this blog recently – Do I Really Need a Business Rule Capability? Now I generally talk about Decision Services as the driver for business rules – services that answer business questions for other services – so how can you tell that a service is ideal for automation using business rules? Well there are perhaps four classic reasons:

  • The service requires lots of “rules” to be considered for each decision.
    Managing large numbers of rules in code is typically very difficult but a business rules management system handles this much better.
  • The service has very complex, inter-dependent rules.
    Inferencing business rules engine, those that can use an algorithm to establish which rules to evaluate and those that have powerful syntax constructs can really take the sting out of developing this kind of service.
  • The service’s behavior must changes all the time.
    Constant maintenance of code to respond to changing promotions, regulations, competitors pricing etc is costly and time consuming. Using business rules to automate these kinds of services can dramatically decrease the cost of ownership for these services both by making it easier for non-technical folks to make controlled changes and by making it easier to change rules on the fly without destabilizing the service.
  • The service has rules that require business expertise to understand.
    If the rules in a service are hard to understand without a strong background in the business context then it will be hard for programmers to code them correctly. Empowering the business experts to interact more directly the service by automating it in business rules can eliminate or at least dramatically reduce these issues.
  • The service is one that business users insist on controlling.
    Sometimes a group of business users simply insist in having control of the behavior of a particular service. Perhaps the service is replacing something the business users built themselves in Excel or Access and they have become accustomed to controlling it. Perhaps they have heard from colleagues or peers. Regardless, this can be a driver for decision services and business rules, though hopefully one of the other criteria will also be true!

Decision Services are easy to find in most processes and thinking of these business services this way will make it easier to develop and maintain them and much more possible to engage the business in their development. Using a business rules management system is a great way to build these kinds of services.


Comments on this entry are closed.

  • Greg Glockner May 14, 2009, 7:25 pm

    I agree that the first three points are good justifications for a business rules system.  I have issues with the fourth point.  The vendors hype that “the business person can code the rules” but this is more of a fantasy.  It is rare to find someone who is not an engineer but is willing and capable of editing and maintaining the production-level business rules. Writing business rules may be easier than traditional programming, but this is still a programming task. Otherwise we wind up with the same kind of flawed logic that we see in spreadsheets; academics have shown how often spreadsheets have fatal flaws despite the firm believe that they are correct.

    The fifth point (of your four?) is fine so long as we understand the rule writer is still an engineer.

  • Vijay Narayanan May 15, 2009, 5:47 pm

    I think business rule automation via decision service is also relevant for decomposing business logic/rules embedded in legacy systems. Many a time the business is afraid (read risk averse) about touching legacy systems because the business rules are not explicit and not enough transparency exists in order for code to be modified to accommodate new business requirements

  • James Taylor May 18, 2009, 5:12 pm

    In fact business people can code the rules, provided that the right infrastructure is in place. It’s true that they still can’t really just go code the decisions themselves (nor do they want to) but they can and are put in a position to maintain, add, remove and change the rules in the decisions. It takes more than just exposing the logic as rules, though, as I have noted before.

    Check out this post https://jtonedm.com/2009/05/18/more-on-business-rules-in-legacy-modernization/ for some of my thoughts on this!