ILOG launches JRules 6

According to Pierre Haren, CEO of ILOG, we are at the start of a new “Industrial Revolution” - based on rules processing, an ILOG speciality, of course, together with Business Process Modelling.

The Business Rule Management System (BRMS) an ILOG specialisation, along with optimisation and visualisation, and the recently-launched JRules 6 claims to deliver real developer support and auditability across the entire business rules lifecycle.

What Haren means with his Industrial Revolution, I think, is that business rules bridge the gap between business process and IT. A business rule, essentially a decision table, is amenable to incorporation into an automated system based on pure logic; but it is also understandable to a business subject-matter expert, who can verify that it is correct.

Traceability from the rule expressed in business terms and the coded application it is embedded in or associated with then really helps you to demonstrate “IT governance” – or, more sensibly, business or corporate governance.

And, as Jean-Francois Abramatic, LOG’s chief product officer, will discuss, there are even potential applications of Rules in the provision of machine-to-machine communication, for the Semantic Web. This could be a start of a step change in the ubiquitous application of automation to business – if you believe that the gap between business process and automated systems is what is holding this up (and, to a large extent, I do).

According to Haren, rules processing a discussion topic in the Semantic Web community, with significant contributions from ILOG. A recent workshop bought together 70-80 people from the Semantic Web and Business Rules communities, people from very different origins, together in the same room: “The first day, there was not an agreement, and that’s OK” he says. But now, he continues, it has grown into one of the larger working groups in the W3C, working out the interoperability issues around rules and, in part, providing the meta-information, the rules of engagement, for machine-machine interactions.

But, you can’t exchange rules between different rules engines yet, although Abramatic is sure we're moving in the right direction – as well as the W2C initiatives, consider the OMG's work on Production Rule Representation (PRR) and related Business Process standards here; this should (like the W3C stuff, it is still a work in progress) enable you to explicitly represent production rules as visible, separate and primary model elements in UML models.

However, there are some real issues with this rosy picture, related to the development process for rules-based systems. Rules are immediately attractive and easy to understand but when you look at them in detail, you realise that a rules-based system can be similar to any other automated system in complexity and needs to be managed – as James Taylor of Fair Isaac points out with reference to the rules processing in BizTalk Server 2006.

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. eBay, for example runs Rules on over 2000 servers (serving some 450 million pages and over 10 million transactions daily) in order to detect and prevent fraud; and Tai Ping Insurance uses a 1000-Rule claims processing service to replace 2000 people. These systems can be business critical.

ILOG 6 appears to address many issues that may have limited the use of rules in the past. For example, it provides business-level simulation and testing tools (not just technical debugging support), such as Rules Scenario Manager; together with full-lifecycle rules management.

So what did the builders of rule-based systems do up to now? Keep things simple, I guess, by breaking up a task into manageable subtasks (and Haren suggests that you’d be unwise to have more than about 100 rules per task even now) and including a human in the loop when anything really important happens. This is still not a bad idea. As Haren says, even with 100 rules, “unless there is a natural structure to what you have, 100 rules all trying to do something different is a single box is a little complex”. Just as with conventional programming, rules-based systems must be properly designed and architected.