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?

# # #