Business rules management systems

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.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Try Sun servers, workstations and storage products free for 60-days. Sponsored by Sun Microsystems DOWNLOAD PDF Click here to download InfoWorld's special report Putting rules engines to work

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 Technology’s (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.

Click for larger view.

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.