Columns

New Business Rules to Live By

• By Linda L. Briggs
• March 1, 2006

The need to comply with increasingly complex regulations, while struggling to maintain an enterprise’s momentum and agility, is pushing businesses to look harder at an old challenge: finding better ways to automate repetitive software processes, while allowing for variations.

Business rules management technologies, which separate the logic behind a business decision from the mechanics of carrying it out, simplify development and promise business users greater ability to manage changes to business processes.

A business rules engine gives the IT side specialized languages that allow developers to write simple logical statements about the business. “It turns out to be a lot less code because an engine interprets those statements,” essentially filling in the blanks, explains John Rymer, an analyst at Forrester Research. Instead of describing exactly how each request should be processed, as in Java, developers write statements. The BRE then decides which statements are relevant to each particular case. It’s still development work, but using a different development method and language.

The BRE market has matured over the past several years, and more companies are starting to take a serious look at enterprise-level BREs. Rising Sun That was the case with Sun Microsystems, which in 2004, began to consider replacing its numerous homegrown BRE systems with a commercial product. Sun’s componentized infrastructure (generally XML-based and Webservices oriented) was a major factor in their choice of Fair Isaac Blaze Advisor, says Rex Martin, lead architect for the BRE implementation. It is a Java-based rules management system, which Sun is using to evaluate a variety of complex, customerfacing implementations. Sun first used the BRE as part of risk analysis in its services area, where software analyzes a customer system to determine if a problem exists.

Today Sun uses Blaze Advisor to build rules services that range from simple to extremely complex. One simple set of services is a rule set built around a recommended set of software patches, says Martin. With the rule set, the patch set is self-aware and can maintain itself without human interaction.

A more complex set of services is a series of rules that draws on data from multiple data sources, such as patches, contracts and Sun’s customer account management system. With Blaze Advisor, Martin says, Sun can aggregate all the data, pull it forward, represent it to the rules service and provide a succinct view of a particular problem or customer. All that can be done without exposing each data source to developers or carrying the data sources forward to the customer in the service itself.

In some instances, the Blaze BRE’s ease-of-use has allowed Sun to use non-developers—knowledge engineers, as Sun calls them—for rules creation and maintenance. Initially, Sun planned to have developers write code as needed within the product’s IDE. However, the Fair Isaac consultants built the core rules service of the Blaze IDE. “We were able to [use] our knowledge engineers and get them working in the IDE to code rules, without having to get down into all the underlying layers,” Martin explains.

New focus on business rules
The BRE landscape is relatively small and fragmented. Along with Fair Isaac and ILOG, other companies that offer full-featured, enterprise BREs include Computer Associates, Pegasystems, Haley Systems, Yasu and Corticon. But doubledigit growth in 2005, along with several recent key acquisitions by bigger players, point to a growing market, with more mergers and acquisitions likely.

Competitive issues such as agility and regulatory compliance are fueling the market’s growth. “[Sarbanes-Oxley] is the tip of the iceberg,” Rymer says. A bigger issue is: When policies are embedded in apps as logic, any change—such as a new requirement or added compliance policy—means changes must be made anywhere that policy occurs. Changes like that are required often, so software maintenance becomes more costly, as does tracking changes to ensure they’ve been made correctly throughout the system.

Not only are software costs rising, but the risk of errors increases, a problem that top management must avoid more than ever because of SOX mandates. “If you can describe policies in one place and apply those policies to multiple applications,” Rymer says, “you’ve got a much better chance of consistent application of policies across groups. It’s huge, having [policies] all in one central location.”

Chris Robison, director of the agency technology group at UICI, a company that sells insurance products to the self-employed and to other markets, agrees with Rymer. Independent agents in the field meet with customers and use UICI’s salesforce automation software to prepare quotes on the spot. Since rolling out Haley BRMS, Robison says he now has “all the business rules for all of our products in one repository. And anyone can read that repository. That’s the biggest advantage.”

An equally important feature in Haley, Robison says, is it enables users to write business rules in plain English—albeit with strict syntax rules. To UICI, that capability offered the enticing potential of eventually having business people manage rules. The company considered other BRE products, Robison says, but because they were table-driven, “we knew it would always [require] a specialized skill set to manage the rules.” Instead, a product redesign this spring will eventually put the business side fully in charge of rules sometime later this year.

Good idea, painful process
Creating new rules may be getting easier with some of these products, but a big challenge at UICI and elsewhere involves gathering the business rules from multiple apps and documentation throughout the org.

“It can be a painful process,” Forrester’s Rymer says. “One issue is that a lot of businesses haven’t recorded what their policies are. It’s similar to issues we’ve seen with business process management. It’s a wonderful idea, but what if 90 percent of customers can’t describe their processes? Or if, when they do, they find that they’re broken?”

