In-Depth

Proponents Push Business Rules, But Programmers Aren’t Buying, Yet


Talking Points
RULES TO DIVIDE

  • There’s a good chance programmers already are using business rules in the form of proto-rules in their environments.
  • Business rules advocates often promise that the technology will eliminate much of the rote or otherwise tedious maintenance and production support.
  • Programmers often have good reason to resist the transition to a business rules-based approach because the impetus usually comes from the line of business.

The tale that unfolds herein smacks of heresy. It describes an effort to empower business users to program or customize code and implement code changes in production environments. It also implies, to a limited extent, that some development responsibilities can be taken out of the hands of IT. But that’s not all. In its most radical version, the story proposes to do away with many of the programming tasks that enterprise coders take for granted.

That’s the operative premise of the business rules approach, an emerging programming paradigm that interpolates a new middleware tier alongside that other new middleware tier—the J2EE or .NET application server. This new-new middleware tier, called the business rules management system (BRMS) is tasked with translating the declarative statements—business rules—that business users and analysts have identified and codified into functional code, typically consumable by J2EE or .NET application servers.

What’s surprising is that some business rules adopters say their code jockeys have never been happier.

“There obviously was resistance from the IT side when a new application is in there that they don’t have full control over,” concedes Michael Koscielny, director of regional underwriting operations with automotive insurer and BRMS adopter AAA Michigan. “The folks working on [the BRMS were] really doing true development work. We’ve assumed the routine stuff and the maintenance, which is stuff they were pretty happy to give up. So this has absolutely improved our relationship with IT.”

The upshot, Koscielny says, is a win-win situation for IT and the line of business. “We work much more closely with them than in the past,” he explains. “We’re stakeholders now. The business owns [the BRMS], and because of that, there’s much better communication with the folks in IT.”

Of course, Koscielny and AAA haven’t bought full-tilt into the business rules approach. At this point, few adopters have.

From proto-rules to business rules
Why would programmers warm to the idea of business rules? For starters, advocates say, there’s a good chance they’re already using the technology—in the form of proto-rules—in their own environments.

Often, these proto-rules are hard-coded into the application logic. “There’s various kinds of business rules, but there are other kinds of business rules that are more of the editing/validation nature that probably the existing legacy systems support more directly, and there it’s probably a case of extraction, unification and redeployment” of these existing rules, says Ron Ross, co-principal of consultancy Business Rules Solutions LLC, member of The Business Rules Group and executive editor of BRCommunity.com, an online resource for developers and business users working with business rules.

Consider a homegrown e-commerce application that’s outfitted with a built-in facility to enable discounts on a per-customer basis. The business rules paradigm proposes to abstract this logic into the form of a declarative rule or sequence of rules. For example, for every customer that purchases X or more dollars worth of goods, apply a discount of Y—and move it from the application-layer into the BRMS.

The conceptual shift, of course, is that with the encoded proto-rules of today, enterprise developers hold the keys to the kingdom. If the line of business—say, a sales department that’s under pressure to meet its quarterly revenue targets—wants to implement a promotional campaign that’s pegged to some changes in the application’s proto-rules, it has to hammer out its requirements with coders and get the project approved.

In the business rules model, the rules are interchangeable and componentized so that once they’re identified, codified and implemented in a repository, they can be provisioned for a production environment.

In the business rules vision touted by many advocates, line-of-business users would own each of the stages of this process. That’s a problem, however, even for many business rules enthusiasts. In addition, there’s a lot more involved with building a business rule than “If X then Y.” In fact, the most important piece of the business rules puzzle is still gestating: the identification and codification of a portable vocabulary for business rules. “It’s surprising, but in all this time, there hasn’t been any standard for words like ‘goal’ and ‘objective’ and ‘standard,’” says Ross.

Given the glacial progress of industry standards bodies, there may not be one anytime soon, either.

Developers stop worrying and love the rules
Business rules proponents recognize their vision—if not the technology—also can be an tough sell to the code jockeys on the other side of the great divide. “There’s almost always some resistance at first, and part of overcoming that is realizing that this [business rules] isn’t some newfangled idea, but an idea that’s been around for a while,” says Henry Bowers, director of product marketing with longtime business rules specialist ILOG.

Many advocates acknowledge programmers often have good reason to resist the transition to a business rules-based approach. After all, the impetus usually comes from the line of business. In many cases, it’s a move that IT is forced to accept.

Because of this, advocates like to trumpet the technology’s pedigree, which has its roots in a very developer-friendly space—the experimental expert system and artificial intelligence technologies of yesteryear. “The kernel of what you see in today’s business rule management systems came from there, but the only thing that really survived to the present was the engine itself,” says James Taylor, director of product marketing with Fair Isaac, one of the oldest BRMS players on the block. “It’s the engine technology that grounds and provides a stable basis for applying business rules in mission-critical applications.”

Proponents also try to narrowly delimit the scope of what they mean by business rules. In fact, many advocates bend over backward to point out that the paradigm doesn’t usurp any responsibilities from IT. “What we mean by business rules are sort of the business-related logic that’s the domain of the business person, but it’s also very changeable business logic,” ILOG’s Bowers says. “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.”

To help make the idea even more palatable to IT pros, business rules advocates usually have at least one trump card to play—a promise to eliminate much of the rote or otherwise tedious maintenance and production support. After all, business rules proponents argue, a lot of production support issues are prompted by requests from line-of-business customers to add new features or functions to, or change the operation of, existing applications. But if the line-of-business users are empowered to make these changes, that’s one more monkey off a code jockey’s back, isn’t it?

