Business Rule Reuse in the Real World

David   Christiansen
David Christiansen Application Architect, Liberty Mutual Insurance Group Read Author Bio || Read All Articles by David Christiansen

Rule reuse may not be what you think it is.  When we talk about reuse, we usually think of it in terms of software components that can be accessed a number of different ways.  As a result, it's natural to think of rule reuse in the same way:  software components based on rules that can be accessed using a variety of transport mechanisms or input formats.

It's not about software component reuse.

We can draw on insurance for a classic example of this type of reuse.  Automated underwriting is a common application of business rules technology, and it typically needs to be accessible a variety of ways:  in real time as a web service for new business written over the web, and as file-based batch process for renewals and new business from a legacy application.  This is a form of reuse, but it's not business rule reuse.  It's simply traditional software component reuse.

Let's start with a general definition of rule reuse.  In a moment, I'll propose a more structured definition that will help us understand how to apply the concept.

Business rule reuse means applying a single rule to more than one situation.

Reuse of rules occurs when you can write a rule only once and have it apply to any number of situations.  This implies that to really be able to reuse a rule, you have to be able to apply this rule to a new situation without changing the rule.  I call this the litmus test of rule reuse.

More specifically, business rule reuse is the ability to apply a single rule or set of rules in any number of business contexts as defined by known business dimensions.

In this definition, I've adapted two terms, business dimension and business context, to help clarify what I mean by rule reuse.  We'll define these terms in turn, hopefully leading to a better understanding of business rule reuse.

Business dimensions define the context in which a rule is used.

A business dimension is a measurable aspect of the way a business grows and varies its products and services.  In most businesses, these will include some aspect of time (future products versus current products and past products), locale, product type, customer type, transaction type, and others.  These can be defined differently for different types of businesses, so long as they are high-level dimensions of the business.

Take the insurance industry as an example.  Within a single insurer, insurance products (and their rules) vary by several business dimensions, including the following:

  • Time:  Insurance products change over time, as do their associated business rules.  This is often driven by legislation at state and national levels.

  • Locale:  Insurance products also vary geographically.  Homeowner's policies (and their related business rules) vary considerably between states.

  • Product Type:  Insurers usually carry a number of different product types, such as homeowner's, general liability, auto, etc.

Each of these represents a business dimension.  The idea of business rule reuse is to be able to reuse rules across all business dimensions.

A given combination of business dimensions that define the applicability or effectiveness of a rule is called a business context.  Take the following rule for example, assuming that state, policy effective date, and line of business are known business dimensions:

Felony Conviction Rules

Rule #1:  Effective December 31, 2004, applicants for general liability policies in Texas, Colorado, or Wyoming with a felony conviction will be automatically declined.

Rule #2:  Effective October 31, 2004, applicants for general liability or homeowner's policies in California, Florida, and Alabama will be automatically referred for senior underwriter review.

Rule #3:  Effective January 1, 2002 until December 30, 2004 ...etc.

Hopefully you can see how the felony conviction rules vary by the three business dimensions.  The particular values of each dimension under which a business rule applies is called a rule context, as illustrated in the following table:

Felony Conviction Rules
States Effective Date Expiration Date Line of Business Rule

Texas

Colorado

Wyoming

12/31/2004 None GL Rule #1:  Automatically decline applicants with a felony conviction

California

Florida

Alabama

10/31/2004 None GL

Home
Rule #2:  Automatically refer applicants with a felony conviction to a senior underwriter

Each row of green is an individual context for the rule to its right.  It's important to note that a single rule can, and often does, apply in more than one context, as shown in the example below.

Felony Conviction Rules
States Effective Date Expiration Date Line of Business Rule

Texas

Colorado

Wyoming

12/31/2004 None GL Rule #1:  Automatically decline applicants with a felony conviction
California

Florida
12/31/2002 10/30/2004 GL

Home
 
Alabama 7/1/2002 10/30/2004 Home  
Alabama 8/1/2001 10/30/2004 GL  

California

Florida

Alabama

10/31/2004 None GL

Home
Rule #2:  Automatically refer applicants with a felony conviction to a senior underwriter

This is what I mean by rule reuse.  Rule #1 exists independently from the range of business dimensions (collectively called a business context) that determine when it applies. The ability to make rules independent in this way is the key to reusing rules.

Reduce the number of rules by separating the rule from its context from day one.

If you can separate your business rules from the contexts in which they apply, you will drastically reduce the number of rules that you have to collect, manage, implement, and maintain.  This significantly reduces the total cost of ownership of a rule set.

I know what you're thinking:  What about all those rule contexts?  Someone still has to deal with all of these, right?

