Organizations that have embarked on a business rules approach have made this important decision because they realize that, by better managing their existing business rules, they can gain some kind of edge.  Yet, despite this fact and years of work in the business rules field, it is still the case that many organizations struggle with how to realize significant value from adopting a business rules approach.  While we all intuitively feel that we know what a rule is when we see one, most organizations find that one of the core reasons that they struggle with rules is the lack of agreement on this most basic question:  "What is a business rule?"

Most organizations that start down a business rules path face a basic problem:  the more that an organization begins to see the world through a business rules lens, the more everything starts to look like a business rule.  And, if everything is a business rule, then a business rule is so amorphous that it becomes difficult to see how it adds any value.  It is as if we see the world as being filled with levers.  The keys to our cars are levers, the door handle on the car is a lever, the shifter in the car is a lever … and so on.  It is not wrong to say that each of these is a lever, but it really does not help our understanding much to describe them that way.  In much the same way, describing too many different elements as simply a business rule may not be wrong, but it certainly does start to lose its explanatory power if we use it too widely.

For many organizations, the focus on business rules has to do with how to create consistent, structured, and repeatable behavior.  The kinds of rules that support this need are referred to as "structural rules."  Structural rules can be implemented as procedures within an organization or by using various automation technologies.  These kinds of rules define exactly what is meant by some term (e.g., a "Preferred Customer") or when a particular business situation exists (a customer is "Upgrade Eligible").  These rules are a completely different animal from rules that capture business motivations.  Those rules are referred to as "operative rules."  Rather than focusing on behavior, operative rules focus on capturing motivational statements about organization intent (e.g., it is obligatory that a customer service representative visually inspect the renting party's driver's license) while acknowledging that there may be exception cases that allow the general rule to be violated.  The following definitions^[1] more fully capture the differences between the two:

• Structural rules prescribe criteria for how the business chooses to organize ("structure") its business semantics.  Such rules express criteria for correct decisions, derivations, or business computations.
  
  
• Operative business rules focus directly on the propriety of conduct in circumstances (business activity) where willful or uninformed actions can fall outside the boundaries of behavior deemed acceptable.  Unlike structural rules, operative rules can be violated directly.

Understanding the difference between these two major kinds of rules is the first key to understanding that not all rules are created equally.  Most organizations following the business rules approach are looking for concrete returns within specific initiatives.  Because of this, most business rules initiatives focus their attention on structural rules rather than operative rules.  By focusing only on structural rules, organizations can help eliminate the analysis-paralysis often associated with business rules initiatives.  But, even within the realm of structural rules, there remains a need for multiple ways of analyzing and constructing rules to make these rules more comprehensible and manageable.  The approach to this is to make use of "rule metaphors" that establish patterns for constructing groups of related rules.

Business Rules as a Metaphor

Most of us learned what we know about metaphors in a high school English class.  We learned that metaphors are a literary device where a word or phrase is applied in a literal way to something to which it is not literally applicable.  But, there is a more general meaning of metaphor that is applicable outside the literary domain.  In this case a metaphor is:

A thing regarded as representative or symbolic of something else, esp. something abstract^[2]

Because a metaphor is a simplified abstraction of some other object, we accept that the way we are describing the thing the metaphor represents is somehow restricted by the very use of the metaphor.  The tradeoff being made is that the metaphorical abstraction makes it easier to think about certain problems by allowing them to be simplified.  People use metaphors everyday to simplify their communication.  Phrases like game-plan, recipe for success, and elevator-talk are all examples of the kinds of metaphors that have become so ingrained in our everyday conversation that they are hardly noticed.

Business rules is just such a metaphor.  There is no such thing really as a business rule.  We use the concept because it helps us better understand and manipulate certain kinds of problems.  In fact, for years most organizations have captured what we now think of as "structural rules" in a variety of other ways, including requirements documents, process flows, and information models.  The promise of the business rules approach is that certain kinds of problems will be structured in a way that allows those problems to be more easily understood, changed, and governed than they would have been otherwise.

