When should you NOT use a Rules Engine?

Question

I have a pretty decent list of the advantages of using a Rules Engine, as well as some reasons to use them, what I need is a list of the cons of why you should NOT use a Rules Engine

The best I have so far is this: "Rules engines are not really intended to handle workflow or process executions nor are workflow engines or process management tools designed to do rules."

any other big reasons why you should not use them?

Answer 1

I thought Alex Papadimoulis's article was quite insightful: http://thedailywtf.com/articles/soft_coding.aspx

It's not comprehensive, but he's got some good points.

Answer 2

That's certainly a good start. The other thing with rules engines is that some things are well-understood, deterministic, and straight-forward. Payroll withholding is (or use to be) like that. You could express it as rules that would be resolved by a rules engine, but you could express the same rules as a fairly simple table of values.

So, workflow engines are good when you're expressing a longer-term process that will have persistent data. Rules engines can do a similar thing, but you have to do a lot of added complexity.

Rules engines are good when you have complicated knowledge bases and need search. Rules engines can resolve complicated issues, and can be adapted quickly to changing situations, but impose a lot of complexity on the base implementation.

Many decision algorithms are simple enough to express as a simple table-driven program without the complexity implied by a real rules engine.

Answer 3

The one poit I've noticed to be "the double edged sword" is:

placing the logic in hands of non technical staff

I've seen this work great, when you have one or two multidisciplinary geniuses on the non technical side, but I've also seen the lack of technicity leading to bloat, more bugs, and in general 4x the development/maintenance cost.

Thus you need to consider your user-base seriously.

Answer 4

I get very nervous when I see people using very large rule sets (e.g., on the order of thousands of rules in a single rule set). This often happens when the rules engine is a singleton sitting in the center of the enterprise in the hope that keeping rules DRY will make them accessible to many apps that require them. I would defy anyone to tell me that a Rete rules engine with that many rules is well-understood. I'm not aware of any tools that can check to ensure that conflicts don't exist.

I think partitioning rules sets to keep them small is a better option. Aspects can be a way to share a common rule set among many objects.

I prefer a simpler, more data driven approach wherever possible.

Answer 5

I blogged about it a while ago.

You can check it here -> http://www.codetoglory.com/?p=21

You should really use it when you have dynamic rules that change constantly like Insurance,trading, and foreign exchange domains.

Hope my blog article can give you some good overview.

Answer 6

In my experience, rules engines work best when the following are true:

1. Well-defined doctrine for your problem domain
2. High quality (preferably automated) data to help drive most of your inputs
3. Access to subject matter experts
4. Software developers with experience creating expert systems

If any of these four traits are missing, you still might find a rules engine works for you, but every time I've tried it with even 1 missing, I've run into trouble.

Answer 7

I will give 2 examples from personal experience where using a Rules Engine was a bad idea, maybe that will help:-

1. On a past project, I noticed that the rules files (the project used Drools) contained a lot of java code, including loops, functions etc. They were essentially java files masquerading as rules file. When I asked the architect on his reasoning for the design I was told that the "Rules were never intended to be maintained by business users".

Lesson: They are called "Business Rules" for a reason, do not use rules when you cannot design a system that can be easily maintained/understood by Business users.

1. Another case; The project used rules because requirements were poorly defined/understood and changed often. The development team's solution was to use rules extensively to avoid frequent code deploys.

Lesson: Requirements tend to change a lot during initial release changes and do not warrant usage of rules. Use rules when your business changes often (not requirements). Eg:- A software that does your taxes will change every year as taxation laws change and usage of rules is an excellent idea. Release 1.0 of an web app will change often as users identify new requirements but will stabilize over time. Do not use rules as an alternative to code deploy.