Terry Moriarty

The hows and whys of defining business rules

Businessperson's Perspective

August, 1998

"Bell Atlantic Seeks Eased Business Rules" was a headline from Reuters on January 29, 1998. The article summarized Bell Atlantic's efforts to persuade state and federal regulators to lift restrictions on the company's products for businesses.

"Top executives representing firms at all levels of the global IT supply chain will meet behind closed doors next week to form a new consortium with the aim of defining Internet commerce and business rules allowing the channel to move goods around more efficiently," an article published recently in InfoWorld Electronic said.1 The article continued with the objectives of the group: "Rather than defining low-level technology specifications, the group ... will embark on the ambitious task of defining business rules for the IT supply chain and for conducting business-to-business I-commerce."

"Business Rules: Perfecting Professional Etiquette" is a presentation by Marjorie Brody of Brody Communications Ltd. that addresses "how to avoid losing face, stepping on toes, or putting your foot in your mouth so you can conduct business confidently and correctly in any culture and under any circumstances."

Business rules has become a popular term, if these recent articles are any indication. But does everyone mean the same thing when using the term? Some business rule practitioners promote a narrow definition that includes only declarative business statements; consequently, those statements that sound "procedural" are not considered business rules. Ronald Ross has been a primary advocate for the declarative business rule, eloquently describing the difference between business statements that describe "knowing" and "doing."2 According to Ross, statements that assert what an organization "knows" are candidates for business rules; those that describe what an organization "does" are not.

While I agree that segmenting business statements into "knowing" and "doing" has value, I'm concerned about precluding the "doing" statements from consideration as business rules. I don't believe that those people represented by our term "the business" subscribe to this narrow definition of business rules. To validate my suspicions, I decided to ask my friendly businessperson, Dave.

For nearly two decades, Dave held numerous positions with a west coast bank, including branch and service center manager. Much of the vision behind the bank's client relationship management system came from Dave. When I first met him, he was responsible for the commercial bank's management information systems. As such, he participated in establishing business policy with respect to the bank's incentive plans and administering the assignment of clients to the bank's portfolio. He served as the liaison to the IT department, providing requirements for both the operational and data warehouse applications. Dave was the first person that the bank's executives and knowledge workers called when they needed some new business analysis about the performance of their products, market segments, or client relationships. Currently, Dave is consulting with another financial service organization with more than $6 billion in assets, supporting its merger and acquisition activities.

IT tends to have a love/hate relationship with people like Dave. With his strong business knowledge and influence with management, Dave is the type of subject-matter expert (SME) we want in our business analysis sessions. He understands with data modeling from a business perspective; the customer data model is posted in his office. But Dave is also technology literate. He has definite opinions of how "his" databases and applications should be designed. He has developed several business applications that, according to Dave, "IT couldn't or wouldn't" implement.

Over the six years I've known Dave, we've discussed information management from both the philosophical and practical points of view. I have a greater understanding of the frustrations the business feels when IT imposes its view of the world onto the business community. He was the perfect person with whom to discuss the business perspective of business rules. I didn't want to be accused of "leading the witness," so I only asked one question. Then I sat back and let Dave work it out:

Terry: What is a business rule?

Dave: (Silence)

Terry: Are you still there?

Dave: I'm still here. I just never thought about defining business rules. Let me rattle off some business rules and see what we come up with.

• Only one record must exist in the database for a customer. Each customer must be uniquely identified.

• Staffing levels must adhere to the organization's staffing model.

Business rules can be segregated into things like organizational and sales and marketing strategies.

Terry: Would you say that anything you find in a policy manual is a business rule?

Dave: Yes.

Terry: What about your product and service manuals--your product configuration and pricing plans?

Dave: I don't know about that. I'll have to think about that for a while. But what about procedures?

Terry: Yes, what about procedures? Do you consider them to be business rules?

Dave: That answer's easy. Absolutely.

Notice that Dave's response when asked to define a business concept included two classic SME responses:

• Silence because he never thought about defining the terms before

• Definition by example because he can't articulate the definition, but he knows one when he sees one.

Because Dave is just one person whose opinion can't be taken as gospel, I did a search on the Internet of "business rules." It's amazing what people are putting out on the Web. I found a number of organizations that have posted what they call their business rules for specific aspects of their business. While most of the statements are declarative, procedural statements were also included (see Table 1). Businesspeople don't seem to find it necessary to distinguish between procedural and declarative statements when using the term "business rules."
 

