Your developers may be great at writing code, but you
don’t want them making ill-informed decisions about the way the
business works. Likewise, business analysts should focus on making
business decisions rather than try to translate them into
excruciatingly detailed requirements. One way for a company to make
the most of each side's strengths is by deploying a business rules
management system (BRMS).
A BRMS can bring the business and IT much closer by giving
control of the logic - and even the code - to business analysts.
This heretical idea relies on a fundamentally different approach to
development, where developers isolate an application’s business
logic from its data validation logic and from its flow control. The
business logic then gets its own container, the BRMS, in which
business analysts "code" business rules in a simple, English-like
programming language.
BRMS engines normally embed themselves in vertical enterprise
applications which simulate human expertise, such as those that
handle underwriting, loan applications or complex scheduling. It
gives the business side direct control over the rules that govern
how enterprise applications behave. And when business analysts
decide that business rules have to change, they can make the
alterations themselves rather than waiting for IT to get around to
it.
The result is much lower maintenance costs and much higher
confidence that software is implementing business rules
properly.
Break the logic logjam
Business analysts typically have a far more distant relationship
with enterprise applications than they do with, say, a desktop
spreadsheet. If people on the business side want a new application
built or changes made to an existing program, they submit a request
to the IT department, which probably hasn’t the foggiest what
they’re talking about. So begins an endless round of meetings
between the business and IT to iron out the ambiguities.
At some point, developers start writing the code, either
building business rules into software components running on an
application server or implementing them in stored database
procedures. The development team then tests the code and hands it
back to business analysts for verification. It's at this point the
code is rejected because the results are nothing like what the
business analysts envisioned. A few months and a few code rewrites
later, the business side finally gets something it can live
with.
With a BRMS, business analysts not only determine the business
logic, they write it too. All they need to know is how to write a
rule in English.
A business rule typically goes like this: if certain events
occur or conditions exist, then certain events should happen or
else other events should happen. Each If-Then-Else statement is a
business rule. Each rule is a declaration and may interact with
other rules. A BRMS allows business analysts to see, understand,
code and maintain rules with (almost) no help from IT.
A BRMS chews on a set of rules until it comes up with a
solution. It loops through the rules again and again until no more
can be executed. The idea is that changing data drives the way
rules execute - and that interacting rules reduce the need for
human intervention. Related sets of rules may govern loan
approvals, insurance policies, choice of distributor, and so
on.
By contrast, conventional application development arranges rules
in an incredibly fragile, top-down fashion.
For example, if the Then part of a rule changes the data used by
the If part of another rule, the whole process must be examined to
put the rules in the right order. That’s why it takes so long to
write, change, and maintain business rules using ordinary
application development.
Tiers without fears
Diagrammatically, a BRMS-driven application looks much like a
conventional one. In a multi-tier system that contains the usual
combination of web server, application server and database, the
BRMS occupies a fourth tier that puts the logic in the hands of
business analysts. Thanks to the English-like nature of BRMS
statements, even the chief executive can jump in and check the
rules. Any rule can be changed, added or deleted; sent to the IT
department for integration and testing; and put into production -
all in a matter of days or even hours.
This can save companies a bundle in change management, but they
should also prepare for a sizable initial investment in BRMS
development and training. It’s almost impossible to evaluate how
much time it will take to write the business rules because it all
depends on how many rules you will write - inevitably, you will end
up with more than you originally anticipated.
Business analysts may also baulk at the notion of coding
business rules. As with any big IT adventure, a BRMS project must
begin with the understanding and support of top management.
Practical applications
A BRMS would be overkill for a small-scale, single-function
application. And many big enterprise applications, such as ERP or
CRM systems, already include rules engines, although they may be
invisible to end-users. But many of the larger applications
developed in-house can benefit from a BRMS, particularly if the
business logic is isolated from the rest of the application in the
original design.
Things get trickier when determining whether to integrate a BRMS
into an existing system. The IT department and business analysts
must collaborate in extracting business logic from the control
logic and data validation code it is mixed up with.
Software components may break when the business logic is
extracted - and deciding which rule goes where can be a laborious
exercise. It may seem obvious, for example, that business rules do
not affect data validation. But in some cases, data validation
parameters change frequently - date ranges may shift, pick list
categories may be dynamic - and so must come under the control of
the business analysts.
Another stumbling block in refactoring existing systems is that
the existing rules are rarely entirely correct. Inconsistencies may
create political problems or spawn long discussions on the business
side as business analysts work to resolve issues they may have
otherwise avoided facing.
Ultimately, each existing piece of business logic must be
examined to see how it will fit in the new system. New objects may
also be necessary, although most database applications can be
extended by the BRMS without database modifications. New GUI
screens should also be considered because the entire application
will be more sophisticated and require more information.
Many organisations hire consultants to help them determine the
amount of work involved in deploying a BRMS. It may be easier to
scrap an existing application and start from scratch, using old
data validation and control code only when it saves time and
effort.
Take the fire drill out of finance
Financial institutions provide some of the best examples of the
BRMS in action because they allow the business side to get creative
without incurring excessive IT overhead.
Financial services company E-Loan turned over $6bn (£3.24bn)
last year, mainly via a BRMS developed with the Jess Java rules
engine. The company used the source code provided with Jess to
write its own BRMS user interface so business analysts could enter
simple rules to generate code for loan approval. E-Loan's chief
technology officer says the improvement in customer relations
brought about by faster decision easily justified the application
development cost, which was lower than with traditional
solutions.
At CitiStreet, chief information officer Andy Marsh sorely
needed a system that business analysts could understand. Ilog’s
JRules allowed him to express all his rules in the lingua franca of
both his company and the financial industry, halving the average
analysis time required by the company's business analysts. He is
now contemplating how to extend the benefits ot the company's
workflow management process.
Lisa Fiondella, senior vice-president of product management at
Equifax, says the driving force behind her adoption of JRules "was
the reduction of translation errors between the business users and
the programmers". Other reasons include greater efficiency in
overall IT operations and a shorter time to market for a new
web-based loan-credit product. Fiondella says using the BRMS
eliminates the "fire drill" response to demands for business logic
changes in existing applications.
BRMS technology is spreading to other areas too. Telecom
companies often use a BRMS for everything from determining how to
route messages, to scheduling maintenance downtime and handling
customer relations. Another frequent telecom application is to help
achieve compliance with statutory regulations.
In deploying a BRMS, companies often face a conceptual hurdle in
teasing out the rules that govern various business functions. After
that Rubicon is crossed, however, and analysts focus on rules that
change dynamically, organisations can apply a BRMS in some
unexpected places.
One business that gains from using a BRMS to react fast to
competitive pressure and customer behaviour is casino giant Harrah.
According to chief information officer Tim Stanley, the
casino's marketing managers analyse activity at each location every
day to come up with new promotions. Within 24 hours the new rules
have been tested and gone into production.
"Sometimes I walk out of my office and see a group of customers
actively playing at a time that used to be slow," he says, "and I
say to myself, ‘They wouldn’t be here now if it weren’t for the
one-off promotions I can do with our rules system.’"
Which is right for you?
BRMS tools cover everything from open-source languages to
full-blown enterprise systems. If you want to test the BRMS water,
you could begin with Jess, which is a free download.
But major development projects require collaborative
communication between all participants - business analysts, coders,
the chief executive, end-users, finance directors, and so on. And
that means a BRMS with all the bells and whistles.
Ilog’s JRules (the Java version) and Rules (the C/C++ version),
and Fair Isaac’s Blaze Advisor are enterprise tools with debugging,
testing and analysis tools. Enterprise customers that need blinding
speed but are willing to live with limited tools would do well to
consider PST's Official Production System for Java (OPSJ).
An IT department that has staff already trained in OPS or the C
Language Interface for Production Systems (Clips) might want to
take a look at Haley’s Authorete, PST’s Clips/R2, or Sandia
National Laboratories’ Jess.
New tools with new twists to consider include PegaRules from
PegaSystems, and Corticon, which has a spreadsheet interface for
rules input.
The more polished products, such as JRules or Blaze Advisor,
make self-service rule changes easier for business analysts, but
experts in business rules logic must always be available to ensure
the BRMS works smoothly. According to Gartner analysts, a properly
implemented and supported BRMS can cut IT operating costs by
between 10% and 15%. And that estimate doesn’t take into account
the soft benefits of rapid response to shifting business
demands.
The idea of isolating and consolidating business logic may seem
odd, but the pay-off is all but inevitable.
James Owen is a senior knowledgebase consultant at
Knowledgebased Systems and has worked with expert systems since
1989