A basic rule of technology is that you only get smart results from smart tools. One such "smart tool" is a business rule management system (BRMS) that takes business logic out of procedural code and puts it where it belongs: in the hands of business analysts. A BRMS can extract and isolate business rules from all of the other control code in an application, allowing business analysts to configure the rules (for discount pricing, loan interest rates, insurance premiums, and so on) using simple if-then-else statements and ordinary business language.
Exposing business logic in this way can yield amazing cost benefits. Rules-management systems are especially useful in industries such as banking, mortgage lending, insurance, and telecommunications, where the logic is complex, changes are frequent, and the rules are best left under the control of the business experts.
Of course, putting business rules in the hands of nonprogrammers doesn't take programmers off the hook. Indeed, the main benefit of a BRMS is that, by allowing them to share a rules language they both understand, it facilitates closer communication between the programmer and the analyst, making the job of each much easier. A good BRMS serves two masters, giving the programmer effective tools for creating the rule base and deploying applications, and giving analysts easy-to-use tools for building and changing rules.
For Java applications, ILOG's JRules 4.5 offers all of the bells and whistles that enterprise developers and business analysts require. Improvements from version 4.0, which was introduced in March 2002, include automatic code generation and point-and-click deployment for programmers, and friendlier rule-building tools for business analysts. Version 4.5 also performs better than 4.0, and provides the useful ability to configure role-based access privileges to rule sets and individual rules. (See sidebar, "How I Tested.")
JRules provides the richest set of tools I've seen in a BRMS. Only Blaze Advisor from Fair Isaac rivals JRules' ability to "expose business logic to daylight." OPSJ from Production Systems Technologies and Jess from Sandia National Laboratories deserve honorable mention, but JRules and Blaze are the only rules engines for the Java platform truly geared to enterprise use.
Rules and coding
The importance of developer tools for both programmers and business analysts cannot be overestimated. Nontechnical users must be able to determine that business rules have been written correctly. Over the lifetime of a rule-based application, these same business users must be able to modify rules to accommodate changing business processes. JRules has always provided a graphical user interface (GUI) that allows analysts to build rules and programmers to view the underlying code, but until version 4.0 the GUI wasn't very stable.
In version 4.5 the GUI is not only stable, but the Business Action Language (BAL), which the programmer uses to describe an application's objects, attributes, and methods in the lingua franca of the business user, now has all of the features of JRules' underlying rule language. With version 4.5, analysts can do anything in BAL that can be done in the less-accessible JRules syntax. Further, BAL can be extended to include words and phrases common to the industry and company.
Once the programmer configures the BAL, JRules' GUI allows business users to build rules simply by selecting canned phrases and logical operators from menus. When the rules are in place and the logic is fixed, variables—such as the percentage for a discount—can be changed with a click. In the end, instead of having to explain a business rule to a programmer in order to translate it into Java—if (order.numItems >= 2 and order.numItems <= 4)—the business analyst can express it in a form anyone can understand: "If the shopping cart contains between two and four items..."
At the same time, the GUI gives programmers access to the underlying Java objects, and allows either programmers or business users to debug rules. As with any standard debugger, it allows you to set and unset breakpoints or step through the rule. The only hurdle the GUI and BAL present is the time and effort it will take programmers and analysts to define how they want the plain English version of the rule base to appear.
Another helpful addition in JRules 4.5 is the expanded capabilities for rule flow analysis. Even though rules are incrementally independent, there is typically a certain "natural flow" of rules from one event to the other. Using the Rule Flow Editor allows the business user to graphically view this sequence of events. And if there is a correction to be made, then the user may simply drag and drop a rule into a new location.
Decision Tables, another new feature, allow business analysts to write a set of rules in a familiar spreadsheet format. The rules are generated from the spreadsheet and can be modified anytime and regenerated. Decision Tables should prove invaluable in some financial settings.
Programmers also get a number of handy new features. One is the ability to view Java objects in Unified Modeling Language (UML) format and to generate Java code from that model. JRules 4.5 also provides automatic code generation for Java 2 Platform, Enterprise Edition (J2EE), Java 2 Platform, Standard Edition (J2SE), and Web services, as well as point-and-click deployment for various scenarios, including the BEA WebLogic and IBM WebSphere J2EE servers. While many programmers hate code generators (Reason? Pride.), this is still a very good start toward building a system. You can always change the generated code.
Performance matters
When evaluating a rule-base engine, one of the first measures is performance. The most common benchmark is the Miss Manners test. In this test, 128 guests are invited for supper, and each may have one, two, or three hobbies. The idea is to seat boy-girl-boy-girl so that there is someone with a similar hobby on either side. When run properly, the guests and hobbies have already been determined, so the system can't cheat nor can the system rearrange the data for better performance. The data are arranged totally at random and may not be changed.
In firing all of the 8,513 rules in just over 100 seconds, JRules 4.5 proved to be about 7 percent faster than JRules 4.0 when I tested using J2SE 1.3.1_07. I also ran the tests using JRules 4.5 and J2SE 1.4.2 and got another 5 percent improvement. JRules 4.0 is not compatible with J2SE 1.4.2, so I could not compare performance on that JVM.
I also compared JRules 4.5 and JRules 4.0 performance using the Waltz test, a far more complicated benchmark that involves determining shapes, edges, and points of juncture. Again, JRules 4.5 ran slightly faster than JRules 4.0 when run using J2SE 1.3.1_07.
After implementing a rules engine, companies are often amazed to find that either their rules, as implemented in code, are wrong or that a great deal of their business logic is missing entirely. The typical mismatch between the goals of the business and the actual computer code in business applications is due to programmers not understanding the business logic and business analysts not understanding what is happening with the code. JRules 4.5 can help programmers and business people bridge the gap.