Monday 30 June 2008

2 years of JRules

Recently I came across the an an article on the register "ILOG launches JRules 6.0" which was written around the same time I first started working with the product. This was around a couple of years ago, so I thought I'd share my thoughts about the product , ILOG and rules engines in general.

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.
Please let me know if you have any questions about Jrules or let me know about your experiences of using the product.

Further reading:

ILOG Lauches JRules 6
- The Register
ILOG White papers
Drools Documentation

5 comments:

  1. Hi,

    Thanks for taking the time to put this blog together. I found the information you presented to be very helpful, and it came along at a very opportune time.

    I am an IT consultant as well, and have been involved with a telecom company on the east coast of Canada.

    We just rolled out a Test Center of Excellence, where we are attempting to harvest reusable test artifacts for future use.

    We have implemented a continuous integration framework based on cruise control, and naturally, we have an interest in having all unit tests be integrated with our platform.

    My question is specifically around unit testing RuleSets. I have not had any formal training in JRules, and I have not had any time in front of the tools. We are trying to establish whether we need to (or should) invest in RSM. Rules Scenario Manager is advertised as a tool that will help manage Test Scenarios, in much the same way as our current Rational Test Manager. What is not clear to us is how Test Scenarios get created to begin with. We have had multiple sessions with the ILog people, but I still don't seem to have the facts that I need.

    My understanding right now, is that there is an API for the JRules engine. There is also an API for the RSM tool, that apparently lets you interface with the RSM tool from within JUnit. What is not clear to me, is how much capability is available to me, as a java developer, with JUnit skills, to write effective JRule unit test cases; assuming that we do not invest in RSM.

    In your experience, who (what role) writes the test cases for JRules? Business Analysts, Developers, both? Does RSM provide the ability for non technical BA's to write effective Test Cases against JRules? What tool is used to create the Test Scenarios(xml) themselves? I understand that the JRules Studio has some wizards for creating Test Scenarios.

    Any input that you can provide with regard to JRules unit and component testing would be great.

    Thanks again,

    Allan

    ReplyDelete
  2. Hi Allan,

    I don't have any experience of using RSM. But we were suppose to use it, but the ILOG consultants who came to set it up, didn't really know much about it either, so in the end we ended up creating our own custom component testing framework to test our rulesets.

    We also setup our own rules unit testing framework , where we would use dynamic rule selection to test a single rule.

    A technical developer would definately have to write this kind of unit test.

    I wouldn't recommend a business user within 10 miles of the actual business rules or any of the source code.

    ReplyDelete
  3. There should be also a way to package rulesets without running eclipse headless. Check my post in:

    https://www.ibm.com/developerworks/forums/thread.jspa?threadID=326281

    ReplyDelete
  4. Nice article, i appreciate for putting this together! "This is obviously one great post. Thanks for the valuable information and insights you have so provided here. Keep it up
    sports science dissertation ideas

    ReplyDelete
  5. I came across this post and I must say it really word by word describes my experience with JRules.

    ReplyDelete