Business rules proponent Ross argues the technology gets programmers back to doing what they most love: innovative, value-enhancing software development. “For the kinds of developers who don’t care to deal with business questions so intently, this actually gives them a cleaner separation so they can do the neat and cool stuff with respect to refactoring, redeployments and all of the other things they’d like to be doing,” he argues.

Although there’s a lot of upside to the business rules approach for IT and the line of business, much of it is future upside, experts say. The solutions available today do deliver on the basic vision—empowering business users to change code, yada, yada—but are rarely if ever used without significant oversight from IT. Call it “empowerment lite.”

Business rules in action
Central to the business rules approach is the idea of separating core business from non-business logic. Jane C. Analyst probably doesn’t care about the e-commerce application (a hybrid Java- and C-based system) that facilitates the order fulfillment process on her company’s Web site. It doesn’t matter to her that when the J2EE application server fields a new customer request, it makes calls to legacy C and C++ programs via the Java Native Interface. Nor does she care one bit about the JDBC calls the application server makes to an Oracle database to retrieve information about a specific customer’s historical purchasing habits. From her perspective, Jane C. Analyst is concerned only about the customer, the order, the value of the order and so on.

One piece of the application infrastructure Jane C. Analyst probably does care about is the BRMS that translates the declarative statements she enters in a pre-built template into functional J2EE, .NET, or (in some cases) COBOL code, and which (thanks to the rules engine that sits inside the BRMS) is able to implement these changes into production.

The BRMS is the heart of the business rules approach, and the BRMS products marketed by Fair Isaac, ILOG, Corticon and others. These high-end offerings are powered by sophisticated inferencing engines, for example, which are able to deduce the correct order in which a collection of rules should fire on the basis of the information that’s available to them. At their heart is the business rules engine, a server daemon which starts and stops rules as needed.

The modern BRMS features built-in support for things like provisioning, so that rules can be easily enabled and then recalled; monitoring, so that businesses can track which rules have fired, which rules haven’t fired, and troubleshoot accordingly; and auditing, so organizations can provide proof that certain rules—which also double as controls for the purposes of compliance—are in place and functioning correctly. In some cases, replacing once-manual processes with business rules can provide a valuable legal safeguard, too: 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.

Consider AAA Michigan, a business rules adopter that embodies several of these use cases. For starters, AAA uses business rules to support a tiering function for its automobile insurance underwriting program. This lets it offer different customers different quotes based on their responses to questions, says AAA’s Koscielny. In this case, Koscielny confirms, the switch to a business rules approach didn’t displace any existing programmers.

“We had a processing system that was strictly a processing system, no edits, rules, just underlying processes,” he says. “It was 100 percent manual, which was quite time consuming and labor intensive. We defined all the logic associated with that process in Blaze, and the beauty of that is that it’s 100 percent accurate every time, so we’re not making math errors.” It goes beyond that, though, says Koscielny. 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, which tracks rules and maintains a history of changes—helps AAA cleanly make new changes. This probably would not have been possible using a conventional production support approach.

What success has AAA had in achieving the Holy Grail of the business rules paradigm—that is, a line of business that owns, supports and maintains its own application, independent of oversight from IT? His company is halfway there, says Koscielny: The line of business does indeed own the application—Blaze Advisor BRMS—but still submits to oversight from IT. “We have used the template approach within Blaze to where once we have a few short meetings with developers, they define the template, we have the opportunity to review the code from behind, and once that’s done, we put that into a user interface,” he explains.

But code changes still don’t go live until IT is done testing them. What’s more, Koscielny concedes, the line of business itself doesn’t actually implement them. “We have an agreement with IT that they will pass for us those sorts of changes at least once a week,” he says.

Different spaces, different rules
Proponents cite the ability of business rules engines to solve many different business problems, and unfailingly note the majority of extant business processes haven’t yet been automated or even documented. Put it all together, they say, and you’ve got all of the trappings of inevitability.

“The difficulty is that those business rules tend to have quite different semantics in different problem spaces, even within the IT arena,” says veteran programmer H.S. Lahman, a consultant with custom coding house Pathfinder Solutions. “Thus double-entry bookkeeping is a paramount concern for a core accounting system while it is irrelevant to a sales forecasting system. So the real question is: are there adequate tools for describing those rules in the semantics of the particular problem space?”

Work proceeds apace on this and other fronts, however. And although business rules propose to minimize the role of software developers, much of this work is being done by luminaries in the programming space. Last summer, for example, the Object Management Group announced its Business Enterprise Integration Domain Task Force had started working on a standards framework for modeling business rules, workflow and other aspects of the business process.

“This gets very deep into organizing business vocabularies as well as business rules, and in the underlying logic and logical formulations for the meaning of those rules,” says Ross, who notes that such efforts have taken him and several of his colleagues far afield from their areas of expertise. “This gets you into linguistics, it gets you into formal logic, not to mention standardization activities. So a consortium was formed called the Business Rules Team…to hammer out business semantics of business rules standard submission.”

What’s more, the OMG’s efforts are heavily pegged to its programmer-centric Model-Driven Architecture, and some experts see a great deal of synergy, not to mention potential, here as well. “I see OMG’s MDA initiative being an important way to link [business rules management] tools with software development tools,” says Lahman, who notes that MDA provides a disciplined framework for converting models in one representation into models in another representation. “Basically what MDA provides is a much needed framework and standards that allow migration of models from the pure customer viewpoint to a detailed software computational solution.”

Sidebar: What’s a business rule?

More on ADTmag.com:
California’s DMV creates rules for a developing road
By Kathleen Ohlson
Business rules not just for coders anymore
By ADT Staff
The goal: Automating policies, procedures
By Lana Gates

Featured

Upcoming Events

AppTrends

Sign up for our newsletter.

I agree to this site's Privacy Policy.