TERRY MORIARTY

As current methodologies mature, what does the future hold for business rules?

The Next Paradigm

February, 1993

Have you noticed the increased interest in business rules? Chris Gane is now researching how to extract business rules from existing code. Alice Sandifer and Barbara von Halle are championing the need for a business rule database in which an enterprise's business policies can be cross-referenced to the information components we use for constructing information systems.

I believe the interest in business rule analysis and modeling represents the next evolution in information analysis methodologies -following in the footsteps of information engineering and object oriented concepts. In fact, the current effort to dissect and comprehend business rules from an information structure perspective may result in an analysis methodology that finally melds the business and information systems mindsets.

What I find really exciting about the interest in understanding business rules is that the approach appears to be driven by the practitioners who are responsible for corporations' information resources. In our efforts to overcome the communications gap with our business counterparts, we're struggling to comprehend the essential ingredient driving an enterprise's information needs: business rules as represented by corporate policies and procedures. Through presentations at industry conferences, meetings of such professional organizations as the Data Administration Management Association as well as articles in industry publications, we're gradually getting a handle on the nature of business rules. And much of the discussion surrounding business rule analysis, interpretation, and transformation has occurred within the pages of Database Programming & Design.

What is a business rule? In my opinion, a business rule is a constraint placed upon the business. When a new enterprise is established, it's constrained by the products and services its owners want to offer and the markets in which they wish to compete. The owners of video rental stores have constrained their businesses to movie rentals. They don't want to offer services unrelated to movie rentals, such as banking, travel, or medical services. Throughout its life, the enterprise continues to be constrained by the interests of the owners, evolution of the industry, and economic and political climates. For example, the video rental industry has expanded beyond movies to include the rental of video games and audio books. These changes represent any refinements on the organization's initial constraints.

Daniel Appleton, who's been researching business rules for nearly a decade, defines a business rule as "an explicit statement stipulating a condition that must exist in a business information environment for information extracted from that environment to be consistent with business policy."' Similarly, Barbara von Halle and Alice Sandifer define business rules as "natural language sentences that describe data requirements to the business users."' Sandifer and von Halle acknowledge that "natural-language sentences" aren't restricted to verbal and textual formats. Rather, any material commonly used within the business community to communicate with one another, such as pie and bar charts, scatter diagrams, and tables, can be business rule sources.'

The authors have defined a five-phase process for business rule modeling: acquisition, analysis, validation, storage, and modeling.' These phases are distinct tasks that must be performed to model business rules properly. The order in which these tasks should be performed isn't implied. All phases can occur simultaneously in a joint applications-development (JAD) session. What's important is the dynamics of the interactions between the business partner and the information analyst as a business rule migrates through the phases, and the role of the business rule modeling paradigm selected by the information analyst in mitigating the communications problems that can occur.

First let's consider the concept of a "paradigm," which has received so much attention in our industry lately. A paradigm is defined as a "model, pattern, or example, especially an outstandingly clear or typical example or archetype."' Basically, a paradigm illustrates the composition of some object, describes how some process is performed, or helps in gaining an understanding of an abstract concept or principle. The paradigm often encompasses a set of rules governing its interpretation and use.

When I was in high school, English grammar rules were illustrated through sentence diagramming. Specific notation was used to depict sentences, nouns (subjects), verbs, adjectives, and adverbs. By parsing a sentence and translating its components into the diagram, I gained a better understanding of the English language. I became a champion sentence diagrammer. However, others in the class didn't adapt well to this form of analysis, primarily because they couldn't learn the rules of the sentence diagramming paradigm. While this learning tool aided my education, it impeded the learning for others.

Paradigms can be encountered in almost every industry. Film directors use storyboards to help the actors and film crew envision a scene. And the pie charts and bar graphs that our business partners present during business rule acquisition sessions are just a few of the paradigms they use to communicate with one another about the enterprise's financial situation.

Within the IS industry, the paradigms used for the analysis phase are methodologies such as structured analysis, information engineering, and object-oriented analysis. The business rule analysis process represented in Figure 1 illustrates the migration of business rules through the analysis phases.

As the figure illustrates, the business partner provides statements of business rules in naturallanguage or other business-oriented formats. The information analyst mentally processes these rules and classifies them into information components according to the rules of the selected analysis methodology (or paradigm). The business rules' data components may be classified as entities, attributes, and relationships, while the process components may be classified as business functions, business processes, and data flows. Once classified, the information analyst illustrates the business rules through the appropriate set of diagrams. By reading the models back to the business partner in business language, the information analyst attempts to validate the models and identify incomplete or inconsistent areas. In these areas, the analyst will probe deeper by asking detailed questions about the business. Gary Schuldt describes the acquisition and classification of business rules as "business rule-driven" processes, while the validation and probing steps are "model-driven" processes.

Communications problems often occur between business partners and information analysts because each group uses different terminology. Businesspeople speak in the language appropriate for their businesses, while information analysts often use terms that are meaningful within the IS industry. Have you ever had a conversation with someone who speaks a different language? When neither person understands the other's language, miscommunications are often the result. However, when two people agree to speak in the language best understood by each, communications problems can be minimized.

