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
Posts
Who stole my spring??
-
After a nice 20C degrees day yesterday, I woke up this morning to this:
10 years ago
5 comments:
When a customer is dead set on using a BRMS when they shouldn't, there's very little one can do. Here's my bias take on when to use or not. my criteria is a bit different.
1. who is the best person to author those rules. If it's business user or business analyst, I consider it business a "likely" candidate.
2. does the business need to audit and report on the rules? if it does, coding it in java/csharp/C++ isn't acceptable in my mind. A BRMS implemented properly makes it much easier to audit the business rules. this is especially true of government regulations.
3. would hand coding the rules product garbage? in some situations, the business logic may be so complex that any attempt to code the entire thing by hand becomes impossible and unmaintainable. In those situations, a rule engine is needed. the rule engine may be a simple home grown one, or a commercial BRE.
4. is the application a real-time system? if it is and there's thousands of rules, hand coding it just isn't going to cut it. 90% of the developers out there don't know how to write good compilers or optimal pattern matchers. very few people have the skill and experience needed to build a high performance rule engine for those types of high performance use cases. from my first hand experience, I would say it's less than 40 people on the entire planet.
5. is the use case and functional requirements simple enough that anything would work. if that's the case, I tend to avoid a BRE and BRMS completely.
6. are the developers capable of understanding the tool and does the schedule take it into account? Even if the business really needs a BRE and BRMS, if they don't have the right staff, there's no point using BRE/BRMS.
I can add a new thought on this. Many business apps need to define rules like premimum rules, payment rules etc. These are currently stored in the database and bespoke UI's made to manage these.
If these are stored in a rules engine with a good BRMS, it can save the company the effort to create the managment screens while providing business a lot more flexibility.
Peter:
Good points all. Basic rule architecture 101 but still good points. I would think that your points could be summarized by the situation dictates what you should and should not do.
Vikrant:
Unfortunately, some businesses today STILL want to write their own GUI screens. They get good mileage out of this by NOT having to train he business analysts on how to use rules. If the BA already knows the logic, they just write it into the BRMS using the lingua franca of their particular industry.
Thanks to both for your comments. :-)
SDG
jco
Hi, I have been reading some of your articals and I am wondering what is your opinion on responsibility. Who is realy responsible for maintaining and managing business rules? Is it BA and IT guys just provide the platform?
Jakub
Jakub:
Who maintains the rules depends on the setup. I have seen situations where the business analysts (BAs) gave the logic to technical guys (IT) and the IT guys were responsible. In more than 50% of the cases, and especially when using a decent GUI to enable them, the BAs author and maintain the rules with the help and guidance of the IT guys.
My personal feelings are that the IT guys (who rarely know little more than the BAs about rulebased systems) would architect and maintain the Web apps, the database and any objects (C/C++, C#, Java, whatever) needed to run the rules while the BAs authored and maintained the rules.
BUT, here's the main problem. Both WANT to keep their "power" over the rules when neither of them wants to train and study and understand rulebased systems. A proper understanding of declarative programming is absolutely necessary in an enterprise environment where there are thousands of rules and objects to maintain. While the BAs are the ones who "should" be doing this, they rarely have the discipline nor the training for proper IT infrastructure. And the IT guys rarely have the business knowledge to author and/or maintain the rules.
Solution? TRAIN both departments in declarative programming and have the rule team composed of IT and BAs working together for a solution to a complex problem.
SDG
jco
Post a Comment