The irony of the success of the business rules movement is that organizations find themselves awash with rules.  Even limiting the scope of rules efforts to just structural rules still leaves a huge body of rules to be dealt with at most organizations.  Once organizations reach this point, they have discovered that the simple business rules metaphor lacks enough power to allow them to successfully deal with all of the things identified as rules.  For most organizations, this begins once a particular domain of rules contains more than a couple hundred rules.  It turns out that the broad rules metaphor is too general for a large set of rules.  What is needed is a way to organize rules to make them easier to comprehend and govern.  It probably is not too much of a surprise to hear that what organizations need is more metaphors!

Business Rules and Other Metaphors

If you can accept that the business rules metaphor helps us better deal with certain problems, then it is probably not too much of a stretch to accept that this is not the only metaphor we need.  In fact, it makes sense to view business rules as part of a business analysis framework that includes a variety of analytic metaphors that, when combined, allow us to better understand and specify business solutions.  Business rules are deeply intertwined with two other key metaphors for almost every situation where business rules come into play.  The first of these is the business process metaphor. 

Figure 1.  Elements of a Business Analysis Framework

Business Rules and Business Processes

Business processes define the set of behaviors that can be performed and the paths that can be taken to perform these behaviors.  To support the creation of these definitions, each business process contains a series of activities that capture the work done and also the paths or flows that show the order in which those activities are performed.  Business processes are all about documenting what work is performed when and by whom.  However, it is quite common for organizations to also write business rules that indicate that some kind of activity should be performed.  For example:

If the customer has a credit score that is less than the acceptable value then decline their application.

This business rule has a behavior embedded within itself.  That behavior is to "decline their application."  Declining an application is a process that involves many activities along the way.  In other words, "decline application" is probably best understood as a business process.  This leads to the first principle for organizing business rules:

1. A business rule should never incorporate behavior.

Behavior is best understood as a process, so keep behavior out of your business rules!

If a business rule should never incorporate behavior because behavior is best captured using business processes then what is the proper relationship between business rules and business processes?  The intersection between business rules and processes is the decision.  A decision is a point in a business process where paths come together and a choice has to be made about which path to follow.  An example of a decision is the determination that a Customer has a VIP status.  While some information (e.g., Customer Name, Customer Address, Date of Birth) is information that is simply captured by an organization, other information is driven by business decisions about how to categorize and quantify information that the organization possesses.  These kinds of business decisions are business policy driven and they embody how an organization implements the policies that control how work flows through a business process.  For example, an organization might decide to redefine the VIP Customer piece of information.  By making more or fewer customers eligible for the status, the organization can greatly impact how those customers flow through their business processes.

Figure 2.  Decisions Control Path Selection

But, as we learned above, a decision is something within a process that examines a piece of information.  The information itself is outside of the process.  So, where does that leave our business rules?

Business Rules and Information

The answer to this question involves the second business analysis metaphor tightly intertwined with rules — information.  One of the most important insights over the last decade in regards to managing business rules involves understanding their relationship to information.  To understand this, it is probably best to start by asking why business rules exist.  By far the most predominate reason that organizations create rules is to support the creation of information.  Going back to our previous example, the VIP Customer is a business policy-driven piece of information, so it should have rules that specify how to derive it.  For example:

A Customer having Excellent Credit and having transacted Tier1 Level Amount over the last 12 months is a VIP Customer.

So, the second principle of organizing business rules is:

2. Organize business rules around the piece of information that they derive.

This principle of information-centric governance is the most important element that organizations should embrace as part of their rule governance approach.^[3]  One of the reasons that this approach is so important is that it allows a large set of rules to be broken into discrete and independent groups of rules.  These groups of rules are independent because each of these groups has no visibility into the rules in any other group.  Instead, each group of rules may refer to the information derived by another rule group or to other information that is known to the organization.  This leads to the third principle of organizing rules:

3. Business rules groups should have no visibility into rules outside of their own group.