The same language problems often occur between business partners and information analysts. As information analysts, we all too often expect our business experts to become familiar with our language of information models and data flow diagrams. Since most of the information analysis languages are fairly simple, many business partners have been able to grasp the concepts underlying our diagrams easily. However, to a significant portion of businesspeople, our models represent a paradigm to which they can't adapt. These business partners may only understand the textual documentation behind the model or the information analyst's explanation of the diagrams. The actual diagrams may be totally incomprehensible. Their willingness to approve the models is often based more on their trust of the information analyst, who has spoken all the right business terms, than on their understanding of the diagrams.

Information analysts are still striving for a paradigm that can bridge the language gap between business and information systems professionals. While various paradigms are available that attempt to provide this common language, none have been entirely successful. The term "paradigm shift" has been coined to identify the process of discarding a paradigm that hasn't fulfilled our needs in favor of a promising new paradigm. When information analysts embark on a paradigm shift, they're changing the methodology used to classify and diagram business rules. Basically, the information analysis language is changed. The business rules we're attempting to comprehend haven't changed, but the approach we use to relate these rules to information needs has. Paradigm shifts during the business analysis phase can be confusing to the business partner because the information analyst has adopted a new language.

In my career, I've completed one paradigm shift from structured analysis to information engineering; I'm in the middle of the second shift to object-oriented analysis; and I perceive myself to be on the forefront of a third business rule analysis (see Figure 2). 1 began my career as a programmer and business function requirements analyst using structured analysis. The primary emphasis was understanding a specific business function in terms of the processes performed and their interaction with each other and the external world. I was only interested in the data attributes necessary to complete those processes. Holding areas for data attributes were classified as "data stores." The actual specification of business rules was buried in the process minispecs.

I accomplished the shift to information engineering with relatively little pain. I had worked on large strategic applications developed independently of one another using structured analysis and had been involved in nightmarish attempts to integrate incompatible data. It was obvious that data and process had to be treated as equals (with data a little more equal than process). Information engineering retains all the structured analysis process analysis constructs while providing the rigor of information modeling through its emphasis on the entity-relationship diagram. With information engineering, many important business rules have been extracted from the process minispecs to be clearly stated through the information model. However, information engineering continues to provide only cursory treatment of the attribute with the majority of business rules communicated in the process minispec.

Like many information analysts, I am currently struggling with the object-oriented paradigm. This approach recognizes that processes exist primarily to manipulate information. Therefore, processes are classified with attributes as properties of an object. While I completely agree with this distinction, I'm at a loss as to why many proponents of the object-oriented paradigm claim that it is revolutionary. Anyone who uses information engineering and is familiar with entity life history concepts recognizes that the logical evolution for information analysis is to establish a tight coupling between an entity and the processes performed to manage that entity's attributes. In essence, process becomes subordinate to data.

While I support the adoption of object-oriented concepts, I don't believe that this particular paradigm shift helps bridge the communications gap between business partners and information analysts. If anything, the situation becomes worse since the business rule classification words have changed with little rationale. "Entity" has become "object," "process" has become "method," and "data flow" corresponds to "message." Furthermore, no more focus exists on the association of the attribute to business rules than in the previous two paradigms.

I believe it's time to start the next paradigm shift to a methodology that directly supports the business rule. As with the previous paradigms, the shift primarily involves the treatment of processes during the business rule classification phase. The attribute will emerge as a recognized "object" in its own right. Many business rules classified as processes in the older paradigms will be further dissected and attached to the specific entity, attribute, or process to which it actually applies.

The average life cycle of an information analysis paradigm appears to be 10 to 15 years. Historically, development of a new paradigm seems to occur as the current paradigm is just gaining acceptance. In the late '70s, structured analysis was gaining acceptance. Interest in the information engineering paradigm was just beginning, as evidenced by the First International Conference on the Entity-Relationship Approach, held in 1979. In the mid-'80s, information engineering was gaining a foothold in many organizations. At the same time, some of the first papers on object-oriented concepts were presented at the Fifth International Conference on the EntityRelationship Approach. By 1990, information engineering had become the standard for information analysis. The most widely discussed topic at the 10th International Conference on the Entity-Relationship Approach was the implication of object-oriented approaches on information engineering. If the current paradigm shift pattern holds, object-oriented analysis will most likely enjoy wide acceptance by the mid-'90s.

Now is the time for the next paradigm to emerge. I'd like the approach to deal practically with business rule analysis, To that end, I'll be lending my voice to von Halle, Gane, and Schuldt in developing the business rule-driven approach.

REFERENCES

1. Appleton, D. S. "Second Generation Applications," Database Programming & Design, February 1988, pp. 48-54,

2. Sandifer, A., and B. von Halle. "Designing by the Rules," Database Design, Database Programming & Design, January 1991, pp. 11-14.

3. Sandifer, A., and B. von Halle. "A Rule by Any Other Name," Database Design, Database Programming & Design, February 1991, pp. 11-13.

4. Sandifer, A., and B. von Halle. "Linking Rules to Models," Database Design, Database Programming & Design, March 1991, pp. 13-16.

5. Webster's II, New Riverside University Dictionary, The Riverside Publishing Co., 1988.

6. Schuldt, G. "Business Rules and System Models," Presentation to the San Francisco Data Administration Management Association, July 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.