What are the myths about rules engine? [closed]

Question

I'm writing a presentation about rule engine technology, specifically JBoss Drools.

What are some of the 'myths' about rule engines.

One I can think of is that it allows business users to control the rule engine, I believe it is possible, but it requires control and education - and not all business users are able to do it.

Do you agree/disagree? Does anybody else have any thoughts?

Happy to release my final 'findings' under Creative Commons...

Execution

Thanks guys, I can't mark both questions as right annoyingly. So random selection made. – Execution

Answer 1

I don't know about myths, but I agree that having business people maintain rules is not a slam dunk.

I think expecting business folks to have the patience and anal retentive attention to detail required to do IT's job is a fantasy. It's been in play ever since 3G languages (graphical approaches to programming) have been offered as a way to get secretaries to write code so the programmers could all be fired.

I'd point out that as the size of the rule set increases, the possibility of ensuring that it's correct and self-consistent goes down. If your rules set has thousands of rules it'll be hard to test.

Speaking of which, combinatorial explosion of combinations will make it hard to test a rules engine.

Rules engines are terrific technology, but be careful.

Officeholder

I tend to agree, but my experience is limited to interfacing two cases of fraud detection applications. As there is an opposite opinion in @Nim answer about the feasibility of end users to control the whole thing, I asked him for sharing some detail. As powerful as the technology is, having the IT staff to maintain the rules is (I think) the same kind of issue that prevented the use of "expert system" environments to be mainstream in the past. – Euratom

Expert systems might have been limited by the inability of the business to maintain rule sets, but I'd say the bigger issues were the limitations of the technology and the hardware it ran on. Demos that selected wines were one thing; replacing a master machinist is quite another. – Officeholder

In other words, rules engines are terrific technology, but they are still technology. – Nitid

Artificial intelligence still has a ways to go before it matches human intelligence. We haven't reached Kurzweil's singularity yet. – Officeholder

Answer 2

Actually, having used drools heavily, I disagree with you on your point about users having the ability to do stuff easily, I think it's relatively trivial to provide users with a simple interface to generate powerful rules dynamically.

One I would definitely add to the list is:

Myth: Rules engines are slow!

Not so, again, I've pushed even thousands of events per second through drools quite easily.

Another which I absolutely loathed was:

Myth: It's too heavy weight and complex to use.

Nonsense, the syntax is trivial and with a few lines of java, you can do some really funky stuff! Sorry if this appears to be a rant, had months of this crap at a previous employer as I wad trying to introduce this tech!

Abercrombie

Sounds interesting ... could you provide some insight or details of your/ your team accomplishments in providing "users with a simple interface to generate powerful rules dynamically"? I saw just two relatively big applications, but both failed to do this. – Euratom

Let me put some context here, I actually cheated, what I realised was that, for what we were doing, it wasn't the rules I had to modify, all I had to do was to convert the user input into "facts" for the rules engine, which when combined with other inputs and a very limited set of rules - did exactly what we wanted. I created some UIs (swing) based, which presented users with wizard like interfaces to generate rules and this seemed to work okay for what we wanted, but then the key thing is scope, I intentionally made it pretty restrictive. In the end, as I mentioned, I changed tack... – Abercrombie

...and converted the user input into facts rather than rules, and as a result my rulebase was quite small.. My other two points still stand though! :) And I think this is one of the neat things with something like Drools, it's very adaptible... (as you can clearly see, I'm biased towards it! :) ) We had working group on CEP at my previous company and I saw a few implementations that had success with generating rules via Excel input - the input was from people in the Operations teams - i.e. non technical, again thought the common theme was the restrictive scope... btw. apologies I can't... – Abercrombie

... go into too much implementation detail other than to mention the approach I took... I'd also be very much interested in what you'd produce... – Abercrombie

@Abercrombie - If Drools is so easy to learn then why are those books about Drools so massive? Is it like chess, a day to learn and a lifetime to master? – Ly

Answer 3

Myths...
1/ Business users can:
author rules
deploy them
test them
run them
Whithout the help of IT... I have delivered a training for a client who was actually thinking that it was true because the salesman said so... ah ah ah they made my day/mounth/year !!!

Can you seriously think about a company who will take the risk to deploy a service in the back of the IT team?? no way!
You need security as well to prevent me writing a rule stating:
if the name of the client is "Damien" then 100% discount - groovy baby!

The architecture of a project cannot be done by non-technical users

2/ You can manage rule project easily without having to worry about anything.
There is limit of number of rules you can deal with. In theory one could have as many rules as they want but this is not entirely correct. JRules stop synchronizing rules between Eclipse and RTS from around 3,000 rules. It will take forever if you have a project with 100,000 rules all in RETE. Building the tree will take a long time. Even in Sequential mode it takes a long time to proceed.
You cannot use a rule repository like the folder "My Documents" and just keep on adding rules.

3/ Business users can write all kind of rules without any training.
Different things:
a/ order of conditions may impact performance.
b/ some rules are complex and need a good understanding of the language
c/ the algorithm used can impact the result of the execution
d/ a single badly written rule can multiply the execution time by n.
I worked on a project where only 1 rule was responsible for some random timeouts.
e/ Some complex problem can be express in one rule.
This problem is solve in one rule and has one result:
There are four Golfers standing at a tea, in a line from left to right.
- The golfer to the Fred’s immediate right is wearing blue pants
- Joe is second in line
- Bob is wearing plaid pants
- Tom isn’t in position one or four, and he isn’t wearing the orange pants
BTW: This is an JBoss example.
How can a business user do this?

4/ Rule engine can do backward chaining
I think JBoss say they can but I am not sure about this. Blaze and JRules cannot.

5/ One doesn't need any programme language to write rules.
Correct, but you will need some to execute the rules. Except if you are using a simple XSD as Object Model. But your Decision Service will not do that much clever thing.

6/ It is slower than JAVA
Of course but by using BRMS you are externalizing the business logic so it has a cost.
Exactly like when you externalize data. The database call has a cost.
I have sent 5,000 objects into the working memory of JRules with a project containing 4 dummy rules which were calling each other... Performance test purpose
Result: 19 Millions rules executed in 75 seconds. Do your maths... it is not that slow.

7/ You can do anything in a rule
Do not make database call in a rule (especially in the conditions). Using Rete, in theory, a rule could "test" the condition to find matching result in the memory thousands of time.
No one want to call a database that much in an application.

Hope it helps

Salina