Monday, January 12, 2009

Lots and lots a rules.... why not script it?

You can do a lot with rules - often way more then any one person would need. This often brings up the case of when you should or shouldn't use rules (as in drools) opposed to some simple (if large) sequence of "if statements".

This is not something you can answer in general, but what can be shown is that using drools don't have to be any worse then doing something similar as a sequence of if statements in a scripting language (or probably even java) for a reasonable number of rules.

To try this out, I wrote a script to generate 5000 randomised rules, which were of the useless and contrived form: "when p: Person(age > 40, age < 42, name =...." and so on...

So no inferencing, no higher order logic and such, but a few propositions. Really just no more then what you would do with an if statement.

For about 5000 rules I would typically get a result in less than 1ms.
Generating it as lots of if statements, it took around 5 or 6ms in jruby (just simple if statements - but the same logic) - so certainly a scripting approach is fast enough for that sort of sequential case (well its a few times slower, but if you get a response in less than 5ms, thats always pretty good I think !). What you don't get with the scripting approach is inferencing, higher order logic and much more (I am sure others can think up some other advantages).

So in summary: the features are there when you want them, but in really you don't pay a runtime speed penalty to not use them (and in some cases can get a benefit).


  1. Mic:

    One of the reasons that I used to give for NOT using a rulebased system was data validation. However, a client wanted to do just that so that their business analysts could do the rules using JRules. So they did and were quite happy to spend the US $30M or so to do it. Basically, it re-organized their business platform and saved them US $4M per month.

    When using a rulebased system and if the people entering the rules are the IT guys, then most so-called "business applications" of BRMS could be coded in C, C++, Java or even COBOL. Doesn't matter... But if the business analysts are involved the MAIN REASON for even using any kind of BRMS is so that the business analysts DON'T have to learn programming to use, enter and maintain the rules.

    You answered your questions perfectly. And it's what I have been saying for years: If the BA guys are doing the rules you have to have something like a BRMS. BUT, for ordinary, actual AI applications, then you have only a few instances where a rulebase is required: Usually when the solution requires complex coding and the answer is almost indefinable, such as diagnostic procedures (MYCIN), drug interactions, configuration problems (XCON?), psychological problems, plant maintenance schedules or shift scheduling, etc.

    Unfortunately, those few things aren't enough to pay the bills. So, we have BRMS (and extension of AI into the business world) that will pay the bills because it's the business guys in banks, insurance companies and finance companies who have the "real" money to spend on things like this.


  2. I would argue if you need more than 50 or so "IFs" to solve most any problem your code would be much easier to follow if you externalize it to a rulebase. As you approach 100s to 1000s of those "IFs" you would be insane not to want to use a rule engine. Debugging the base code, managing change on the fly, and the exposing of the logic to business users are also very important. We found the act of overriding the output generically because of using rules was one of our biggest benefits. While this is not a direct result of a RE, the fact we had disconnected, ID'd rules made this very easy to code and easy for the business to get.

    In our business speed of execution has only come into play a few times where we couldnt have solved the problem in a reasonable time without a RE, it many many times more often is the fact we have to change the rules very quickly, override the output of a rule, or simply want non-IT people to edit the logic in a way that wont break the underlying system.