Industry Observer: Rule Based Systems : Why use a rules engine

I have been working with Rule based systems for quite sometime and I have moved from a non-believer to a believer and now a business rules envangelist over the years.

Over the years I have been asked several times the question?

Why Do I need to spend $100,000 buying a rule based system ?

The arguments I get (and frankly the arguments I use to give 5 years ago) for not using a rule engine in a project included:

1. Why are we adding one more layer of complexity to the project ?
2. Most of the rules we have dont change so often then why do we need a rules engine ?
3. I can write rules in Java in a similar modular fashion as an off the shelf rules engine just by by definining a clearly defined interface and putting all the rules in a seperate package.
4. Why should I learn more language for writing rules.

Over the years I have relialized that there are broadly 4 categories people use Rule Engines.

1. Flexibility :
This is one of the biggest sales pitch from the tool vedors. They basically sell the idea of the ability to make changes to rules and not make code changes. They also sell the idea of making realtime rule changes and these changes taking effect immediately in production.

While this is a very important reason to buy the product. In my experience this is something that has been overemphasized and have not really seen getting used a lot. With the SDLC procedures in a lot of places requiring UAT before anything moves to production , this feature that does not get often used.

But their is still value in this and I have seen this working in some environments like .com or retail.

2. Seperation of Concern :

This is really a best practice in software development. It is always good to seperate concerns like Database interations , Logging , Rules , etc to seperate areas.

So the question that comes is : I can do this by structuring my rules in a seperate package and have a clearly defined interface for rules interactions. This is true and this can be done by having a diciplined approach in SDLC but when using a BRMS tool the dicipline comes from the top and gets enforced easily , this might not be the case when using pure java interfaces.

3. Centralized Rules repository and a visal interface (most modern BRMS give this) :
Having a central knowledge repository that details out every fine grained business rule is a dream for most IT organizations.

This is possible with todays BRMS tools like ILOG or Fair Issac. Both the tools have excellent visual cabilities. This feature in iteself will recover the full cost of the BRMS tools. But the word of caution is that just the tool will not lead to keeping all the rules in the BRMS tool. It requires diciplined project management to achieve this

4. Closing the Business IT GAP
This in my opinion is the most compelling reason to buy the tool. In my experience the biggest problems facing the IT organization is the ITness of it. i.e the business view's IT as rocket science and what IT engineers do is a black box . Having a tool like Ilog and Blaze removes the barrier between IT and business.

The business analyst now can view and play with rules that effect business and hence get very close to the implementation.

An Analogy : About a two decades ago , there was a very important profession of a steno person. Someone who would take dictation and then type it in print , there was also the notion of proof reading and that whole excersice was a highly skilled activity. As computers became popular and more user friendly , the job of the steno disappeared as the authors got a tool that was so easy to use that using it themselves was more efficient as compared to dictation and proof reading. The promise of BRMS tools is similar for IT

Fig 1