Q&A: ILog CEO Pierre Harren

Many business process management (BPM) suites are said to support rules. So why would you need a separate business rules management system (BRMS)?

There are two ways to use rules in a BPM environment. One way, which is the way everybody talks about, is to use rules for simple process-control flow--"if it's a Gold customer, take this route and if it's a Silver customer, take that route." As these points multiply into something complex, you need business rules.

The second way to use rules--and the one that is much more important and widespread, but less talked about--is to create a transparent decision service. BPM is all about linking services that are done by mainframes, by pieces of code or by business rules services. The advantage of a business rules service is that it can be safely modified by business users and it is readable. If you double-click on it, you can see what's going on, as opposed to clicking on a piece of Java code, which business users can't read.

There is still confusion between control-flow requirements and decision services that can be written in understandable business rules and choreographed though a composite app or BPM.

So when do you need human-understandable rules managed by a BRMS?

You could write almost any code within a BPM environment, but when the requirements become very detailed, you're trying to accomplish something in a visual environment that is better expressed in sentences. And when you have a lot of rules in parallel, the visual approach totally breaks down.

The most obvious gauge is the level of complexity. If you drop below 50 rules in a particular application you enter a gray zone. If it's fewer than 10 rules, you could probably handle that with Java, but I'm certain that if you ask a good Java programmer and a good rules programmer to create the same thing with 50 rules or more, the rules programmer will be done much sooner and on-going maintenance costs will be much reduced because it can be handled by business users. When you consider apps that require as many as 500 rules, you have almost no choice other than a rules engine.

Rules engines have long been used for credit scoring and fraud detection, but what new applications are emerging?

The uses are getting broader. For example, the national freight railway in France uses SAP, but it has some 5,000 customers, each with a different contract. They wrote the contracts as rules, and for every transportation event, SAP calls a service written with rules that calculates the billing.

The cost of integrating a new rule service has gone down tremendously in SOA and BPM environments. In large implementations, business rules are pervasive because the cost of building those services has dropped dramatically, and you have the ability to create a rule module that basically replaces code--with the advantage of being readable and business-user maintained. We're getting to the point where building a business rule service is actually faster than describing that service; if you can specify it, you're done.

Outtakes

What's your hobby? I love paragliding, and for the last 13 years I have consistently flown about 20 hours per year, in France, California, Hawaii and elsewhere. Favorite travel destination? About once a year I travel to a remote part of Senegal, in West Africa, called Casamance. If you look for Cap Skirring or Ziguinchor using Google Earth, you'll see beautiful examples of the nature-driven mangrove fractals.