Perhaps an appropriate title for this article could be: A Romance with a Hidden Dimension. Borrowing from the adventure in Flatland (Abbot, Edwin A.,1952), a person who sees the world in one dimension will see only lines. For instance, a three-dimensional object such as a coin, viewed from the edge of the table (a one-dimensional view) ceases to appear as a cylinder (three dimensions) or an oval (two dimensions). It appears as a straight line (one dimension). So, too, any figure, viewed in this manner appears as a line. The object's other dimensions, while still present, remain hidden.
A person who sees the world in two dimensions will, in fact, see more than lines. Such a person can discern triangles, squares and other similar figures. Specifically, such a person would view the coin from above the table and discern it as a circle. It is interesting that a one-dimensional viewer and a two-dimensional viewer can be looking at the same object, and each sees it differently. Even more intriguing is that the two-dimensional viewer has no means by which to communicate the circular essence of the coin to the one-dimensional viewer who knows nothing of circles.
Taking this one step further, a three- dimensional viewer will see the penny as a cylinder, complete with length, width and depth. Likewise, such a viewer is at a loss to describe depth to the two-dimensional viewer or to describe width and depth to the one-dimensional viewer.
Think of rules as a third dimension of a business information system. Historically, the first dimension was the process dimension. We viewed systems as (mostly) process only. The good news is that we developed and utilized methodologies and techniques for analyzing processes. In fact, we became experts at the process dimension and built powerful computers to perform processes.
The second dimension was the data dimension. We began to view systems as a combination of process and data. The good news again is that once we could view the data dimension, we developed methodologies and techniques for analyzing data. Some of us became experts at the data dimension. We built powerful DBMS products to perform data-specific manipulation.
Parts 1 through 3 of this series have given you a glimpse of rules as their own dimension. If you can perceive the rules, you can see that the rule dimension is not the same as the process and data dimensions. In fact, the rule dimension adds depth to your two-dimensional view of a system. If you can perceive the rules dimension, you are ready to find a use for methodologies and techniques for analyzing rules. You may be ready to adopt or develop new technology for executing rules.
Introduction to Analysis
Part 2 of this series introduced the idea that a business rules approach encompasses a rules track. The focus of the rules track is to distinguish the set of computations, constraints, inferences, guidelines and action-enabling rules that utilize the information to guide actions. Part 2 also described the phases of a business rules approach.
Rules analysis, however, is where the rules dimension really becomes intriguing. In general, the analysis phase applies discipline to artifacts collected in each track. Specifically, the analysis steps in the rules track apply familiar and new discipline to the rules collection, in much the same way that data analysis adds discipline to a collection of data elements.
The Beginning of Rules Analysis
You are ready to begin rules analysis when you have collected a set of rules which you now can study and improve. You may have collected these rules from people, program code, database constructs, procedures manuals or a combination of these sources.
The deliverables from rules analysis should be a set of business rules management procedures and a logical rules model. At the core of rules analysis is the set of steps, techniques, guidelines and tools for turning a set of discovered rules into a logical rules model.
In this series, a logical rules model consists of three key deliverables. The first is the set of rules expressed in standard terms and facts and analyzed for logical rule quality or semantic integrity. The second is a table or diagram depicting rule-dependency relationships. The third is a table or diagram correlating rules to the data or knowledge each references and creates.
Many of you have criteria by which you judge a logical data model to be of high (semantic) quality. So, too, can you develop criteria by which to judge rules to be of high (semantic) quality. After all, every rule costs money. It costs money to think of it, document it, analyze it, optimize it, automate it, challenge it, trace it and change it. Following are the seven criteria against which to measure each rule:
- Relevant/justified: Each rule must be essential to the target scope of analysis.
- Atomic: Each rule must represent one thought such that an actor (human or electronic) can apply the rule in guiding behavior.
- Declarative: Each rule must prescribe a decision or computation rather than dictate a procedure for performing and enforcing the decision or computation.
- Intelligible/precise: The rule's intended audience must understand it such that the rule is predictable and repeatable in its usage.
- Complete: Each rule must possess all intellectual properties necessary for its usage.
- Reliable: Each rule must originate from a source authorized to decide that the rule is as the business desires.
- Authentic: As each rule is copied into various forms (natural language, templates, declarative specifications, executable code), each representation must remain faithful to the original intent of the rule.
There are three criteria against which to measure a collection of rules. The rules must be:
- Complete: All rules necessary to protect the integrity of related business events are present.
- Unique/non-redundant/minimal: There are no uncontrolled redundant rules.
- Consistent: A rule set does not knowingly contain contradictions within itself.
Figure 1 illustrates when and how in a business rules methodology you can address each of the ten criteria for rule quality.
Figure 1: Tips on How to Improve the Quality of Rules and Rule Sets
An Introduction to Rule Patterns
It is not possible in one article to present all details behind all steps in rules analysis. Of interest, however, is the use of rule patterns for analyzing certain criteria for rule quality. For the purpose of this article, consider that an entity and a rule pattern are similar in nature, although one deals with data and the other with rules.
In this context, think of an entity in a logical data model as a prescription for organizing atomic data attributes where the business is interested in storing and managing instances of the entity. Then, think of a rule pattern as a prescription for organizing atomic rules where the business is interested in storing and managing instances of the rule pattern. An example will make this clear.
Figure 2 is a rule-pattern table. In its left-most columns, it depicts those rule clauses that represent the conditions in a rule (the IF clauses). In its right-most column, it depicts the one rule clause that is the result of the rule (the THEN clause). A proper rule-pattern table, by definition, contains only one result column because an atomic rule has only one result.
Figure 2: Sample Rule-Pattern Table
A proper rule-pattern table, by definition, also contains columns only for those conditions that are mandatory. That is, a proper rule table does not allow nulls in its conditional columns. This too will become clear by studying Figure 2.
The first column in the sample rule-pattern table contains the rule ID for convenience. The second and third columns in this rule pattern table contain the conditions in the rule while the fourth column depicts the rule's one result. The conditions and results are comprised of rule clauses.
Notice that Figure 2 is populated with two atomic rules. Each rule has the same pattern to its conditions, and each rule shares the same pattern for its result. However, the instances of those patterns vary for each rule.
Rule patterns are interesting because they provide a visual mechanism for achieving two analysis goals. The first goal is the separation of the conditions of the rule from the result of the rule. The second goal is the abstraction of those conditions and results into to a general expression of the rule's structure. By abstracting individual rules into a general but precise rule structure, you are able to examine more easily the semantic integrity of those rules that conform to the same rule structure and across rule structures. For example, you can easily analyze each rule clause and each rule for a given rule structure against the whole set of rules in that structure to ensure that the set adheres to the semantic quality criteria. Let's look at the ideas behind rule-pattern analysis.
To better understand how to analyze rule patterns, consider Figure 3. Figure 3 contains rules collected by a rules analyst during a rules-facilitated session. For simplicity, other rules such as constraints, action-enablers and computations are not shown.
Figure 3: A Collection of Rules
If you gather into one preliminary rule-pattern table all of the rules in Figure 3, you will create Figure 4. In Figure 4, all of the rules share the same result, but some conditions are null because they do not apply to every rule instance in the table. (Other rules classifications, such as constraints, action-enablers, guidelines and computations also can be expressed in rule-pattern tables.) You can reduce Figure 4 to proper rule patterns, as shown in Figures 5, 6 and 7.
Figure 4: An Improper Rule-Pattern Table
It is interesting to note that while an organization (or subset of an organization) may operate with many thousands of rules, the number of rule patterns should be significantly less. The same holds in the data world. That is, while an organization may operate with many entity instances, the number of entity types is significantly smaller. Also consider that an interesting construct for analysis is the rule pattern.
Using rule patterns, you can improve the quality of your collection of rules.
- Blatantly redundant rules within one rule pattern can become obvious.
- Overlapping rules (a subtle form of possible rule redundancy) can be detected through cross-rule pattern analysis if you group rule patterns together appropriately.
- Inconsistencies within one rule pattern can become visible.
- Completeness within a rule pattern can be assessed. You can determine whether all necessary clauses are present. You can also determine whether there are instances for every combination and permutation of rule-clause values.
Rule patterns are only one technique for conducting rules analysis. You can also enhance rule completeness by revisiting your rule-enriched logical data model for missing constraint rules.
Rule-Enriched Logical Data Model
A rule-enriched logical data model represents a natural evolution of a traditional logical data model. Therefore, data analysis and modeling is different for a business rules system in two ways. First, the deliverable is a rule-enriched logical data model which contains data structures for base, nonderivable, persistent information as well as information materialized through the execution of rules. Information materialized through rules is either computed by a computation rule or inferred by an inferred knowledge rule.
Figure 5: Rule Pattern 1
This does not imply that the information materialized by rules is made persistent in the physical database design. The rule-enriched logical data model does, however, represent the rule-materialized information from a logical and semantic perspective as input to the database design process. These rule-materialized pieces of information are truly business assets. They should have names, definitions and domains and should be shareable across the enterprise when appropriate.
The second unique aspect of data modeling for a business rules system relates to rules gathering. Most logical data modeling methodologies include steps and techniques for capturing the basic integrity constraints (a subset of rules) about the data model. These are sometimes referred to as structural constraints. Most often, these include primary key constraints, alternate key constraints, relationship referential constraints, relationship and attribute optionality constraints, and attribute domain constraints. Most logical data modeling methodologies leave other kinds of constraints (multiattribute constraints, multientity constraints) to the application development methodology.
Figure 6: Rule Pattern 2
A difference in the business rules approach is that the logical data modeling methodology complements the rules analysis methodology by specifically capturing all data integrity constraints some in the data structure, but most in the corresponding rules.
Figure 7: Rule Pattern 3
Consider the basic (very simple) entity-relationship model in Figure 8. Suppose a rules analyst has gathered the rules in Figure 9 that will execute against the model.
Figure 8: Basic Entity-Relationship Model
Carefully study Figure 10, which depicts a rule-enriched logical data model. Notice that it contains additional attributes (and could contain additional entities and relationships) that represent values materialized by rules. The values of these are known through execution of rules. Therefore, these are not pieces of basic information, but pieces of knowledge. Knowledge results from application of logic to information. Consequently, a rule-enriched logical data model is a step beyond information management and a step closer to knowledge management.
Figure 9: Sample Rules
Notice, too, that rules have been added to the model. The rules are numbered, but also named according to the entity they pertain to, a descriptive word and a rule-related classword depicting the classification of the rule. Each rule is normalized to an entity where normalization is based on the data value or truth value (for constraints) the rule materializes. This kind of discipline results in very predictable rule-enriched (knowledge- enriched) models. A rule-enriched model provides a database designer and a rule designer with a common ground for designing the best implementation options for the rules and the data. The design should become the joint responsibility of a rules designer and a database designer, both working from one deliverable.
Figure 10: Sample Rule-Enriched Data Model
The business rules approach advocates the tremendous amount of business value in analyzing rules. After all, the rules of the business represent its decision-making capacity and govern how the business behaves with respect to its internal people and external partners and customers. The rules are a strong basis for business process reengineering as well as the transformation of systems from one technology to another.
Through rules analysis, you can assist the business experts in crafting high- quality rule sets following disciplined approaches. Rule patterns are just one possible technique.
Some of you may feel very comfortable with the rules dimension knowing that high-quality rules, like high-quality data, are atomic, declarative, intelligible, precise, reliable and authentic, and that high-quality rule sets are complete, unique and consistent.
Therefore, whatever rules techniques you apply, you need to decompose composite rules into atomic ones, express them in templates and common vocabulary, remove rule redundancies, resolve rule overlaps, resolve rule inconsistencies, make sure each rule pattern is intellectually complete and make sure the entire set of rules within a rule pattern is complete. This is similar to the attention you give to a set of data attributes.
This article does not cover the impact of rules analysis on process and workflow analysis. Specifically, not only do you want to analyze rules for semantic quality, you also want to be sure you understand how rules depend on each other (possible execution chains). One rule depends on another if the first rule requires the materialized value of the second rule. Rule dependencies provide essential sequence as input to process and workflow analysis.
A final step in rules analysis, not covered in this article, is returning to the business motivation. Specifically, many steps in rules analysis ensure that the rules you collected make semantic sense as a whole. However, you need also to make sure that the rules are consistent with business motivation such as policies, objectives and risk mitigation. Your rules analysis should conclude by revising the connection between the resulting high-quality collection of rules and the business motivations the rules intend to support and achieve.
As a final thought, consider the analysts working on the system. Do they view the system through one-, two- or three- dimensional eyes? Whether or not a person sees the rules dimension may be intriguing. The truth is that as with previously hidden dimensions, the rules dimension has always been there and always will be there. Without the ability to see it, you don't have the ability to analyze and leverage it. You will be missing a major part of the vision.
Next month is the last installment of this series. It will discuss design considerations with emphasis on rule design opportunities.
Acknowledgement: The material in this article is adapted from an upcoming book to be published by Wiley & Sons in 2001. Significant contributions to the content came from Janet Wall, Art Moore, Linda (Jeney) Nieporent and Neville Haggerty.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access