In combination with Principle #2, this implies that business rules are a way of deriving information that is part of an organization's overall information model.  This means that there is no separate model for the information that is produced by a business rule.  So, when a process, rule, or any other business analysis element examines a piece of information, it does not know whether the information was derived by rules or not.  That is important because whether or not a piece of information is rule-derived can change over time.  In our previous example, the VIP Customer was previously a piece of static information about the Customer.  The VIP Customer information would only have been changed when it was updated by an Account Manager.  Let's assume that at some point more targeted marketing required that piece of information to become business policy driven.  Suddenly, the information has become rule driven.  But, from the standpoint of any process that was already using that piece of information, this is entirely transparent.  So, any process that previously had a variation for VIP Customers should be agnostic to the fact that the VIP Customer information became rule driven instead of simply being static information.  This brings us to another principle for rule organization:

4. Other metaphors that make use of information derived using business rules should not be aware that that information is derived by those rules.

While these four principles do form the core basis for organizing business rules, they still do not provide the level of cohesive structure that organizations need to manage a large set of rules.  What is needed is more metaphors!

Metaphors for Rule Groups

The examples we have looked at up to this point help illustrate some of the general guidelines for how rules interact with other analysis metaphors.  However, these examples do not deal with managing multiple rules within a given rule group.  The need for multiple rules in a single rule group happens for a variety of reasons.  One such scenario is when there are simply multiple independent ways that a piece of information can be derived.  So, following on our previous example:

1.  A Customer having Excellent Credit and having transacted Tier1 Level Amount over the last 12 months is a VIP Customer.

or

2.  A Customer having a VIP Account Status is a VIP Customer.

In this case, there are two rules, each of which can independently indicate that a Customer is a VIP.  While many simple derivations can be handled just by grouping together a set of rules that derive the same information, this is not enough in some cases.  For example, the set of rules may be both large and the individual rules not fully independent.  One variation of this is when more than one rule can be triggered for the same concept, but the rules derive different values for that information.  To illustrate:

1.  A Rental with a Rental Location Type of Airport and a Seasonal Factor of High-Demand and a Vehicle Class of Intermediate has a Base Rate of Intermediate-1.

and

2.  A Rental with a Rental Location Type of Airport and a Vehicle Class of Intermediate has a Base Rate of Intermediate-2.

In this example, the rules can produce a set of values for the same piece of information so that the Base Rate can be both Intermediate-1 and Intermediate-2 at the same time.

Another flavor of the scenario where multiple rules are needed in a single group is where the rules should not be triggered individually.  In other words, the rules are mutually exclusive.  In these cases, the rules will look similar to one another.  For example:

1.  A Rental with a Rental Location Type of Airport and a Seasonal Factor of High-Demand and a Vehicle Class of Intermediate has a Base Rate of Intermediate-1.

and

2.  A Rental with a Rental Location Type of Airport and a Vehicle Class of Intermediate and that has not had Rule 1 triggered has a Base Rate of Intermediate-2.

Rule Groups using a Decision Table Metaphor

In both cases, a large set of rules would become very difficult to handle when written as individual rules.  So, instead of accepting this, we use a metaphor that makes it much easier to understand and manage the rules.  A decision table is an example of one kind of metaphor that can be used for this.  In a decision table, each row represents a rule and the columns represent all the information that is available for each rule to be tested.  The last column represents the information that will be derived if the rule conditions are met.

Figure 3.  Decision Table with Ordered Mutually-Exclusive Rules

Using a decision table is powerful because it does a number of things at once:  it eliminates much of the redundant wording, making it simpler to understand the rules; it visually groups the rules into a single cohesive structure; and it allows characteristics like the rules being mutually exclusive and ordered to be expressed as part of the table definition rather than needing to be included in each rule as was the case in the original example above.

Rule Groups with Decision Tree Metaphors

