Business rules have become a hot topic, often being discussed along-side Business Process Management (BPM).

1. Business rules have become a hot topic, often being discussed along-side Business Process Management
(BPM). BPM has historically meant workflow, or automating the logic associated with how work moves.
BPM has grown to include many elements of a service-oriented solution orchestrated by workflow,
including business rules. But business rules stand on their own, dealing with the logic associated with
decisions. While they may be integrated into a BPM environment, business rules can and do work quite
independently of BPM, integrating with legacy applications, non-flow-based applications and even
standing on their own.
Increasing Interest in Business Rules
According to Gartner Vice President and Distinguished Analyst Jim Sinur, the pursuit of organizational
agility explains much of the interest in business rules. Any organization is defined by its decisions such
as:
What customers to go after and in what markets
How to price products
Who should receive differentiated service
Whom to offer credit
What revenue to recognize.
Literally thousands of strategic and tactical decisions are made daily and they reflect an organization’s
policies, goals, and reputation. These decisions are guided by internally created policies and externally
driven regulatory policies such as the Sarbanes-Oxley Act (SOX) and the Healthcare Information
Portability and Accountability Act (HIPAA). The basis (or rules) for these decisions can change often. In
fact, business decision logic changes more often than work movement logic (workflow), the domain of
BPM. An organization’s ability to quickly change how decisions are made based on market or
competitive change has become a key success factor in corporate survival.
Business rules are designed to externalize the logic of business decisions from classically written
procedural applications or automate decisions made manually because they’re too hard to automate in
some other way. By extracting this logic into its own tier, just as data was extracted 20 years ago into
database management systems, business rules can be created and maintained independently of the
applications that consume them. So an organization can quickly change its pricing decision
independently of the applications that need to price products (e.g., Website or call center).
What Is a Business Rule?
Any logic written to automate is a rule, but business rules really focus on a subset of logic. Business rules
deal with decisions made within an organization whose specification is owned by the business. Here’s
one example: “Should our insurance company approve and pay this claim?”
Business rules underlie any decision; they’re the statements that together guide us to the resulting
decision. An example associated with the claim decision might be, “If the claimant’s policy is active and
the claim occurred while working, then pay the claim.”

2. When done well, business rules-based automation delivers consistency in the decisions an organization
makes. Rules most often attack deterministic problems, where the organization is looking for
consistency. A lack of consistency can cause significant risk and cost. If an insurance company approves
claims that are being processed when the claims should be denied, economic loss occurs. On the flip
side, where claims that should be paid are rejected, the insurance company is now exposed to legal risk.
Rule vs. Decision
Rarely is a single business rule the basis for making any decision. More often, many rules interact to
form a decision. An underlying concept in a decision architecture is that business decisions are the
atomic unit we should be focused on, not the rules. Business rules are in fact underlying artifacts of
business decisions. Business rules are critical to implement decisions, but they should not be the center
of the architecture. Any more than a line-of-code is the center of the architecture for an application.
This article focuses on the idea of a decision architecture, not a rules architecture. It will discuss at what
level decisions should be identified and managed, the organizational impact of a decision architecture,
and an IT perspective on a decision architecture.
We’ve been working with computer-based automation for 40 years. But a non-scientific study of about
50 organizations suggests a low percentage of business decisions are automated. They’re being made by
people based on written policies, training, or organizational history. Why? The answer commonly heard
isn’t that these decisions can’t be coded; it’s that the technology cycle associated with changing that
code as the decision needs to be changed is too long and expensive. The business cycle for decision
change is far faster than the technology cycle for changing the decision automation.
Sophistication in Decisions
Organizations want to make decisions that are far more sophisticated than they’re able to make using
people to make decisions manually, or using “coding” to automate. These decisions are made up of
hundreds of rules. Banks would minimally like to make consistent decisions on several factors associated
with a decision such as a customer request to refund overdraft fees:
Does this person have a history of overdrafts (how often and over what time period)?
Does this person make money for us (i.e., large average balance in a non-interest-bearing account)?
Banks want to look well beyond such simple rules associated with a customer’s checking account. Here
are extensions to the simple rules set:
Does this customer have other products with the bank? If so, how many?
Are those products profitable?
How profitable overall is this customer? Are most of his or her transactions via the Internet vs. more
expensive branch interaction?
What’s the overall customer value score for this customer (extend profitability to include potential)?

3. Is the bank in a selling cycle with this customer? (If he or she is applying for a mortgage, I don’t really
want to create dissatisfaction by forcing these fees.)
Is this customer in a customer service cycle for some reason? (Is there underlying potential for
dissatisfaction you don’t want to exacerbate?)
Does this customer have some distinct value to the bank? (Perhaps this customer is eccentric and
regularly overdrafts, but has a $50 million family trust with the bank.)
Does this customer hold an important party-role relationship? Maybe he is the son of the chairman of a
Fortune 10 company that does business with the bank.
I have just expanded the decision from two simple conditions (with about three potential values per
condition) to nine conditions (again, with about three values). This expands my potential business rule
combination from nine (3) to 19,683 (39).
This combinatorial explosion is at the heart of the number-one issue with business rules automation and
the focus on a decision architecture: How do I decompose sophisticated decisions into atomic units
where the decisions can be owned, managed and then combined into higher-level decisions? How do I
build decision logic that deals with the combinatorial explosion associated with sophisticated decisions
to assure that my decisions are reliable? We need decisions that are complete in their definition and
consistently provide the right answers.
The Decision Architecture
Business rules are the underlying artifact of decisions and decisions are where we’ll now concentrate.
The decision architecture focuses the organization analysis on decision points. Should I approve this
overdraft rebate request? This is a simple or complex decision composed of business rules. This decision
is analyzed and decomposed into many component decisions:
1. There is one lower-level decision on fee rebate, which is based on the value of this customer to the
checking account business unit.
2. There are one or more decisions being made on the customers’ value in each of the other product
lines within the bank.
3. There is a decision about the value of the customer based on the presence of an active sales cycle
such as a mortgage.
4. Finally, these many decisions must be combined to form a top-level or final decision based on the
overall best interest of the bank.

