Top 10 Reasons Why We Should Not Manage Business Rules or use Business Rule Engines
Here is a list of what I call "the usual suspects" - - These are the quotes that you will hear many IT People say when someone proposes the idea of using a rule engine instead of hard-coding or hard-wiring rules.
The Proposer sees the rule engine as a way to increase IT productivity, improve time to market, and reduce IT costs.
The "Old IT" People see the rule engine as a threat because it means they won't have to write as much code. Less code to write means less money to make.
The "New IT" People see the rule engine as an opportunity because it means they won't have to write as much code. This will give them more time to do more higher value-added work.
So listen up next time someone suggests using a rule engine in your company: See if you can tell from the response and feedback who gets the "New IT" of the 21st Century, and who is still stuck in the "Old IT" of the 20th Century?
10. "This is different." - - I agree, yes, traditional procedural applications are quite different from declarative rule-based applications
9. "This is not how we build traditional procedural-IT systems around here."
8. "This is not the way we hard-code or "hard-wire" our rules in our systems."
7. "If we use a rule engine, we may not need as many IT business analysts." - - This is a fact. Subject Matter Experts and other Business People may indeed be able to author the rules themselves, without IT Business Analysts
6. "And if we really learn how use this rule engine well, we may not need as many IT Programmers either..." - - This is a fact
7. It's not object oriented." - - This is wrong on multiple levels. First of all, object oriented programming systems evolved from A.I. and expert systems research labs. The earliest inference engines and expert systems were actually among the first (if not the first) computer programs that were truly object oriented. Remember SmallTalk?
6. "The inference engine will be too slow." - - This is wrong. This statement may be made by somebody who has experience working on expert system projects back in 1985. Everything was slow back then. Inferencing is a lot like thinking - It's hard work! Remember, PC's were running at 10 or 20 MHz back then. Inference engines run fine on my 3 GHZ PC in 2005.
5. "It'll never work." - - Some people just don't get it. They cannot deal with change. Lots of very smart people say things like that, and they turn out to be dead wrong. See Famous Quotes
4. "We tried that years ago, but it was too slow." - - See #6
3. "This rule engine adds one more layer for our programs to deal with." - - Technically, you may be right. However, did you stop to consider how many layers of legacy rule code you will be able to get rid of once the way you throw out all the spaghetti-code rules logic and put the rules in a rulebase (aka rule engine) instead? Getting rid of all that "hard-wiring" is probably going to eliminate about 23.5 layers of junk. So, yes, I agree with you on this one: Using the rule engine will add "one more layer". Let's call it the "business logic layer" or the "knowledge layer"
2. "Our rules are too complex for a rule engine." - - Every time I hear this claim, my jaw drops, then I go speechless. After a few seconds, I will explain the fact that the more complex your business rules are, the more you need a rule engine. This is usually the right moment to bring up the RETE algorithm and discuss how it scales and handles more rules without degrading.
1. "We'll just write our own rule engine." - - This is usually the last gasp. Once all the claims above are debated and proven false, this is the one that seems to come up last. At this point, even the IT People realize the way to go is a rule engine. But the first thought is "He's right, we need one... We need a rule engine... We need to build a rule engine." Right.... Let's see. How about a database analogy? What you are saying is that you should build your own rule engine, the same way that you should build your own relational database management system instead of buying Oracle or SQL Server or DB2. OK. I see your point....
Well, if you're that smart, you may be better off writing your own programming language as well. VB is too slow. And Java just adds one more layer.