In-Depth

Why Business Rules Matter

'What mainframe shop doesn't have business rules? In an age of draconian compliance and governance, the case for rules is stronger still. You can, however, benefit by implementing a BRMS.

• By Stephen Swoyer
• 05/13/2008

With all the talk about business rules, you'd think the rules themselves were something new.

That may be because vendors, including Corticon, Fair Isaac Corp., and ILOG Inc. (among others), market full-blown business rules management systems (BRMS) -- platforms for identifying, codifying, cataloging, and managing business rules. These vendors do their best to educate customers about the importance of business rules -- and, of course, about the benefits of a full-blown BRMS.

IT managers in mainframe and other high-end environments might be wondering what all the fuss is about. The mainframe has evolved, after all, as a platform for implementing and dealing with business rules. COBOL, with its highly declarative syntax, seems like an ideal language for programming business rules. Many organizations have done just that, often haphazardly, occasionally rigorously, over the years.

Why should mainframe or other high-end consumers take the BRMS plunge? Part of the reason, advocates say, is the non-standardized way in which business rules themselves have been implemented and managed in most environments. Compliance and governance, which place a premium on standards, accountability, and auditability, simply demand more. There's also the idea that compliance and governance have really primed the pump for business rules: governance, after all, values standards, not unconventional or informal processes or activities.

With an emphasis on closing loopholes -- i.e., ferreting out informal and undocumented processes or activities, there has been a push to take discretion out of the hands of all but a few highly accountable executives or managers. Business rules, either hard-coded into application logic or integrated via a BRMS, are an effective means of doing so, advocates maintain. If a particular action kicks off a business rule or sequence of rules, there's no way of getting around it. No way that isn't auditable or traceable, that is.

These are the key drivers, but BRMS proponents also tout other factors -- including what some describe as the "insular" development of rules themselves. It isn't just that rules, when instantiated, evolved in an ad hoc or non-standardized way. Business rules as a discipline have evolved significantly since their birth nearly two decades ago.

"Historically, business rules were viewed as simply a different way of coding, and the object of business rules was the business rules themselves. It's really the only industry I've ever seen where this was the case," says David Straus, senior vice-president of marketing with Corticon.

"If you take something as [seemingly] un-businesslike as software development, even the object of software development wasn't software development -- it was the business."

To a degree, Straus says, this perspective was a product of the imaginative soil -- i.e., artificial intelligence (AI) research -- in which business rules development (as a discipline and not simply as an ad hoc activity) first took root.

"If you go back and look at the history of this market, it started in a more formal way in the mid-80's with a bunch of AI guys who were applying this really cool set of technologies to take these rules and apply them to problems -- in a lot of cases, [to] expert systems. For these guys, the rules … were the atomic unit of goodness," Straus explains.

"That was really cool stuff and really important stuff, but it really doesn't [address] what we're trying to do. We're trying to automate a decision that was manual or improve a decision. The business process management market is about processes. The rules market was talking about the how-tos, but not the outcomes. That's the big change [these days]."

What about business rules in mainframe or other high-end environments? Straus concedes they exist, but they're frequently haphazardly implemented, poorly understood (as assets), hard-coded into application logic, and -- in short -- non-standardized. Straus argues that they aren't as pervasive as governance or compliance advocates -- much less BRMS advocates -- might wish.

"I've seen estimates where the percentage of operational systems that are automated was something like 20 percent or less. That means 80 percent of the repetitive decisions we make in business today are still being done by people. That's exactly the knowledge that we need to identify and document," he says.

Not that business rules could or should take people completely out of the loop, Straus cautions. "Business rules can be used to make recommendations to people in a very organized way. If you want a human underwriter to still make that decision, you can either rely on them to have read the policy manual to make their decisions or you could actually codify the policy manual [in the form of rules]," he explains.

In many ways, Straus says, the proof is in the pudding: once users take the BRMS plunge -- which in Corticon's schema involves a model-driven approach to identifying, codifying, and implementing rules -- they tend to get a lot more ambitious.

"They not only have caught the energy of using business rules, they begin to quickly move to saying 'We could use it here and here and here and here.' And by actually using a model-driven approach to business rules and doing it once, you can suddenly envision the other applications or problems in your environment where you can use them," he contends.

A BRMS is a viral phenomenon, he argues: "In large organizations, it tends to [branch out] in waves. A project team will do something and then it will begin to branch out and other projects will see how it works and will use it themselves."

In this respect, Straus likens the adoption of a BRMS to the move from Assembler to COBOL -- without, of course, the attendant execution performance penalty. "Once you program at a higher level, you recognize that it has its benefits," he concludes.

"What I think the business users want is agile apps. They want an outcome, and if business rules happen to be a cost-effective way to get that outcome, then they'll do it. The benefit of [business rules] is that these models are very understandable by both IT and the business."