4. As you consider this simple two-level hierarchy, the decision architecture begins to emerge. At the lower
level, you have multiple atomic decisions that are each owned by a different product line. Each product
line wants and needs to own the criteria and execution of these decisions that are provincial to their
best interests. The business rules associated with each product line’s decision should be owned by those
product lines. They should have the ability to create and maintain the rules and associated decisions.
But, at a higher level of authority, these decisions must be combined to form the final decision. The
channel owner might do this. It might be done with prejudice to the product line since the fee in
question is associated with income to their product line. But a product line-based decision won’t be
taken if the judgment is that a decision in its favor (keeping the fees) puts the bank’s overall business
with a valuable customer at risk.
Applying the Decision Architecture
The decision architecture is a natural fit with business organizations. For as long as we’ve had computer-
based systems, the business has wanted to maintain authority and control over them. But far too many
of the core decisions made within a business process have been excluded from automation because of
the need to change with far greater agility than historic system automation allowed. Business controlled
rules and the decision architecture allow for three key values the business has sought:
1. Control at a level of authority and knowledge. The business rules-based decision architecture lets
the responsible business authority or organization own and control the atomic-level decision.
2. Control with agility. Business rules and the decision architecture let users within the business who
have authority over the decision specification and the knowledge to describe the specification take
greater control over the creation and modification of the actual business rules logic. This can be done
independently of the remaining technology that consumes the decision, allowing almost instant change
of a given decision as it feeds into higher-level decisions or consumption of that decision service.
3. Consistency and reuse. By segregating decisions into independent services, a given decision used in
multiple points of automation in an organization can be owned, controlled and maintained by an
authority, but it’s consumed by many different processes in an organization. This can eliminate
redundant implementation of the same logic, which can lead to inconsistency and higher costs.
Business-Friendly Interface
To achieve distribution of creation and maintenance of any give atomic decision service, tools must be
provided that business-side users can consume. This means moving away from a programming
environment to a modeling environment. We have seen the impact of this shift before in the movement
away from restrictive computer architectures (e.g., COBOL) and toward more flexible ones (e.g., Lotus 1-
2-3). Such changes have let business users perform key tasks and make decisions in dramatically shorter
timeframes. What’s happening in the business rules market is similar. This isn’t about setting up a new
programming paradigm. Instead, it offers a step function change that provides the business with usable
tools to accomplish the creation and maintenance of decision automation assets.

5. The Advantages of a Model-Driven Architecture
But be aware of the difference between a true model-driven environment and those that only pretend
to be. In a true model-driven environment, there’s no underlying programming language and no
procedural logic (only declarative). The modeling environment should let you completely model any
business decision logic. When there’s an underlying technical language, you can be sure some
reasonable percentage of the problem you seek to solve can be solved only by manipulating the code vs.
the model. These environments always break down and cause the organization to work at the lower-
level language, turning the implementation into another coding exercise. When this occurs, you’ll lose
all the values associated with the business rules-driven decision architecture.
A Technology Perspective
Business rules are intended to be declarative, not procedural. This means that, in the business rules-
based decision architecture, the rules language describes what should happen, not how it should
happen. In many business rules systems that describe themselves as declarative, you’ll find many
procedural constructs in their lower-level languages. But why should we care?
A primary benefit of the decision architecture using a declarative modeling environment is that, when
decisions are dealt with atomically (meaning within a given unit of logic to describe a given decision
completely), computer science and mathematical principals can be used to verify a given decision is
reliable. Whenever we build logic, we seek to test the logic to ensure it’s correct. Using the declarative
decision architecture, a given decision can be verified to be:
Complete (meaning there’s no missing logic)
Unambiguous (meaning there’s no conflicting logic)
Compressed (meaning there are no extraneous or overlapping rules)
Non-recursive (meaning there are no unintended logical loops).
These qualities become essential when you begin modeling sophisticated decisions, such as the one we
described with more than 19,000 logical rule combinations. If the modeling environment can’t find
these problems, you’re lost. This is because classic testing won’t deal with this combinatorial explosion.
At this level, the testing problem is intractable.
Additionally, when decisions are decomposed to an atomic level and exposed as services, the cost of
developing and maintaining logic can drop dramatically while increasing the value of technology and
automation to the business. The business rules-based decision architecture helps drive a primary
business value around agility and control while concurrently attacking one of the IT organization’s
largest costs— development and maintenance.