A basic law of technology is that you only get smart results from smart tools when they’re used by smart people. Your developers may be great at writing code, but you don’t want them making ill-informed decisions about business rules. By the same token, business analysts should focus on what they do best rather than trying to translate business decisions into excruciatingly detailed requirements documents.
A BRMS (business rules management system) can bridge the chasm between business and IT by giving control of the logic -- and even the code -- to business analysts. That heretical idea presupposes a fundamentally different approach to development, where developers isolate an application’s business logic from its data validation logic -- usually a GUI of some kind -- and from its flow control. The business logic then gets its own container, the BRMS, in which business analysts "code" business rules in a simple, English-like programming language. Leading BRMS products include ILOG’s JRules, Fair Isaac’s Blaze Advisor, the Corticon Decision Management System, and Production Systems Technologies’ (PST’s OPSJ (Official Production System for Java). Even Microsoft is getting into the act with a Business Rules Framework for BizTalk 2004.
BRMS engines normally embed themselves in vertical enterprise apps such as those that handle underwriting, loan applications, complex scheduling, or other tasks that require simulation of human expertise. The advantages are obvious. Rather than playing telephone with IT, the business side gets direct control over rules that govern how enterprise applications behave. And when business analysts decide that business rules must change, they can make those alterations themselves rather than waiting for IT to get around to it. The result: much lower maintenance costs and much higher confidence that business rules are being implemented as intended.
Breaking the logic logjam
Business analysts typically have a much more distant relationship with enterprise applications than they do with, say, a spreadsheet model on the desktop. If people on the business side want a new app built or want changes made to an existing one, they submit a request to the IT department, which probably hasn’t the foggiest idea what they’re talking about. So begins an endless round of meetings between business and IT where the ambiguities get ironed out.
At some point, developers start writing the code, either building business rules into software components running on an app server or implementing them in stored database procedures. The development team then tests the code and hands it back to business analysts for verification -- at which point it’s rejected because the results are nothing like what the business analysts envisioned. A few months and a few code rewrites later, the business side finally gets something it can live with.
With a BRMS, business analysts both determine and write the business logic. All that’s necessary is that they know how to write a rule in English. A business rule typically goes like this: IF certain events occur or conditions exist THEN certain events should happen or ELSE other events should happen. Each IF-THEN-ELSE statement is a business rule. Each rule is declarative in nature and may interact with other rules. A BRMS allows business analysts to see, understand, code, and maintain those rules without help (well, sometimes with a little help) from IT.
A BRMS "chews" on the rules until it produces a solution. It continues to loop through the rules over and over again until there are no more rules that can possibly be executed. The whole idea is that changing data drives the way rules execute -- and that interacting rules reduce the need for human intervention. Related sets of rules may govern loan approvals, insurance policies, shipping carrier selection, and so on.
By contrast, in conventional application development, rules must be arranged in an incredibly fragile, top-down fashion. For example, if the THEN part of a rule changes the data used by the IF part of another rule, then the whole process must be examined to see how to get the rules in the right order. That’s why it takes so long to write, change, and maintain business rules using ordinary app dev methods.
Embedding rules in the infrastructure
At a block diagram level, a BRMS-driven application looks much like a conventional enterprise app. Think of a BRMS as another tier in an n-tiered system that contains the usual combination of Web server, application server, and database. The BRMS occupies a fourth tier that puts the logic in the hands of business analysts. Thanks to the English-like nature of BRMS statements, even the CEO can jump in and check the rules. Any rule can be changed, added, or deleted; be sent to the IT department for integration and testing; and be put into production in a matter of days or even hours.
Although enterprises can expect to save a bundle in change management, they should also prepare for a sizable initial investment in BRMS development and training. It’s almost impossible to evaluate how much time it will take to write the business rules because this depends on how many rules will be written -- and that inevitably turns out to be more than originally anticipated. Moreover, business analysts may well balk at the notion of "coding" business rules. As with any big IT adventure, a BRMS project must begin with the understanding and support of upper management.
The decision whether to use a BRMS rests on the type of application and the nature of the existing infrastructure. Obviously, a BRMS would be overkill for a small-scale, single-function application. And many large-scale commercial enterprise applications, such as ERP or CRM systems, already include rules engines, although they may be invisible to end-users. But many big enterprise business applications developed in-house can benefit from a BRMS, particularly if the business logic is isolated from the rest of the application in the original design.
Things get trickier when determining whether to integrate a BRMS into an existing system. The IT department and business analysts must work together to extract business logic that has been intermingled with control logic and data validation code. Software components may break when the business logic is extracted -- and deciding which rule goes where can be a laborious exercise. It may seem obvious, for example, that business rules do not affect data validation. But in some cases, data validation parameters change frequently and must be placed in the business analysts’ control (date ranges may shift, pick list categories may be dynamic, and so on).
Another stumbling block in refactoring existing systems is that the existing rules are rarely, if ever, entirely correct. Inconsistencies may create political problems or spawn long discussions on the business side as business analysts work to resolve difficult issues they may have otherwise avoided facing. Ultimately, each existing piece of business logic must be examined to see how it will fit in the new system. New objects may also be necessary, although most database applications can be "extended" by the BRMS without modification to the database. New GUI screens must be also considered because the entire application will be much more sophisticated and will require more information.
Many organizations hire consultants to help them determine the amount of work involved in deploying a BRMS. If upper management buys into using a BRMS and understands its value, it may be easier to scrap an existing application and start more or less from scratch, using the old data validation and control code only when it saves time and effort.
BRMS does finance
Financial institutions provide some of the best examples of BRMS solutions in action. For example, the past few years have seen an explosion in the number and variation of loan products, each governed by their own set of rules. BRMS enables the business side to get creative without fear of incurring excessive IT overhead.
One financial services company, E-Loan, did US$6 billion last year, most of it approved via a BRMS developed with Jess, a Java rules engine. The company used the source code provided with Jess to write its own BRMS user interface so that business analysts could enter simple rules that generated code for loan approval. Etienne Handman, CTO of E-Loan, says that improved customer relations -- stemming from the speed with which analysts can now make decisions -- has more than made up for the app dev costs, which turned out to be lower than traditional solutions.
At CitiStreet, CIO Andy Marsh was in sore need of a solution that business analysts could understand. The BAL (Business Action Language) of ILOG’s JRules allowed him to express all of his rules in the lingua franca of both his company and the financial industry. The result has been that the average analysis time required by CitiStreet’s team of business analysts has been reduced from six months to three months. Marsh is now contemplating how to leverage the benefits of BAL and JRules into CitiStreet’s workflow management process.
Lisa Fiondella, senior vice president of product management at Equifax, says that the driving force behind her adoption of JRules "was the reduction of translation errors between the business users and the programmers." She adds two other reasons: greater efficiency in overall IT operations and a shorter time to market for Equifax’s new product, InterConnect, a Web-based processing and decisioning platform that approves loan credits. As Fiondella explains it, using a BRMS eliminates the "fire drill" response to demands for business logic changes in existing applications.
A number of major banks, including Lloyds TSB, Barclays, and Citibank, use a BRMS for various applications, such as loan eligibility and pricing. A JRules application at one of these banks not only checks the applicant’s credit history, income, and so on, but it also checks out any co-signers and on that basis may recommend that the applicant apply for a higher status. After the applicant is approved, the BRMS finds the best price for the loan according to rules established and approved by the loan and sales departments. All of this activity is monitored daily by marketing and sales.
Changing the rules of the game
Although the BRMS has probably had its greatest success in the financial world, the technology is being applied to many other areas. Telecom companies in particular are frequent customers, often using a BRMS for a slew of applications, from determining how messages should be routed, to scheduling downtime for maintenance, to handling customer relations. Another frequent telecom application is the use of BRMS to help comply with and optimize operations for federal, intrastate, and interstate regulations.
When first introduced to the BRMS concept, enterprises typically face a conceptual hurdle in teasing out the rules that govern various business functions. After that Rubicon is crossed, however, and analysts focus on the rules that change dynamically, a BRMS can be applied successfully in some unexpected places.
If there’s one industry that demands quick reaction to competitive pressure and customer behavior, it’s the casino business. According to Harrah’s CIO Tim Stanley, marketing managers for the casino giant analyze business activity at each location every day. Based on that analysis, they come up with a new plan or promotion, and using JRules’ BAL, they implement new rules that are then tested and put into production within 24 hours.
"Sometimes I walk out of my office and see a group of customers actively playing at a time that used to be slow, and I say to myself, ‘They wouldn’t be here now if it weren’t for the one-off promotions I can do with our rules system,’ " Stanley says.
Picking the right BRMS
BRMS tools cover a wide range, from open source languages to full-blown enterprise systems. Those who want to get their feet wet with a BRMS might begin with Jess, which is a free download. Major enterprise development projects, however, require collaborative communication among all the participants -- business analysts, coders, the CEO, end-users, finance directors, and so on. Such projects are best served by a BRMS with all the bells and whistles.
ILOG’s JRules (the Java version) and Rules (the C/C++ version) and Fair Isaac’s Blaze Advisor are enterprise tools with the necessary debugging, testing, and analysis tools. They are products of companies that focus on overall business optimization. On the other hand, enterprise customers that need blinding speed and are willing to live with limited tools would do well to consider OPSJ.
Business rule languages have been in existence for decades, so it’s quite possible that many IT shops will have developers with previous experience. An IT department with staff that has prior training in OPS or CLIPS (C Language Interface for Production Systems) syntax might consider Haley’s Authorete, PST’s CLIPS/R2, or Sandia National Laboratories’ Jess. And of course, new tools always arrive on the market with new twists to consider, such as PegaRules (just broken out as a new product from PegaSystems) and Corticon, a new BRMS product that offers a spreadsheet interface for rules input.
The more polished products, such as JRules or Blaze Advisor, make self-service rule changes easier for business analysts, but experts in business rules logic must always be available to ensure BRMSes work smoothly. When a BRMS is properly implemented and supported, IT can expect operating cost reductions of 10 percent to 15 percent, according to Gartner.
That estimate doesn’t take into account the intangibles of being able to respond quickly to shifting business demands. That advantage may be hard to quantify -- and the notion of isolating and consolidating business logic may seem odd at first. In most cases, however, the payoff is next to inevitable.
New standards open up BRMS
In the early days of rules-based systems, there were only a few vendors, most of which used some variation of a syntax developed by the OPS (Official Production System) programmers at Carnegie-Mellon University. Each vendor put its own spin on the language, effectively locking in customers. What the industry needed and still needs is a way to enter rules in an engine-neutral format.
Several communities are proposing standards that will eventually enable business analysts to use a single, portable rules syntax and employ different rules engines for different projects. The leading proposed standard for achieving this is BRML (Business Rules Markup Language), an XML-based format for expressing rules in engine-neutral fashion.
The other major XML standard being proposed is DAML (Defense Advanced Research Projects Agency Agent Markup Language). The main goal of DAML is to enable developers to tag pages of information so that they can be read by BRMS products, which can then parse the information and use it in a rules-based context.
Evidence that business rules represent a worldwide effort can be seen in the RuleML (Rule Markup Language). Originating at the Sixth Pacific Rim International Conference on Artificial Intelligence in August 2000, RuleML is an attempt to support forward-chaining (top-down) and backward-chaining (bottom-up) approaches to building rules. RuleML was proposed as an XML standard but has been extended to Java-based rules engines.
FpML (Financial products Markup Language) intends to be the XML standard for swaps, derivatives, and structured products, and the Business Products Management Initiative proposes to standardize management of business processes that span multiple applications, corporate departments, and business partners.
Finally, the real heavyweight to enter the standards arena is Sun Microsystems, which has introduced JSR (Java Specification Request) 94 and has assigned it a place in Sun’s JDK. At this point, the javax.rule API is fairly limited to a few classes with several interfaces and exception classes, but that, after all, is how Java itself started. For Java-based rules engines, JSR 94 might prove to be the glue that binds together engine-neutral rules development.
Business rules and vocabulary for newbiesBRMS (business rules management system): Originally called a rulebase, now has matured to include much better API and GUI debugging capabilities and should include sophisticated tools that allow business users and programmers to fine-tune the final product
CLIPS (C Language Interface for Production Systems): Free C/C++ rules-based system that uses the OPS syntax for rules and is available from NASA
DAML (Defense Advanced Research Program Administration Agent Markup Language): Emerging standard for managing rules in military applications
EHS (else hand side): ELSE part of a rule that kicks in if the rule should fail (see LHS, RHS)
Jess (Java expert system shell): A BRMS from Sandia National Laboratories, which uses CLIPS/OPS syntax for rules
JSR 94 (Java Specification Request 94): Incorporates the javax.rules API to make Java-based BRMSes interoperable
KBS (knowledge-based system): Complex project that incorporates a rules-based system, a knowledge base of facts and actions, and an ANN (artificial neural network)
LHS (left hand side): IF part of a rule (see RHS, EHS)
OPS (Official Production System):System in which a production is a rule; inspired by the early rules-based systems used in psychology
OPSJ (OPS for Java): Developed by Production Systems Technology’s Dr. Charles Forgy, inventor of the Rete Algorithm
RBS (rules-based system): What is known today as a BRMS; isolates logic in a declarative style that’s easy for nonprogrammers to enter and modify
Rete Algorithm: Public domain algorithm invented by Dr. Charles Forgy in 1979; minimizes the number of matches in a rules-base system and effectively accelerates program execution by a factor of 3,000
Rete 2: Much more advanced Rete algorithm also invented by Dr. Charles Forgy; between 100 and 1,000 times faster than the original Rete algorithm
RHS (right hand side): THEN part of a rule (see LHS, EHS)
XSLT (Extensible Stylesheet Language Transformation): Way to transform an XML description into almost anything; especially useful for converting a general set of XML rule descriptions into a format consumable by a specific BRMS engine
James Owen, senior knowledgebase consultant at Knowledgebased Systems, has worked with expert systems since 1989.