Rules or Code ????

Greetings:

Currently there is a bit of discussion on some of the developer groups as to, "Why not use scripting languages rather than a rulebase?" Good question and it deserves an answer.

One of the problems with rules is that those "outside" the rulebase community have little idea of what belongs in a rulebase and what does not. Nor do they have any idea of what constitutes a BRMS or a rulebase. So, before we run off and begin suggesting that folks use Java Script (or something equally mundane) to contain the rules, perhaps we should examine WHY we are developing a rulebase (and tacking a BRMS interface on top of it) in the first place. What follows will probably be elementary to most but maybe it will remind us of what it is that we are trying to accomplish.

A rulebase has been around since the late 1950's with Newell and Simon's Logic Theorist that preceded even the moniker of "AI". See https://www.rulelab.net/ for more discussion on this. A rulebase initially was to allow psychologists and programmers to try and solve a sticky problem when all of the rules were not known and so that there would not have to be a certain order of rule insertion into a program to be sure that one rule would not fire before another. They called this declarative programming and it is significantly different to all other languages such as BASIC, COBOL, Algol, FORTRAN, C, C++, Java and all of the scripting languages. They were trying to figure out how the brain works when is has a problem with conflicting rules and overriding rules and developed a system where the rulebase literally "chews" on the rules until there are no more rules to execute.

But, the question still remains, "What is a rule?" Or, as our business brethren put it, "What is a business rule?" More importantly, perhaps we should ask, "What is NOT a rule?" First, it is not data validation, even though I have used a rulebase (JRules) to do that very thing so that the business analysts could create, change and/or modify the rules without having to explain to the IT guys WHY this was true. (Shame on me for having been a party to such a venture but it paid the bills for 18 months.) I have a potential client now who has 10K+ so-called "rules" that are nothing more than data validation and they don't have any idea of what is a rule for a rulebase and what is a rule for Java/C++. No clue.

Another time that you should NOT use a rulebase is when you have to begin inserting more that three levels of priority. This alone indicates that the underlying problem is procedural in nature rather than declarative. I have seen so-called rulebased programs with as many a nine levels of priority. What this indicates is either ignorance on the part of the developer or lazy programming. This is much like the infamous "goto" statement in BASIC and other languages - yes, you CAN do it but it is NOT good programming. Just so with priority - use rule sets or rule flow (which I dearly hate but it seems to be a necessary evil) rather than so many levels of priority. (I prefer goal-oriented programming to rulesets but, in the end, it's pretty much the same thing.)

A BRMS, on the other hand, is nothing more than a cool interface and lots of toys to make the rulebase more appealing to the business guys. Remember them? The are the ones with the money who will buy our toys for us to solve their petty problems that could have been solved using any of the procedural languages. However, this does move 100% of the verification of the rulebase over into the business world where it belongs and allows the IT guys to go about their business of J2EE, database problems, web design and things of that nature.

But, and here's the crucial part: What is a valid case for using a rulebase? According to Girratano and Riley way back in 1998 (and they haven't changed much since then) the following are all guidelines for using a rulebase:

Can the problem be solved more effectively using conventional programming?
Is the domain well-bounded?
Is there a need and a desire for an expert system?
Is there at least one human expert who is willing to cooperate?
Can the expert explain his/her logic so that it is programmable?
Is the problem solution mainly heuristic or uncertain?

If these questions can not be answered, "Yes." (with the exception of the fist one) then probably you do not have a rulebase problem but rather a Java/C++/Scripting problem. If most can be answered, "Yes." then and one or two are "No." then you should carefully examine the potential hazards with using a rulebase.

You know, most businesses projects that I have had over the years, with a couple of notable exceptions, usually came straight out of the company manuals and NOT from domain experts. Who wrote the rules and WHY they wrote the rules was unknown for the most part. All the business guys usually know is that their competition is using a rulebased system for solving their problems and their business guys are getting to use a rulebase to do it so we have to do it as well. And the rationale that they use to justify such a solution is oftentimes amazing.

Whatever you do, have fun. You will have times when a client just insists on using a $1M+ rulebase to just keep track of rules that would be better suited to SQL or scripting. (Maybe their golfing buddy sells those things?) To keep your ethics in line, point out all of the obvious reasons for NOT using a rulebase and if the client insists on misusing a rulebase, take the money and run. :-)

SDG
jco