The process of collecting rules and policies from all over a company can be daunting. Sources might include printed and described accounting rules, rules embedded in running apps—including COBOL code on mainframes, printed compliance rules from the government, various banking regulations and on and on.

“That can be a problem with both BRE and BPM,” Rymer says. “What if your back-end data is a total mess, and you can’t really expose it? You’ll have to do some work first to pull it into shape.”

At UICI, Robison faced that challenge. “From the business rules side,” he says, “there was no single repository of business rules. Some were hard-coded in the legacy application, some were hard-coded in other applications that fed us data.”

Gathering rules, rather than entering them into the system, proved to be the bigger challenge. With Haley set up and the nomenclature established, “it’s as simple as typing a sentence,” Robison says. For example, “This health plan may not be sold to a person over the age of 60” or “If the deductible of the base plan is less than $2,000, then the rider on that base plan is not allowed.”

“If you set up the language right, it’s that simple,” Robison says. “Haley knows your dictionary, and there’s really no room for error.” As you write a rule, it tells you what word should come next from a list of words it’s expecting, he explains. Business rules also enable a different approach to programming.

With Haley BRMS, Robinson says, “You no longer have to make sure that you’ve coded a relationship between one object and another object.” With a car, for example, he explains, “You just need to pass four wheels objects into the car object, and it would know from that point on that those wheels are attached to the car, but you didn’t have to code that in your application.”

English-like coding
Robison’s comments highlight a challenge some software shops face when a company adopts a business rules engine: it changes how they program. The use of a rules engine at Catalyst International, a company that provides integrated supply chain solutions to Fortune 50 companies, has altered how developers there look at problems.

Catalyst has integrated ILOG JRules, a Java-based business rules management system, into several of its supply chain management products. In doing so, it’s created products that allow non-technical users at customer sites to make fairly complex changes to software processes.

Using a rules engine, according to product management VP, Noah Dixon, has changed the way he and his developers look at problems. “Instead of saying, ‘We’ve got to do this to a piece of code,’ we say, ‘What is it you want to say? Put it down into words…Then we can say, ‘Oh. [Just] expose that data and you’re done.’”

One Catalyst product uses ILOG as part of supply chain management software for slotting. Slotting means deciding where products should be placed in a warehouse for maximum efficiency, based on factors including demand, consumption trends, dimensions and weight. That sort of app can be complex, Dixon says, with giant customers managing tens of thousands of stores and products. In addition, there are huge variations in business rules from site to site—and daily changes in rules.

A typical Catalyst customer isn’t from IT, Dixon says, but someone focused on the facility’s operation—“definitely not a software engineer.” To provide a sufficiently flexible solution for users, Dixon says, his team of developers “positioned every crucial point in the decision-making process at an integration point with the [JRules] engine,” making each decision point available to business users as an English-like choice offered through drop-down menus. Users can select a statement and input parameters as needed.

By allowing business users to make the changes they need directly to the software, Catalyst has reduced dev costs. Dixon says the company is looking at additional apps for implementing JRules.

Rules without programmers' help
Managing a complex sales campaign is a task for BREs that is well suited for business people, removing developers from at least part of the process.

Java developers at electronic marketing firm BDR have used the BRE engine in JBoss Enterprise Middleware System to create tools that allow marketing departments to manage complex sales campaign lifecycles, according to John Clegg, product manager of eMessagePlus at myBDR.com.

The open-source pedigree behind the BRE called Drools was a key reason it was selected for building an integrated marketing tool for sales managers at BDR. Drools, a Rete-based engine written in Java, became part of JBoss last fall.

At BDR, a sales campaign is a series of messages delivered to select customers based on time or events. As customers respond, the program needs to make decisions throughout about what step to take next--when to stop delivering information to a group of customers, for example, based on an action taken, or when to send more information.

Using JBoss, Clegg's team of seven Java developers built a tool to allow business users to use rules to evaluate customer reactions and take a given action-- to extend the sales cycle, for example--without involving programmers.

Giving that sort of power to users, even savvy ones, presents challenges. "If you give non-technical users the ability to use declarations to change business logic within an application," Clegg says, "you have to be [careful] that you're not going to cause performance issues." To address that, Clegg put the rules engine behind a restrictive graphical user interface that allows the campaign managers to observe actions and use various drop-down menus to make decisions, but within limits.

The specialized languages in BREs can reduce the amount of code required, as well as make the maintenance of business processes easier. Eventually, users may be able to write and maintain business rules in ways beyond the examples here, but for for the time being, that's still what Forrester's Rymer calls "the new frontier." He contends that now most of the issues with BREs lie not with the tools and technology available, but with the readiness of organizations to adapt to building applications in new ways.