Our system (exotic commodity derivative trade capture and risk management) is being redeveloped shortly. One proposal that I have heard is that a rule engine will be incorporated to make it easier for the end-users (commodities traders, so fairly sophisticated) to make certain changes to the business logic.
I am a little skeptical of rules engines. The agilist in me wonders if they are just a technical solution to a process problem… ie. it takes too long for our developers to respond to the business’s need for change. The solution to that problem should be a more collaborative approach to development, better test coverage, more agile practices all around.
Hearing about situations where a rule engine was truly a boon (especially in a trading environment) would be certainly helpful.
I’ve seen two applications that used the Blaze Rete engine from Fair Issac.
One application slammed thousands of rules into a single knowledge base, had terrible memory problems, has become a black box that few understand. I would not call that a success, but it is running in production.
Another application used decision trees to represent on the order of hundreds of questions on a medical form to disposition clients. It was done so elegantly that business people can update the rules as needed, without having to involve a developer. (Still has to be deployed by one, though.) I’d call that a great success.
So it depends on how well focused the problem is, the size of the rule set, the knowledge of the developers. My prejudice is that simply making a rules engine a single point of failure and dumping rules into it probably isn’t a good approach. I’d start with a data-driven or table-driven approach and grow that until a rules engine was needed. I’d also strive to encapsulate the rules engine as part of the behavior of an object. I’d hide the rules engine from users and try to partition the rules space into the domain model.