Why have today's paradigms fallen short of effective business rule classification?

Business Rule Analysis

April, 1993

In February ("THE Next Paradigm," Enterprise View), I proposed that business rule analysis is the next emerging paradigm. For the last 20 years, the IS industry has been evolving through a series of analysis methodologies. From structured analysis to information engineering and, now, object-oriented analysis, each methodology has attempted to overcome the deficiencies perceived in its predecessor paradigms and help information analysts demonstrate their understanding of the business rules driving their corporations' information needs. While the schemes for classifying business rules have changed with each paradigm shift, the subject of the modeling effort the business rule-hasn't changed. Each evolution in analysis methodologies focuses more intensely on the point of stability: data over processes. However, the existing paradigms have fallen short in providing mechanisms for classifying all the business rules an information analyst encounters. Likewise, our documentation approaches must be improved to help information analysts validate that the business rules represented in our business model diagrams and text are not only correct, but consistent and complete as well.

Recently, progress has been made in identifying the types of business rules an information analyst can expect to encounter. Alice Sandifer and Barbara Von Halle's activities have been focused primarily on the types of business rules supported by the constructs found in an information model.' Chris Gane has identified the types of business rules that can be extracted from program code through reverse engineering.' And in the change-management series of this column, I explored the degree of impact a particular business change can have on the application portfolio. While each researcher examined business rules independently and from different perspectives, a lot of overlap exists in the set of identified business rule types.

This column will gather these business rule types together, eliminate redundancy, and provide a brief definition for each. Even though the object-oriented analysis approach has selected different terms (object and method) for entity and process, I choose to retain the older terms since they're more likely to be encountered within the business community. I've also attempted to provide names for the business rule types that are independent of any specific technology.

Business rules can be categorized into three basic groups: entity, attribute, and event. Entity business rules identify the nature and behavior of a specific entity class. The normal definition of an business entity applies: it's a person, place, thing, event, or concept important to the enterprise.

Many important entity definitions exist. Entity Class Definition indicates the existence of an entity class and provides its definition. Entity Instance Identification designates the business's mechanism for identifying each instance of an entity class. Entity Instance Relationship identifies the association that can exist among instances of different entity classes. Entity Instance Manipulation Rule specifies processes determined by the type of manipulation performed: Create, Read, Update, or Delete (CRUD).

Entity State Definition specifies a set of attribute values and relationships defining a valid state for an entity instance that has a specific meaning to the business and business rules applying to that state. For example, the valid states for a videotape may be "on order," "available for rental," "on reserve," "rented," "late," or "damaged." Only videotapes with a current state of "available for rental" can be rented. If a videotape's current state is "on reserve," it can only be rented to the customer who reserved the movie.

State Transition Rules specify the allowable transitions among entity instance states. For example, a videotape's state can transition from "on reserve" to "rented" or "available for rental" depending on whether the customer who reserved the movie actually shows up to rent it before the reservation grace period elapses.

Entity State Process-Related Rules identify processes that are performed based on an entity instance's state. For example, the following sequence of processes may be performed for "late" videotapes: First, a phone call is placed to the customer when the tape is two days late; second, a late notice is mailed when the tape is a week late; and finally, the cost of the tape plus a surcharge compensating for lost revenue is billed to the customer's credit card if the tape hasn't been returned after a month.

Timing is an important aspect of an Entity State Transition or Process-Related Rule. Should the process be triggered immediately when a entity state is detected or should it be invoked by some external event? If the reservation grace period has expired, then the "make videotape available" process should be initiated immediately so that the salesclerk is notified as soon as possible to make the tape available for rental to other customers. However, it may make more sense for late videotape processes to be initiated only when the person responsible for following up on late tapes is ready to perform this function.

An attribute is a specific fact of interest to the business. Rules related to a single attribute are classified as attribute business rules. Information Class defines a set of characteristics that several distinct attributes can have in common. For example, Profit-Amount has a specific connotation and characteristics that serve as the basis of the definition for Customer-Profit-Amount, Product-Profit-Amount, or Market-Segment-Profit-Amount. The generic definition of the information class Profit-Amount applies to each attribute within the class. However, each attribute will augment the base definition with its own characteristics and business rules. For example, the derivation business rules for each of the Profit-Amount attributes are different.

