CURRENT THOUGHTS ON EXPRESSING BUSINESS RULES

By Ronald G. Ross, January 2000

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:    

• 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.

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 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.

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.  

© 2000, Ronald G. Ross.