What and why?
Firstly, what on earth is a rules engine and why would anybody bother using one?The wikipedia definition says "A business rules engine is a software system that executes one or more business rules in a runtime production environment".
The way I see it , a rules engine is a bit of software which contains the business logic for a system , instead of it existing in source code. These rules can be viewed and maybe manipulated by business users .The users should not need to understand the technical implementation (i.e. be able to understand java code), but should be able to view and change the business rules through the rules engine interface.
The example in the JRules documentation is of some kind of retail/sales application where certain customers receive discounts dependant on various details. A business analyst for example can come in and create a new rule to give a 10% discount to a customer who orders over $100 worth of goods. They can do this through the interface and it gets deployed , without the business analyst touching a line of code or the entire application being rebuilt and deployed.
This is one of the main selling points of a rules engine, it makes things a lot cheaper to change an applications behavior. Also the business is not totally dependent on some developer who knows all the intricacies of the code.
My Project
So before I joined the project, some bright sparks decided a rules engine fitted the bill for what they were doing and they chose ILOG JRules over a rival product from Fair Isaac. I think they went with ILOG because of better performance stats when they did a crappy POC.
As I was on a "rules developer" , I used the rules studio which was a plugin to eclipse. As we were the first project to use version 6.0, which really should have been a beta version, the product was riddled with bugs. Also the ILOG consultants on the engagement had little or no experience with version 6 which was significantly different to the previous version which was a standalone application.
So my first impressions of the product and the ILOG guys weren't great. A lot of the problems were ironed out over time, but the ILOG guys were pretty rubbish in communicting any problems back to hq and we had to repetively badger them to get anything done.
Some bugs still haven't been fixed , and we're now on version 6.7 and we have had a whole suite of helper tools as workarounds. Also some features are pretty shit. The reports that can be generated from JRules are almost useless. They are basically screen dumps of the rules and there are no links between rules and where they are referenced in the flow of the rules. We actually developed our own application to produce some really useful reports, which to be honest should be out of the box functionality.
When working on any business application, it is vital that the the requirements are good. Also it is pretty important to have people around who really understand the business domain. These two things are even more important when using a rules engine. Actually I would go as far to say, that if the requirements are pants and you don't have the business users around, who in the end will be defining and analysing the rules, then don't bother going with a rules engine.
On our project we had neither. In the article from the register mentioned earlier, David Norfolk says "Rules processing systems need configuration management and testing just like any other automated system; applying the wrong rules, or the wrong set of overlapping rules with a combined behaviour you didn't anticipate, can become very expensive very quickly." This is pretty much what happened on our project.
Also ILOG provided no recommendations on config management, source control, or build and deployment setups. We have ended up with unique setup. For example JRules out of the box doesn't let you build a ruleset (the collection of rules pacakged up as a zip) from a script or in any automated way. We had to have a custom built plugin to run eclipse in headless mode to create rulesets from an ant script ( See my post "Building from the command line in JRules 6.7").
Performance became a big issue with JRules. But with a few tweaks we were able to push things to an acceptable level. I post up some of the things we did later on.
Rule Engines
Whatever my gripes are with JRules, I think rule engines are more than just a passing fad. The technology is relatively immature and as more people in the industry gain experience in using these products we will see some really good implementations. Rules engines also do seem to be a natural progression from high level languages as they bridge some of the gap between the techie and business user. I have heard good things about Drools and it could be one of those projects the open source community will take to. Also there are companies like Pegasystems who have been primarily working on business process managment solutions, but now their products are crossing over into the business rules space.
Some things to look out for if you go for JRules or any rules engine
- Requirements , requirements , requirements - make sure the requirements have been nailed and you have people around who actually understand them
- Spend time with the business analysts to develop a good business object model and good verbalisations for the model. This will make your rules readable, understanble, maintainable, and you will end up with an overall better result. One of the most frequent complaints by the business analysts was the the verbalisations were rubbish.
- Spend time on design - just because you're using a rules engine doesn't mean you can chuck everything in and expect it to do what you want
- If the ILOG consultants aren't playing ball, get them replaced early
- Setup a process to build, unit and component test early on
- Plan time for refactoring
- Make sure the business users are involved - they will be the ones who will need to work with what you develop
- Rules engines can't do everything, you still need good code built around it.
Further reading:
ILOG Lauches JRules 6 - The Register
ILOG White papers
Drools Documentation
