Skip to main content
Why business rules? A curious reader asks..

I got a comment yesterday from Alexander asking some pithy and pertinent questions about business rules. Here then are my answers (somewhat delayed due to a machine crash wiping out the first version of the post).

Personally, I have nevery really understood the business rules movement.

Well that's why I'm here. Seriously, this is why I write the blog. I think business rules is an under-appreciated and under-exploited technology and it is my mission to convince people of this. Really.

So here goes with his actually statements/questions with my follow-up answers and links

Rules based languages and rules engines have been around for decades but they have never really taken off except for in small niche segments.

  • Well business rules engines have certainly been around for a decade. Before that I might consider that the market was generated by AI languages and expert systems.
  • The business rules market learned a lot from the expert systems experience, not least that to be useful there must be easy integration with enterprise applications. This is why most modern business rules products can manipulate .Net, Java or XML objects and deploy as web services, EJBs or whatever.
  • While it is true that business rules have thrived in certain niches, this is because those niches required business decisions to be automated. Business rules are a great way to automate decisions and so thrived in those niches. Indeed business rules work better than code for this because the separation gives you flexibility to make changes with minimal impact on basic systems, because business rules are more understandable to business-level people and because rule management lets users update rules in a controlled manner without knowing anything about syntax or code.
  • As the pressures on companies to act more quickly, across more channels, while enforcing more regulations and focusing more closely on individual customers, the need for more organizations to automate decisions will grow. As it does, the use of business rules will grow too.
  • The growth of the loosely coupled organization (described in The Only Sustainable Edge) forces decision automation also as it is not acceptable for an extended supply or demand chain to wait for a person to be available. That means computers are making business decisions and code is not a good way to automate those decisions.

I have never seen a convincing argument for why developers should stop coding business logic into applications in favour of using a business rules engine as general way of developing applications.

  • I don't believe that anyone suggests that a business rules engine is a good general way to develop applications.
  • Anyway, who builds applications any more? Haven't we all gone over to services?
  • It seems to me that there are lots of different kinds of services and that one of the categories is that of decision services.
  • It becomes particularly clear (to me anyway) why one would use business rules once you start thinking about the micro decisions your business takes all the time. If you really want to control decisions at that level, and increasingly you do, you need more tools in your toolkit and business rules should be one of them.
  • Building decision services with business rules, and so reducing the maintenance burden on those services going forward by empowering business users to do some of their own maintenance, frees up IT money for innovation and let's programmers stop doing maintenance and start doing something interesting. Given the amount of time a typical decision service will spend being changed, much greater than it will spend being developed, technology for developing decision services should set you up for "change time"
  • There are also a few problem domains where you simply must have inferencing such as that provided by the Rete algorithm (or updated versions of it like Rete III) but these are a minority of the decision-centric problems that rules work well for.

My experience with rules engines is that they are much more difficult to work with than procedural or object oriented languages are are almost impossible to debug.

  • Given a focus on the kinds of decisioning problems for which business rules work I don't think this is generally true
  • The testing and debugging tools for business rules management systems, at least good ones like Blaze Advisor and ILOG, are really sophisticated. They support stepping through rules, evaluating rule execution methods, watch and trace and all the usual stuff. More and more verification and validation tools are included and the recently announced Blaze Advisor 6.5, for instance, supports a version of jUnit for rules.
  • Even if some programmers find them harder, and I guess some do, business users absolutely do not. Business rules can boost business and IT collaboration and resolve one of the most pressing problems with programmers - how to find good technical skills with great business know-how.
  • Using business rules can also help you avoid write-only code.
  • In many cases the problem for code is that of management. When you have 10s or 100s of thousands of rules to implement, a business rules management system simply does a better job of impact analysis, traceability, logging and so on than code. With atomic rules everything from versioning to effective dates to auditing to reporting gets easier.

Hopefully this gives you all a sense of why I remain a business rules booster. Those who are still not convinced might enjoy my top 10 excuses for not automating decisions.

, , , , , , ,

related posts