Business Rules, At What Cost?

by Ronald G. Ross

This column originally appeared in the Jan./Feb. 1994 issue of the Data Base Newsletter.

Recently, several knowledgeable database system designers at a major corporation confronted me with excellent questions regarding business rules. They posed these questions as modeling issues. My response (not what they expected) was that the questions actually represented business issues. Let me explain.

As related by these designers, the company literally has hundreds of products. In itself, this is not unusual. Each of these products, however, is highly variable. In modeling terms, this is reflected by the many special attribute types needed to describe different variations, as well as by the "hundreds or thousands" of business rules (a.k.a. editing constraints) necessary to ensure correctness. It is as if, they suggested, each instance of product acts as its own subtype.

The designers wanted to know whether modeling so many variations in data types and business rules is feasible. If so, they naturally also wanted to know the cost. If as high as they feared, the implication would be that developing models for these business rules simply may not be practical.

The answer to both their questions is yes -- yes, it is feasible, and yes, the cost would be too high -- but I believe these are not the right questions. If the business rules are valid (i.e., understood correctly), they will be "modeled" -- maybe not until implemented in procedural code, but they will be "modeled."

Instead, the company should ask what the total cost of the complete information system (code and all) will be. My guess is either that no one really knows, or that if they think they do know, they probably are off by an order of magnitude or more. Then the company should ask whether having so many product variations really is cost-effective for the business. My hunch is that this is a company with at least one business process in dire need of re-engineering.

This hardly should come as a surprise. In one way or another, database professionals always tend to become lightning rods for sticky organizational questions of this type. The natural professional impulse is to address such problem head-on. Unfortunately, playing the role of shock troop in a frontal assault on organizational politics generally does not lend itself to long and stable careers in one place.

My advice therefore was the following. Their best course is to encourage significant user participation (and sign-off authority) in developing nonprocedural, English-language definitions for the business rules. (I also suggested graphic models if helpful.) If head-high stacks of business rules fail to raise corporate eyebrows about what really is happening in the business, what will?

standard citation for this article:

Ronald G. Ross, "Business Rules, At What Cost?" Data Base Newsletter, Vol. 22, No. 1 (Jan./Feb. 1994), URL: http://www.BRCommunity.com/a1994/a501.html.

September 2005
The Fin de Siegle Legacy Mindset
By Ronald G. Ross -- (November/December 1999)

August 2005
Analysis Paralysis Just May Save Your Life
By Ronald G. Ross -- (September/October 1999)

July 2005
If We Had Started Coding Already...
By Ronald G. Ross -- (July/August 1999)

June 2005
Your Core Business Processes Need a Rule Engine
By Ronald G. Ross -- (May/June 1999)

May 2005
Four Things Wrong with the Way We Develop Information Systems
By Ronald G. Ross -- (January/February 1999)

April 2005
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross -- (November/December 1998)

March 2005
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross -- (September/October 1998)

February 2005
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross -- (May/June 1998)