untitled
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?
|
|
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)
January 2005
Business Rules as Customer Interface
By Ronald G. Ross -- (March/April 1998)
December 2004
Components and Business Rules: Do They Connect?
By Ronald G. Ross -- (January/February 1998)
November 2004
The Policy Charter: A Small-Sized Picture of the Big Picture
By Ronald G. Ross -- (November/December 1997)
September
2004
Implementing
Application Packages: Is There A Better Way?
By
Ronald G. Ross -- (September/October 1997)
August
2004
'Why'
is Why Business Rule Methodology is Different
By
Ronald G. Ross -- (July/August 1997)
July
2004
Never-ending
On-the-Job Training
By
Ronald G. Ross -- (May/June 1997)
June
2004
Re-Usability
in the Business Rule Approach
By
Ronald G. Ross -- (September/October 1996)
May
2004
The
Newest Idea In Business Rules: Rules Normalize!
By
Ronald G. Ross -- (March/April 1996)
April
2004
An
Open Letter to DBMS Vendors: We Need Active Database Systems
By
Ronald G. Ross -- (January/February 1996))
March
2004
The
Greatest Irony Of The Information Age: Business Rules
By
Ronald G. Ross -- (May/June 1995)
December
2003
Business
Rules:
Knowledge For Knowledge Workers
By
Ronald G. Ross -- (November/December 1995)
November
2003
"Play
Ball!"
By
Ronald G. Ross -- (March/April 1994)
October
2003
Enterprise
Architecture: Issues, Ingibitors, and Incentives
By
John A. Zachman -- (November/December 1999 & January/February 2000)
September
2003
Packages
Don't Let You Off The Hook
By
John A. Zachman -- (July.August & September/October 1999)
August
2003
The
History Of Steam-Powered Ships
By
Ronald G. Ross -- (November/December 1988)
July
2003
Life
Is a Series of Trade-Offs and Change Is Accelerating!
By
John A. Zachman -- (January/February & March/April 1999)
June
2003
"Business
Rules, At What Cost?"
By
Ronald G. Ross -- (January/February 1994)
May
2003
"Yes
Virginia, There IS an Enterprise
Architecture"
By
John A Zachman -- (November/December 1998)
April
2003
Business
Rules: Birth of a Movement
By
Ronald G. Ross -- (May/June 1994)
March
2003
Business
Systems And Information Support Systems
By
John Hall -- (January/February 2000)
January
2003
Enterprise
Architecture: Looking Back and
Looking Ahead
By
John A. Zachman -- (July/August 1998)
December
2002
Why
I Like the Zachman Framework Architecture"
By
Ronald G. Ross -- (July/August 1991)
November
2002
The
Framework for Enterprise Architecture (The 'Zachman Framework') and the Search
for the Owner's View of Business Rules
By
John
A. Zachman -- (January/February 1998)
October
2002
Business
Process Re-Engineering
By
Ronald
G. Ross -- (March/April 1997)
|