« What level of reuse does business rules deliver? | Main | Podcasting on SOA and decisioning »

In The Mustang Meets the Rhino: Scripting in Java 6 John Ferguson Smart discusses how JDK 1.6 / JSR-223 allows for the scripting of business rules. This made me think about the relative merits of scripting and business rules. Let's start by considering some of John's comments:

Scripting languages such as PHP, Ruby, JavaScript, Python (or Jython), and the like are widely used in many domains, and are popular because of their flexibility and simplicity. Scripts are interpreted, not compiled, so they can be easily run and tested from the command line. This tightens the coding/testing cycle, and increases developer productivity. They are generally dynamically typed, and have expressive syntaxes that allow an equivalent algorithm to be written much more concisely than in Java. They are also often fun to work with

Well perhaps. What about the total cost of ownership of a portfolio of systems developed this way? Scripts are hard to manage across the enterprise (they tend to be very local), hard to control, and so even if they make maintenance easier (by being easier to change and by being expressive), one has to wonder if they really help in terms of the overall maintenance burden for an organization (as distinct from the maintenance workload of an individual programmer). He goes on to give examples of when scripting is a useful approach:

providing extensions to your Java application so that users can write their own scripts to extend or customize the core functionalities. Scripting languages are both simpler to understand and easier to write, so they can be ideal to give (technical) end users the possibility to tailor your product to their needs.

But what about less technical ones? And how would you manage this extension process? What if it impacted an area of your business with tough compliance requirements - would the individual edits with scripts stand up to regulatory scrutiny?

Embedded JavaScript can be used for a variety of purposes. Since it is more flexible and easier to configure than hard-coded Java, it can often be used to code business rules that may change often.

Now we are at the meat of the problem - should I use scripting to implement business rules, because they are rapidly evolving or not? He goes on to give an example:

The following example illustrates the premium calculations for an imaginary insurance company. Any driver less than 25 years of age will pay 50% extra. If a driver over 25 has a no claims bonus, the company offers a 25% discount. Otherwise, the standard premiums will apply.
This rule could be implemented using a JavaScript expression as follows:

        ScriptEngineManager manager
                   = new ScriptEngineManager();
        ScriptEngine engine
                   = manager.getEngineByName("js");
        engine.put("age", 26);
        engine.put("noClaims", Boolean.TRUE);
        Object result = engine.eval(
            "if (age < 25){ " +
                        "    riskFactor = 1.5;" +
                        "} else if (noClaims) {" +
                        "    riskFactor = 0.75;" +
                        "} else {" +
                        "    riskFactor = 1.0;" +
                        "}");
        assertEquals(result,0.75);
    }

Well this certainly looks better than Java. But would it still look good if you had hundreds or thousands of such rules - typical for an insurer (see this case study for example)? How does it compare with a typical business rules management system's syntax (Blaze Advisor used here):

Customer's age = 26;
Customer's noClaims = TRUE;
aYoungDriver is any Customer where age <25;
if Customer is aYoungDriver then Customer's riskFactor=1.5;
if Customer is not aYoungDriver and Customer's noClaims = TRUE then Customer's riskFactor=0.75;
if Customer is not a YoungDriver and Customer's noClaims=FALSE then Customer's riskFactor=0.5;

This is only one way to implement it but not only is it clearer as is it would also allow templates to be created to make it even easier for business users to maintain these rules and the rules would be stored in a versioned repository. The use of an inferencing engine would ensure that the rules that were relevant were evaluated and not those that were not, improving performance when large numbers of rules were present.

So would I recommend using scripting for managing business rules and business decisions? Well, no. I would recommend using a business rules management system. It seems to me to have many of the key benefits of scripting with some additional ones:

• The separation of decision logic from mechanical implementation gives you more flexibility to make changes with minimal or zero impact on basic systems operation.
• The syntax is even more understandable to business-level people, leading to better business/technical cooperation, reduced implementation times, and fewer opportunities for interpretation errors.
• Business rules management systems have predefined rule replacement features to handle system updates without interrupting service to application users.
• Rule management templates can be created to let users update, view, or create rules in a controlled manner without knowing anything about syntax or code.
• The rule engine can quickly look through large sets of rules, finding the proper ones to apply based on case-specific conditions. No code is required to specify which logic should be fired in which order.
• Last and most importantly, rules are stored in a rule repository allowing them to be managed, shared, versioned and controlled.

Scripting tools have their place. Automating business rules and business decisions is not one of them.

Posted by jtaylor in Business Rules |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/256