In-Depth

Trends: End-User Application Development using Business Rules

The business rules approach is gaining ground—and has proven successful in the most unlikely of environments: long-time mainframe shops.

• By Stephen Swoyer
• 04/19/2005

In most organizations, there’s an uneasy détente between line-of-business customers and application developers. The former are often accused of asking for too much, too often; the latter, of delivering too little, too late. The compromise, of course, is that the line of business gets software that doesn’t really do what it needs it to do, while the enterprise programmer never seems to please any of the people any of the time.

Help could be on the way, however, in the form of business rules, a not-so-new technology on the verge of going mainstream.

The business rules technology purports to empower business users to customize application code and implement these changes, via a business rules management system (BRMS), in production environments. For mainframe systems programmers, business rules seem—on the surface, anyway—to be fraught with peril, but adopters say their use in Big Iron environments can amount to a win-win for both IT and the line of business.

The gestation of a software project in large enterprises sometimes resembles a series of arbitration hearings between two parties at perpetual loggerheads with one another. In a certain sense, IT and the line-of-business typically interact by means of contracts. Whenever a new application or feature is proposed, line of business creates an exhaustive requirements list, programmers negotiate with line-of-business stakeholders to determine what is and what is not feasible, and eventually—several weeks, months, or even years later—produce a final deliverable that is expected to conform to the original requirements.

The problem with this approach is that business requirements almost always change. Application requirements identified by line-of-business customers in, for example, 2002 had probably changed by the time a finished application was delivered in 2004.

Business rules promise to address this problem, to some extent, by codifying business logic in a rules repository and by giving business users an intelligible means—using if/then/else logic—to change an application’s parameters. The classic-use scenario involves an e-commerce site that unveils a limited promotional effort to give discounts to customers on the basis of past patronage or buying habits. If the programmers who built the site’s e-commerce applications were prescient, they probably designed just such a facility into it—namely, a feature that lets them update the application logic to enable promotional discounts for targeted customers with a modicum of effort.

There are several drawbacks to this approach, however. For starters, it requires the direct involvement of application developers, which—given the sometimes strained relations between IT and the line of business—is bound to be a frustrating experience for both parties. Secondly, it involves making changes to an application that could potentially lead to destabilization. Third, even if there’s a facility for enabling (in this case) targeted discounts, to what extent is there a similar feature to track (and roll-back) such changes over time? Finally, the actual code required to support the scenarios envisioned by the line of business could be quite complex.

In the business-rules model, the line of business itself makes these changes. What’s more, business users can do so by completing any of several pre-built templates designed by programmers.

The finished template is processed by the BRMS, which (depending on the vendor) fires out COBOL, Java, or .NET code that incorporates the desired changes. “The key things about business rule management solutions is that they allow you to make a system do things to drive behavior, not with lines of code, but with declarative statements, typically representative of some if/then/else statements, but often fairly complex ones,” says James Taylor, director of product marketing with Fair Isaac Corp., a credit reporting company and one of the most venerable BRMS players on the field. “The attraction is that those rules are atomic elements: they either fire, or they do not. When you’re trying to say, why did this piece of software try to do X rather than Y, it’s much easier to say, which rules fire in that transaction than it is to store and document the lines of code that fired.”

Fair Isaac has marketed its own BRMS, Blaze Advisor, for more than a decade. Blaze Advisor runs on J2EE, J2SE, .NET, and S/390 or z/OS in COBOL form. Because of the ubiquity of mainframe systems in many of the large organizations that can most benefit from business rules, there’s a huge market for BRMS on Big Iron, Taylor says.

“We’ve found that for some of our highest performance customers, although they could add the Java version on the mainframe quite happily, the performance hit associated with getting all of the stuff across the CICS/Java boundary, was taking too long."

How does IT cotton to what a reasonable person might perceive as an invasion of its turf? More to the point, how do mainframe systems programmers, not to mention mainframe operators—both of whom are notoriously selective about who or what gets access to their Big Iron applications—react to this idea?

Fair Isaac says that quite a few companies are using the native COBOL version of its Blaze Advisor product, particularly for transaction-intensive applications (such as credit card processing) that simply can’t tolerate the performance loss involved in translating CICS to Java.

In the case of at least one such customer, AAA Michigan, the introduction of a BRMS—in this case, Fair Isaac’s Blaze Advisor running in its COBOL form—has resulted in a very winning combination. AAA Michigan uses business rules to support a tiering function for its automobile insurance underwriting program. The idea, says Michael Koscielny, director of regional underwriting operations at AAA Michigan, is to offer different customers different insurance quotes based on their responses to different questions.

The use of business rules provides an easy way not only to ensure that applications are processed very quickly—one of the attractions of business rules is that they help to codify business logic that has traditionally been associated with a manual process—but to prove (for legal and other reasons) that all applicants have been fairly treated. Because many of the factors involved in estimating a customer’s eligibility for insurance frequently change, the use of business rules—and, particularly, of a BRMS like Blaze Advisor, which tracks business rules and maintains a history of past changes—helps AAA Michigan cleanly make new changes.

The experience has been so beneficial, says Koscielny, that AAA Michigan plans to business rules-enable other mainframe operations. “The next piece we’re working on now is automating the validation of discounts,” he says. Many of those things are hard-coded into the mainframe system. The problem with that is cycling applications through the mainframe takes more time in the application process than is really expected from the user standpoint, so we’re moving all of those validations over through Blaze.”

The old mainframe hands, for their part, were initially resistant to the idea of business rules, but have since come around, says Koscielny—thanks largely to the fact that they’re now fielding fewer requests from line-of-business customers to make changes (or back out of changes) in mainframe applications. As for giving business users the ability to publish business rules directly out into production environments, Koscielny says AAA Michigan isn’t yet there—and probably won’t go there any time soon, given the issues involved with testing proposed changes and regression testing them across the infrastructure. This is also music to the ears of AAA Michigan’s overly protective mainframe personnel.