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

Blogs on top of Blogs

Well, my buddy Mark Proctor has been really busy blogging about ruleflow and (slight oblique reference to Drools documentation on that subject) work flow and how the two things make it easier for business guys to state their problem. I agree with the ruleflow documentation in that a ruleflow is only PART of the overall solution. So, where's the catch?

If you give a man a fish, he will eat today. If you teach him how to fish, he'll never go back to work. OK, bad analogy. How about having a hammer and everything looks like a nail? If you give business people spreadsheets - what we call decision tables but it's still a spreadsheet to them - or a ruleflow - what looks like a typical workflow engine to them - then THAT'S what they will do (and only that) because it is very familiar and it just "feels right". What can I say? We gave them the gun, they shot themselves in the foot with it, and then we blame them for doing it. And we, the rulebase community, claim that we told them the right way to do and that they just messed it up.

OK, all of the above is procedural programming. You can't get around it. It's just another way to do Java or C++ or COBOL or VB or C# or whatever else procedural language is being used. And that is NOT a rulebase because a rulebase is, primarily, declarative programming. Why, oh WHY can't we, the guys who are supposed to know better, still pushing decision tables, decision trees and ruleflow as answers to complex problems. It probably IS an answer to a specific business problem, but not all problems can be solved that way - which is why we invented a rulebase in the beginning; to solve complex problems that defy conventional, procedural programming.

Bottom line? Don't use a hammer when a screw driver is better suited for that purpose. Sure, the hammer will work to drive a screw into a wall, but it won't hold up very long. A screw will work better. (Don't get snarky on me - sometimes a screw is just a screw and not anything sexual.) And PLEASE do say that I'm against ruleflow, decision tables, decision trees, work flow, etc. I'm not. But a rulebase project just HAS to have it boundaries and applications just like any other tool. Use it properly or it will backfire and kill you.

OK, maybe it's off the subject of what Mark was originally trying to write about. But we just HAVE to draw the line somewhere and it's up to me, Mark, Peter, Dr. Forgy, Haley, ILOG, Fair Isaac, etc., etc., to start drawing and try to write "quality" business - projects that have a chance of being extensible, expandable, and all of the other "-able" handles. BTW, here are the links to Marks stuff so you can read it for yourself. You might start with the first two. The others are along the same lines.

The blog link
http://blog.athico.com/2007/11/vision-for-unified-rules-and-processes.html

The Drools documentation
http://docs.jboss.com/jbpm/pvm/

Another blog on same subject
http://www.dzone.com/links/a_vision_for_unified_rules_and_processes.html

And yet one more - pretty much the same thing in a different wrapper
http://digg.com/software/A_Vision_for_Unified_Rules_and_Processes

SDG
Yaakov