Attribute Definition indicates the existence of an attribute, its business definition, and identifies the entity class to which it pertains. Attribute Existence Rules specify whether the entity instance can exist if a value isn't specified for the attribute, whether different entity instances can assume the same value, and whether the attribute can concurrently assume more than one value for the same entity instance.

Domain specifies the set of values an attribute can assume and the business meaning of each domain value. Derivation Rule specifies the formula used to calculate a derivable attribute's value. For example, Interest-Earned is a derivable attribute with two allowable formulas, Simple and Compound.

Attribute Manipulation Rules specify processes that are performed based on the type of manipulation: initial value setting, value change, value retrieval, or removing a value (setting to null).

Attribute Dependency Rule specifies the conditions or constraints placed on an attribute's ability to assume specific values based on specific entity states or the values of one or more other attributes. Interest-Earned is dependent upon the value of the attribute, InterestCalculation-Method, to determine which formula should be used in the interest calculation.

Attribute Grouping Rule identifies attributes that the business treats as a unit, such as addresses and phone numbers. Attribute Presentation Rule specifies the formats that will be used to capture and display an attribute's value.

An event is a request to perform a specific activity. "Reserve a movie ... .. rent a videotape ... .. return a videotape," and "identify late videotapes" are examples of some of the events occurring in a video rental store. To satisfy an event, many processes may need to be performed.

Event Process Dependency Rules control how processes are invoked to satisfy the requirements of a specific business event based on the associated entity instances' state. The "reserve a movie" event invokes the "check for late charges" process so that the video store's salesclerks can inform the customer of any outstanding charges to be paid when the videotape is picked up.

Event Delivery Rules govern interfaces and presentation to the business environment. Delivery rules identify related attributes that must be manipulated as a unit to have meaning to the business end user. The related attributes can span entity instances. For example, a Rental Agreement requires attributes about the Customer, Movie, and Videotape, as well as attributes specific to the actual agreement. Event Delivery Rules become the requirements for screens dialog and report designs.

Although I have classified event business rules independent of the entities they impact, it can be argued that they should really be classified as Entity Life Cycle Events. With this type of classification scheme, all processing rules can be attached as a property of some entity or attribute.

It's readily apparent that we have identified more business rule types than the currently popular business analysis methodologies handle, in which rules such as attribute derivation, attribute dependencies, and entity state definitions and transitions are often buried in process minispecs. Mechanisms are required for presenting these types of rules in a manner that can facilitate their validation by business experts, but can be easily transformed into information systems.

Sandifer and von Halle have recommended the use of a business rules database in which business policy statements are dissected by business rule type. The textual statement of each rule is maintained in text. Business rules are then classified into the appropriate modeling object according to the rules of the information analysis methodology. The text of a business rule may be refined during the information analysis and classification process. Business rules can be validated from the resulting models or from their textual statements.

I must admit to being skeptical about the concept of a business rule database separate from the repository that supports the business models constructed from the analysis of those business rules. Once a business rule has been classified as a modeling object, I typically capture the text that the authors associate with a business rule as part of the descriptive documentation in the repository. I feel uncomfortable with maintaining the textual statement of the business rules outside of the repository. Bob Jones, a well-known repository expert, expressed similar concerns about the practicality of expressing all business rules textually when models present the rule in a more practical format.'

I believe that the business rules database is one possible solution for validating business rules in a manner that is meaningful to the business partner. This approach removes any dependence on the information analyst who reads the business assertions documented in the models. Furthermore, the business rule database documents a business rule independent of its classification as a model object. As Sandifer and von Halle point out, an information analyst may decide to reclassify a business rule without changing the rule itself.

