I
have learned many things about the expression of business rules in the last
several years. I’d like to share several of them here, to shed light on
where I think we are in understanding business rules at the start of the new
millennium.

First,
it is clearly important to separate analysis-level expression of business
rules from their design-level expression. Most of what I want to say here is
about the design level, but let me start with the analysis level.

Effective
expression of business rules at the analysis level requires formative
guidelines or Business Rule Statement Templates. Such language templates are
now offered by BRS, as well as by other sources. Think of these language
templates as text or sentence patterns, to ensure higher clarity and
consistency. These templates are an important step forward in making the
business rule approach practical.

At
the design level, it has become clear that how business rules are expressed
externally – that is, at the human interface layer – should be cleanly
separated from how they are represented “inside” the computer. What's good
for one is not good for the other.

For
the external representation, at
least several capture techniques are probably needed, each suited to different
categories of rules. For example, each of the following techniques is probably
well-suited to certain types of rules:

Structured
English, for more complex restrictions and logical inferences.

Entity
Life History or State Transition Diagrams, for both basic and more
advanced state transition rules.

Data
Model or Object Model extensions, for basic property rules.

No
matter how the rules are captured, however, there should be a single, unified conceptualrepresentation on the “inside” of
the man-machine boundary. "Inside" here means transparent to the
specifiers, but visible to analysis tools (e.g., for conflict analysis) and to
rule engines or business logic servers (for run-time processing).

On
the inside there may be still other representation. For processing and
performance reasons, there might be many "physical" representations
underneath the unified conceptual representation of the rules. These various internal
representations might be optimized for particular tools or
hardware/software environments.

The
result is actually three layers of representation: external, conceptual, and
internal. As Keri Anderson Healy has pointed out, this is strongly reminiscent
of the old ANSI/SPARC three-schema architecture for data. This should not be
surprising, I suppose, since rules simply build on terms and facts, which are
ultimately represented by data.

What
technique is the best for each representation layer is a matter of great
debate. All three layers are important, but clearly the ultimate power lies in
the middle or conceptual layer. As pointed out in The
Business Rule Book, the important thing for this level of language is that
the rules must "compute." By this I meant the rules must be
represented in a form that is sufficiently rigorous for automated computation
(even if not very efficient).

Alternative
candidate representations for this level of language include the following.
(Predicate Logic is listed first because it establishes the baseline – any
other representation must be at least that powerful.)

Predicate
Logic

Ross
Method, featuring strong rule typing.

The
work of Terry Halpin for ORM (Object Role Modeling).

The
OCL, now under development by the OMG.

These
languages aren't for the faint of heart, but point toward the technological
future of business rules -- supporting higher-level automation schemes for
user requirements.

By
the way, in retrospect, I think I now understand better what the real
contribution of The Business Rule Book actuallywas. (I admit that I didn't understand this at the time I did the research
or wrote the book.) The graphic notation I developed might be useful for
capturing certain types of rules at
the external layer – especially using a point-and-click environment. (By the
way, a point-and-click technique is a bit difficult to illustrate in a book).
However, this would certainly not be optimal for all rules.

The
real contribution, I believe, is that Ross Method is actually a highly
organized scheme for the conceptual
representation of all rules. This representation is based on rule typing,
which I believe to be a level above other approaches. In the introduction to
the book, I used an analogy suggesting that the level of Ross Method is like
chemistry rather than physics. This new chemistry for rules is exactly what I
believe will achieve the full promise of business rules in the new millennium.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:

Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.