Business Rules Bridge the Gap between Policies and Execution

Few IT professionals really understand business, and few finance executives really understand IT. Centralized business rules management (BRM) helps bridge the divide between the business vision and policy execution—and enable IT efficiencies in the process.

Vagaries of compliance got you down? You're not alone. It's a Byzantine process for all involved, but an increasing number of companies are turning to a not-so-new technology practice —called business rules management, or BRM for short—to help them address their compliance needs.

BRM isn't a silver bullet, even proponents concede. Nevertheless, advocates claim, when they're used intelligently, business rules can provide a controlled, centralized, and coherent infrastructure that supports multiple compliance measures.

"The whole idea of compliance is trying to close the gap between your policies and what you do in your business. It's the policy execution gap. And that's something [business rules are] ideally suited for," says David Straus, vice president of sales and marketing with BRM specialist Corticon Technologies.

But what is a business rule?

Business Rules 101

In a nutshell, a business rule is any logic or policy you use to effectively run your business. The point, proponents say, is to (1) identify the rules that are required for a business to function, (2) document them, (3) make them operational, and (4) automate their management (provisioning, enforcement, monitoring, auditing). This has obvious ramifications for compliance.

For example, consider a homegrown CRM application. Business owners might determine specific rules—e.g., customers who order $100 or more in merchandise get a 10 percent discount; repeat customers who order $100 or more in merchandise get a 15 percent discount; and so on. The CRM application checks to see if predetermined conditions are met (if x) and performs a specific action (then y). This if-then logic is a textbook example of a business rule.

BRM proponents see such business logic independent of applications. Business rules management systems (BRMS) allow business users—ideally, with minimal IT oversight—to abstract logic in the form of a declarative rule or sequence of rules. For example, the rule that "if a customer purchases X dollars worth of goods, a discount of Y is applied" is stored not in the application tier, but in a middle tier. This middle tier is the BRMS, which combines a rules engine (a server that decides which rules to fire and when), a rules repository, and management facilities. In practice, a BRMS translates rules that have been identified and codified by business users and analysts into functional code, which is typically accessed by J2EE or .NET interfaces.

In the business rules paradigm, business users create the rules, using simple, declarative statements. BRM effectively gives business folk the keys to the kingdom.

Business Rules and Compliance

The case for business rules, proponents say, is a no-brainer. For starters, they argue, business rules—or, more specifically, a BRMS—can provide a centralized solution for several compliance pain points.

A business rule in its purest form is a control. The BRMS provides the plumbing for the implementation and enforcement of these controls—e.g., user type A can view data in report Z but cannot alter it; user type B can view data in report Z and can alter it; no user can alter data if conditions X and Y have been met. In addition, the BRMS supports monitoring and auditing of controls, which ensures that they're reliable and available and that they generate a documentation trail for the purposes of compliance.

"Rules are very good for [compliance]: you can log for every transaction exactly which rules fire, which ones didn't, which conditions were therefore true, and then go back and say, 'I didn't use this data illegally, because these are the rules that fired,'" says James Taylor, director of product marketing with credit reporting company Fair Isaac Corp., which—along with BRMS specialist ILOG—are is one of the oldest BRMS vendors on the block.

There's another case to be made for business rules. In many instances organizations create new business rules to automate once-manual processes. This can provide a valuable legal safeguard: a human actor is prone to caprice, mistake, or worse; business rules are either invoked or not invoked based on a pre-defined set of inflexible conditions. Like Arnold Schwarzenegger's Terminator, they cannot be reasoned with, bargained with, or—it stands to reason—influenced.

This last quality was a factor in insurer AAA Michigan's decision to embrace business rules, by way of Fair Isaac's Blaze BRMS, says Michael Koscielny, director of regional underwriting operations at AAA Michigan. Koscielny uses business rules to support a tiering function for AAA's automobile insurance underwriting program. This lets his company offer different customers quotes based on their responses to various questions. It also enables AAA to cover its posterior in the event of customer-initiated litigation, Koscielny confirms.

"We built in some eligibility rules that knock people out, so if certain risk criteria appear that make the user ineligible, the user is told immediately [that], because of these conditions, the user is not eligible," he says. "It's possible you might have a customer who says they were discriminated against because they were told they were ineligible; so, this way, they're told right away the how and the why."

Closing the Policy-Execution Gap

BRM proponents like to make a final pitch for the technology, which usually goes something like this: information technology is far from irrelevant—but, in an age of compliance, the application of information technology is also too sensitive and important an issue to trust entirely to IT professionals.

There's a familiar division at the crux of their argument: Few IT professionals really understand business, BRM advocates say; conversely, few C-level executives really understand IT. Still, when IT fails to execute on the intentions of C-level executives, those executives could pay the price—in regulatory fines, or worse. One result of this has been a flurry of interest in narrowing the gap between the vision of the business domain expert and its instantiation in workaday reality.

"Your policies always reflect a gap between the intent of the management and the actual day-to-day execution. This is a gap that people want to fill, and business rules, because they're agile, because they're auditable, because they're controllable...help fill this [gap]," says Corticon's Straus.

The point, enthusiasts say, is that BRM can narrow the gap by putting business domain experts in the driver's seat. This is important for compliance with SOX, the Gramm-Leach-Bliley Act (GLB), and other measures, but it's also critical in verticals—such as the insurance or financial services industries—in which regulations change frequently.

"You want to be able to go in and tweak your policies to react quickly to change, new regulations, competitive mood, a new opportunity opening up in your market," explains Henry Bowers, director of product marketing with ILOG. "It's about making the rules visible and touchable by the people who are defining those rules, and providing a quick and easy path for getting those rule changes into a production environment."

Final Thoughts

Ronald Ross, co-principal with consultancy Business Rules Solutions LLC and executive editor of BRM resource site BRCommunity.com, is—surprisingly enough—anything but a business rules zealot. Debunking some of the more optimistic claims made big BRMS vendors, Ross says that today's BRM solutions aren't there yet in terms of making it possible for business leaders to program and implement (free from IT oversight) their own rules. In spite of the manifest capabilities of today's BRMSes, this goal is still horizontal.

Nevertheless, Ross stresses, BRMS vendors are on the right track. "It really is time to be looking for an evolutionary paradigm, where we are dealing with business know-how and encoding it in a form that is closer to its origination within the business," he concludes.

Author

Stephen Swoyer is a contributing editor for the IT Compliance Institute. He is based in Athens, Georgia. You can contact him about this and other articles at swoyerse(at)percipient-analytics.com.

This article originally appeared at itcinstitute.com. Copyright 2008, 1105 Media Inc. Reprinted with permission.



Comment on this article

You must be logged in to leave a reply. Login »