Yes.  Absolutely.  But rules contexts, unlike rules verbiage, are very easy to collect, catalog, and analyze.  They're just simple data, whereas rules are complex sentences.  If you store business contexts for rules in an appropriate tool (like an RDBMS), you can sort them any way you want, creating different views of the data depending on which particular business dimension you are concerned about at the moment.  Additionally, with the right type of architecture in place, these contexts can be managed directly by the business stakeholders and referenced by the rule engine in runtime.  Now that's business agility.

For most businesses, rules don't change nearly as much as their context does.  Separating rules from their contexts allows for the rapid evolution of a rule set without IT-intensive development efforts.

You can reuse your business rules, but you have to begin with the end in mind.

Separating business rules from business context is the key to real world reuse of business rules.  By reusing rules, you can provide business agility with fewer rules and thereby reduce the total cost of ownership of a rule-based implementation.

It is considerably easy to collect, manage, and maintain a rule set when the rules and their contexts are not intertwined.  That said, if you want to reuse your rules then you need to start with that intent, otherwise you won't realize the benefits of this approach.  Whatever methodology you use to 'harvest' rules -- whether it is a use-case based approach or a taxonomy-based approach -- it has to support the separation of context and rules.  Otherwise, you will certainly fail to provide rule reuse.  You can't leave this type of analysis entirely to IT, nor can you take this approach on the business side and ignore it in IT.

IT and business alignment is the key to this approach.  Both groups must think about the business and its rules in terms of business dimensions, business contexts, and business rules.  Your methodologies, artifacts, and systems need to be aligned with these concepts in order to make business rule reuse a reality.

The good news is that this type of alignment is not that difficult.  The value of these concepts is in their ability to make complex business problems simpler.  That's the beauty of the separation of context and rules:  it makes everything easier.  From analysis to architecture and implementation, context sensitive rule systems are cheaper, simpler, faster, and better.

Example:  Contingency rules are triggered by unpredictable events

Another benefit of context and rules separation is the ability to create contingency rules.  Contingency rules are business rules that are put into place for anticipated but unpredictable events like terrorist attacks, wildfires, and hurricanes.  For example:

Natural Disaster Rules

Rule #1:  Automatically refer all homeowner applications to a senior underwriter in a state that is experiencing a widespread natural disaster such as a hurricane or wildfire until the risk from the hazard has been eliminated.

Contingency rules are a great way to implement business continuity plans that would otherwise have to be implemented in manual procedures.  If you've separated rules from their contexts, and created an implementation architecture that allows you to add new contexts 'on the fly', then contingency rules can be very easy to automate.

Let's use an example to illustrate how this works.  The following chart shows the natural disaster rules and contexts for an imaginary insurance company as of July 1, 2004.

Natural Disaster Rules
States Effective Date Expiration Date Line of Business Rule
        Rule #1:  Automatically refer all applications to a senior underwriter
         

Notice that there are no contexts for this rule, and that all of the verbiage about states and lines of business has disappeared.  That's because we've separated the business rule from its business context, of which state and line of business are a part.  In other words, this rule is not in effect anywhere in our imaginary insurance company.  It's completely dormant.

But then, on July 2, meteorologists identify a new major hurricane, Hurricane Dave, expected to make landfall in Florida within a few days.  The company's senior underwriters decide that they want to suspend automated underwriting of homeowner's and automobile applications in Florida until Hurricane Dave has passed.  They immediately put Rule #1 into play by creating a new context for it, as shown below, agreeing that they will meet again in a week to decide whether to extend the suspension.

Natural Disaster Rules
States Effective Date Expiration Date Line of Business Rule
Florida 7/2/2004 7/11/2004 Home

Auto
Rule #1:  Automatically refer all applications to a senior underwriter
         

Because the company's automated systems are architected to support the separation of business context from business rules, the moment this context is created it takes effect, and all home and auto applications in Florida are automatically routed to the senior underwriters to determine whether they are at risk from Hurricane Dave.  And what about the other states and lines of business that shouldn't be impacted by Hurricane Dave?  It's business as usual for them.  For the last time -- that's business agility.

# # #

Standard citation for this article:


citations icon
David Christiansen , "Business Rule Reuse in the Real World" Business Rules Journal Vol. 6, No. 3, (Mar. 2005)
URL: http://www.brcommunity.com/a2005/b225.html

About our Contributor:


David   Christiansen
David Christiansen Application Architect, Liberty Mutual Insurance Group

David Christiansen is an Application Architect at Liberty Mutual Insurance Group, where he has successfully introduced the use of business rules technology to its Regional Agency Markets SBU. He is the creator of the Enterprise Rules Services Framework, an application framework for independent, standards-based services built on business rules technology. This architecture and its concepts of rules reuse have been so successful that an internal business rules implementation center of excellence has been created to spread their value across the entire organization. David can be contacted at david.christiansen@insightbb.com.

Read All Articles by David Christiansen
Subscribe to the eBRJ Newsletter
In The Spotlight
 Ronald G. Ross
 Silvie  Spreeuwenberg

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.