Decision tables are an extremely powerful metaphor for representing rule groups where all the rules share a relatively small set of common information that is tested across all the rules in the group.  However, many business problems do not fall within these parameters.  It is quite common for a piece of business information to require multiple rules to be written in order for it to be derived and for these rules to share relatively few pieces of information.  Within a decision table, this would quickly result in a very large set of columns with relatively few values filled in per row.  This kind of sparse table is not a way of representing rules that helps organizations manage them.  An alternative approach is to make use of the Decision Tree metaphor.  In the example below, two separate outcomes are shown.  All of the boxes linked to the outcomes (captured in red) represent a single rule in the same way that a row in a decision table represents a rule.

Figure 4.  A Rule Group Represented as a Decision Tree

Using a Decision Tree metaphor allows arbitrary combinations of pieces of information to be combined to support the derivation within a rule group.  Like a Decision Table, a Decision Tree eliminates much of the redundant wording, making it simpler to understand the rules; it visually groups the rules into a single cohesive structure; and it allows characteristics (like the rules being mutually exclusive and ordered) to be expressed as part of the tree definition rather than needing to be included in each rule as shown earlier.  However, the visual structure accommodates variations in the rule that are problematic to capture within Decision Tables, albeit in a less compact and slightly more complex representation than what a Decision Table provides.

Rule Groups and Generic Rules

There is one final issue that commonly causes organizations to struggle with managing rules.  The problem involves situations where rule groups have grown very large because many rules are needed to accommodate the many permutations of values in the information the rules are testing.  For example:

Figure 5.  Decision Table with Information Combination Explosion

This kind of repetitive pattern is very common within rule groups.  When the number of combinations is very high, the pattern explodes into an unmanageable set of rules.  The key to reducing the number and complexity of rules in these situations is to remove the information that is embedded in the rules and turn it into static information.

In this example, the relationships among Locations, valid Vehicle Types, and valid Vehicle Option Packages would be maintained as part of the information model rather than in rules.  We can visualize this information as shown in Figure 6.

Figure 6.  Moving Information Out of Rules 

The rules then can be rewritten as "generic" rules that assume the information model contains the other information.

A Rental has Available the Vehicle Option Packages that are Available for the Vehicle Type and also Available for the Vehicle Location and also Available for the Vehicle Class.

All of the rules in this table and all of the remaining variation can be represented using this single generic rule.  How is this possible?  If the information model already contains relationships among the information, then the rules don't have to embed these relationships.  Maintaining the information statically makes it easier to see that the individual rules did not reflect different business policy decisions.  Rather, they were just a repetition of the same business policy for every variation of the underlying information.  So, we have identified another principle for organizing business rules:

5. Rules should not embed information within their definition.

Takeaways for a Business Analysis Practice

Organizations are eager to find a way to make a significant impact on the amount of business effort required to define and maintain business policy-driven decisions.  Business rules have been held out as an approach that can help organizations to achieve this goal.  However, simply adopting a business rules approach has not been a successful path for organizations that have any significant amount of rules to define. 

The key to managing a large set of rules is to apply a strong framework for organizing those rules.  Five core organizing principles for doing this have been laid out in this article.  These principles provide a mechanism for organizations to understand where to draw the boundaries of what to define as a business rule.  However, this only begins to narrow the problem down.  Managing the remaining rules involves segmenting them into well-defined structures that have well-understood visualizations of the way that rules are grouped together to create information.  Metaphors are the mechanism that organizations need to effectively organize rules within rule groups.  Thus, we have the final principle for organizing rules:

6. Rule groups should always be constructed using the metaphor that best simplifies creating and understanding the set of rules within that rule group.

This article only presents some of the basic variations on the more common business rule metaphors.  In order to be successful with business rules, a business analysis practice will need to develop a comprehensive definition of the metaphors they will use within their organization and socialize this definition throughout.

[1]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF  

[2]  Definition of Metaphor, via google.com (define:metaphor).  

[3]  Decision Management is a commonly used but confusing term for this approach since a decision is an element of a process that references the information that is derived by a business rule.  Multiple decisions in different processes may reference the same piece of information, so governing by decisions would be undesirable.  

# # #