Current Thoughts on Expressing Business Rules
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.
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.
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:
Decision Tables for value thresholds, and perhaps certain types of computations.
Point-and-Click Expression Builders, for instance limits and type consistency.
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 conceptual representation 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.
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.)
Ross Method, featuring strong rule typing.
The work of Terry Halpin for ORM (Object Role Modeling).
The OCL, now under development by the OMG.
languages aren't for the faint of heart, but point toward the technological
future of business rules -- supporting higher-level automation schemes for
the way, in retrospect, I think I now understand better what the real
contribution of The Business Rule Book actually
was. (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.
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.
© 2000, Ronald G. Ross.
About our Contributor:
BRSolutions Professional Training Suite
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.
How to Define Business Terms in Plain English: A Primer
How to Use DecisionSpeak™ and Question Charts (Q-Charts™)
Decision Tables - A Primer: How to Use TableSpeak™
Tabulation of Lists in RuleSpeak®: A Primer - Using "The Following" Clause
Business Agility Manifesto
Business Rules Manifesto
Business Motivation Model
Semantics of Business Vocabulary and Business Rules