Moreover, I believe that the business rule database is an attempt to overcome deficiencies in the currently available information analysis methodologies as well as the CASE tools rigidly enforcing these methodologies. Very few methodologies recognize the need to separate the business rule statement from its classification within the methodology. This problem did not occur before the advent of CASE. If an entity was incorrectly classified as an attribute, the mistake could be corrected by redrawing the model and editing the supporting documentation to reflect the change in classification. The textual description stating the business rule the object supported very rarely had to be changed.

However, CASE tools are not often so forgiving. Reclassification of modeling objects isn't allowed. For example, to reclassify an entity as an attribute, the information analyst is forced to delete the entity along with its associated definition, and create the attribute with its definition. Since a model object's definition is usually the statement of the business rule the object supported, when a CASE tool implements the delete/add approach to reclassification, it's forcing the deletion and reentry of the associated business rule.

Establishing a business rule database that isn't fully integrated with the repository is like giving aspirin to a patient with a brain tumor. While the medicine provides some short-term relief to the patient and may mask the symptoms for a while, it doesn't represent a cure. If the real problem isn't diagnosed, the patient may be doomed.

Relief to the business rule capture and validation problem will be provided by CASE vendors that come up with innovated approaches for balancing the use of diagrams and text. Recently, Warren Keuffel reported on a study that analyzed whether students understood a program better when presented with a flowchart or a minispec of structured English.' The results indicated that "Human factors research seems to indicate that text contributes to processing accuracy, while graphics contribute speed.... We must have equal access to text and graphics if we want to maximize our understanding and our users' understanding of our analysis effort. This requirement needs to be addressed more adequately by our tool vendors."

To their credit, some CASE vendors have provided features addressing the business rule validation problem. KnowledgeWare Inc.'s ADW (based in Atlanta) allows the definition of multiple views of the information model. Using this facility, the information

analyst can focus on the portion of the model relevant to the business rules being validated. Likewise, its data structure diagram (see Figure 1) supports the Attribute Existence business rules by clearly depicting an attribute's cardinality with its entity.

Texas Instruments' IEF (based in Plano, Texas) supports a subject area model derived from the underlying information model. IEF's Process Dependency Diagram (see Figure 2) is an excellent representation of Event Process Dependency business rules.

Logic Work's ERwin (based in Princeton, New Jersey) provides different presentations for the same information model (see Figure 3). The ability to present models including entity descriptions or associated attributes greatly facilitates the process of validating the business rules illustrated in the information model. Most of the CASE tools supporting information modeling have incorporated the ability to translate the Entity Instance Relationships business rules into text. This feature should be extended to other business rule types so that diagrams and text are generated from the same source.

Few CASE tools support the attribute business rules. While some allow Domains and Derivation Rules to be captured for an attribute, most depend on process minispecs to capture the business rules associated with an attribute. For business rule analysis to become an effective methodology, graphic representations for attribute-level business rules must be developed. Palo Alto, Californiabased WhiteLight Systems has incorporated such a diagram into its Enterprise Workstation (see Figure 4), a NeXT-based product used to develop and deliver executive information systems (EISs). The Enterprise Workstation isn't meant to be a CASE tool. However, when WhiteLight Systems' developers found that executives needed assistance in defining their EIS

needs, they developed this diagram to model an enterprise's business information. I certainly wish this type of diagram was incorporated into "real" CASE tools.

Business rule analysis represents a major trend in the evolution of business information analysis methods. I'm sure that the business rule types consolidated in this column don't represent a definitive list. Von Halle and Sandifer have taken significant steps in identifying the need to separate business rules from the classification schemes that information analysts use to understand and represent the information requirements embedded in those business rules. Hopefully, we'll be able to continue the development of these concepts in Database Programming & Design. Who knows, maybe CASE vendors are reading and will listen to our needs.

4. Keuffel, W. "Is Graphical Always Better?," Computer Language, 9(9), September 1992.

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. Her common business models have been used as the basis of customer models for companies within the financial services, telecommunication, software/hardware technology manufacturing, and retail consumer product industries. You can reach her at terry@inastrol.com.