Business Rules: Capturing the Most Elusive Information Asset - High-Performance Web Databases: Design, Development, and Deployment - page 109

Data modeling methodologies, data analysis guidelines, and automated
tools have made it easier to understand the importance of capturing cer-
tain kinds of business rules. Data specialists have learned that the quality
of a data model is directly related to exactly how much meaning has been
captured about the business information and how readily available that
meaning is to the business community. The information systems industry
is still struggling with exactly how to capture all relevant business rules.
BUSINESS RULES DEVELOPMENT LIFECYCLE
Each business rule begins its life as a user utterance, typically a long,
ambiguous, and perhaps unclear sentence. It must then be analyzed,
decomposed, and refined until it becomes a concise, clear, atomic business
rule that can be understood by all. In this atoned state, although simple and
clear, the rule is parochial because it represents the knowledge or opinion
of one or a few people. For use in a shared data environment, the parochial
business rule should be expanded in scope until it reflects the truth as
known by a major participants who have an interest in that business rule.
For example, to an order entry administrator, a customer is a person
who currently has an open order with the enterprise. To a sales represen-
tative within the same enterprise, a customer is any person to whom the
salesperson has spoken about the enterprise and its products, whether or
not this person has ever placed an order for any product. In the same enter-
prise, a credit manager may perceive a customer as any person who has
placed an order totaling more than $500 because such orders require a cus-
tomer credit check. These definitions must either be combined into one
general definition of customer that is all-encompassing, or they must be
distilled into separate names and definitions when these differences are
significant to the enterprise. The result is a true, shared business rule or
set of rules.
After the business rule has been validated by the business community,
and if the rule is within the scope of an information systems development
project, it is next translated into appropriate data modeling constructs.
This process, by its very nature, uncovers additional business rules.
This evolution of business rules suggests that they have a development
lifecycle that can be divided into five major phases. The first phase is
business rule acquisition, which is the process of obtaining facts from a
business rule source. The second phase is business rule analysis, whereby
an analyst converts user statements (verbal or written) into discrete, clear,
and atomic business rules. Phase three is business rule validation, in which
the business rules are circulated and subsequently modified to reflect com-
monality in understanding across organizational boundaries. The fourth
phase is business rule storage, which includes the storage, update, and
retrieval of business rules in a repository. The final phase of the lifecycle is