In-Depth
Proponents Push Business Rules, But Programmers Aren’t Buying, Yet
- By Stephen Swoyer
- May 1, 2005
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