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:

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:

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.

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:

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.

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.

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.

# # #