Original URL: http://www.theregister.co.uk/2006/03/31/ilog_rules_processing/

ILOG launches JRules 6

New industrial revolution

By David Norfolk

Posted in Developer, 31st March 2006 08:04 GMT

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.

But perhaps it is now time to revisit rules processing, if you've rejected it in the past as too limited, too specialised or too worrying. But you must still be realistic; remember we are at the start of something here, not yet looking at a fully mature development platform. Colleen McLintock, product manager for JRules, recognises the continuing issues and it is partly this realism that helps convince me that ILOG has something usable:

“One of the things we’ve done in promoting Business Rules is to sell this Business Agility story,” McLintock says. “In JRules 6 it’s a compelling story from a business perspective, so we focused on that on the marketing side, but the fact of the matter is, we’re a development organisation ourselves. So the bit you didn’t see a demo of is all the stuff you’re concerned about. The development environment integrates with standard source code control/configuration management systems – any [of these] that plug into Eclipse.”

But, doesn’t this imply that business users exploiting business agility will have to learn some of the tricks of real developers?

“Here’s how this works, and this is what’s new with JRules 6,” McLintock explains. “The IT side can synchronise the changes to rules; the business side can write the rules, change the rules, test the rules - but it can’t deploy the rules. From the developer’s workstation, the developer can pull the changes into the development environment, check them into source code control and configuration management and use standard software development practices….”

And, she points out, the JRules 6 Rules Scenario Manager assists with testing both the business side (helping people understand the impact of new rules on the business) and the logical – technical - correctness of the rules.

However, ILOG’s goal, she says, isn’t to re-invent the wheel on the IT side - we already have configuration management and testing tools which work well enough (although, perhaps, there may be scope for innovation in generating sanitised test data to fire rules in a controlled way) – but to focus on delivering business agility.

ILOG is not the only player in town. Fair Isaac , for instance, uses its rule engine as the foundation for a rich set of business applications around “Enterprise Decision Management”. Nevertheless, ILOG has synergies too: it claims that its optimisation technology is used to make its Rules Engine particularly efficient, and you don't really build Rules-based systems unless volumes are high.

ILOG also has visualisation technology and perhaps this highlights a possible omission from JRules 6 at the moment. It lacks an overall visualisation tool that could allow business stakeholders in rules processing to visualise accurately the overall effect of multiple overlapping rules (without oversimplifying things). But ILOG has the technology and experience needed for rules visualisation so perhaps McLintock is right when she says that this is simply a hard problem, albeit one that is being worked on.

And that rather sums up Business Rule Processing. Once you get beyond the basics, it’s not a trivial problem, but the expertise is out there. Rules interoperability standards are coming and developers, as well as business users, are becoming better supported. If you need to support automated business process in a regulated world, and who doesn’t, then you can’t afford to ignore Business Rules Processing these days. ®

Further reading:

ILOG’s White Papers on Business Rules are here.

Jess is a rule engine and scripting environment written in Java by Ernest Friedman-Hill at Sandia National Laboratories in Livermore, CA. This page on the Jess site provides an overview of JSR-000094, the Java Rule Engine API.

Read about Business Rules in the Semantic Web (from an OMG perspective).

What you need to know about business rules standards, according to Fair Isaac.