I believe that the business, minimally, refers to two types of statements when it uses the term business rules: policy and procedures. These business concepts have related information resource management concepts, which I call information integrity business rules and event-oriented business rules (see Table 2).
 

To illustrate the relationship between information integrity and event-oriented business rules, consider the following statement made about a bank: "When a product is deactivated, close all the outstanding accounts for that product." This is an event-oriented business rule because it establishes a relationship between two business events. The "deactivate product" event initiates a "close account" event for each open account for that deactivated product. Why is this procedure necessary? Because a corresponding information integrity business rule exists: "All the accounts of a deactivated product must be closed." The information integrity business rule describes a valid state for the knowledge base. Any event that violates this business rule must be rejected. At any point in time, you can interrogate the organization's knowledge base to determine whether it is irrational--specifically, are there any open accounts for deactivated products?

Your enterprise's SMEs are more likely to provide business statements that can be classified as event-oriented business rules than information integrity business rules. Often, SMEs feel more comfortable discussing their responsibilities at the "doing" level as a mechanism for exposing what they "know." Behind every event-oriented business rule lurks at least one information integrity business rule waiting to be exposed. Our responsibility as business rule analysts is to expose those implicit business rules so they can be examined in the light of day.

Many event-oriented business rules can coexist to support the same information integrity business rule. For example, you may establish different event-oriented business rules for different products. You may establish the "automatically close all accounts" business rule for savings accounts. However, for mortgage accounts, the business may decide that it must close the outstanding accounts naturally at their term. Therefore, the "deactivate product" event is rejected. To rectify this situation, the business may decide to adopt "grandfathering" for mortgage accounts. The outstanding accounts will remain open, but the business will not establish new accounts for that product. Once all the outstanding accounts for the product have closed, the product will automatically be deactivated. Finally, the business must convert the outstanding checking accounts to a different product type before the original product can be deactivated.

You must carefully examine these event-oriented business rules to determine whether they are in conflict. Business rules are conflicting if the enterprise is put at risk in some manner if all the business rules are implemented. Otherwise, these business rules are variations of one another. These business rules are related because they exist to ensure that the same information integrity business rule is enforced, but there is no risk to the business associated with letting all these procedures coexist.

The greatest benefit of the business rule approach is its emphasis on ensuring the flexibility of the business information systems. The business rule approach provides a framework that you can use to anticipate where the business is most likely to change and facilitate the implementation of changes into the organization. Event-oriented business rules tend to be more dynamic than information integrity business rules. As Dave says, procedures are more fluid, subject to change for various reasons. He describes the difference between policy and procedures as analogous to the relationship between strategy and tactics. The tactics that an organization elects to implement to achieve a strategy may change without ever affecting to strategy itself. For example, improvements in the technology that supports the business rules may be stimuli for streamlining the business procedures, but the underlying policies remain unchanged. Therefore, the enterprise can maximize the benefits it derives from adopting the business rule approach when it uses it to manage the evolution of its business procedures.

Ross states that "We do not know or care how the rule 'student may take no more than three courses' goes about ensuring compliance. All we know or care about is that the rule guarantees the truth we seek. That is really why rules are not procedural." Who is the "we" being referenced--data management or the business? I believe that this statement only applies to the former. Given our limited responsibilities for ensuring that the information integrity business rules are properly supported, the data management "we" doesn't care how the application layer chooses to enforce the rule. Our responsibility is to reject any submitted transaction that would result in the violation of the rule. However, the business "we" are very interested in how the rule is enforced and may have invested a lot of time in determining what they consider to be the most optimal procedures to ensure that violations never occur or are dealt with properly should they occur. All the evidence indicates that these procedures fall within the definition of "business rules" as used by the people who establish and approve the procedures.

Shouldn't we let the business determine which statements constitute its business rules and find another terms for data management's more constrained definition of "what the organization knows?" Let's leave the "business" in business rules.
 

References

1. Busse, T. "Executive Group to drive IT supply chain standards." Infoweek Electronic, Feb. 13, 1998.

2. Ross, R. G. "The Fundamental Ideas of Business Rules: The Practitioner's View." Database Newsletter, March/April 1998.
 

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.