Business-Rule Stuff or Marketing Fluff?

Here's how to get beyond the hype and evaluate business-rule products

Terry Moriarty                
February 9, 2000

Today, the term “business rule” is in vogue. Marketers have embraced this phrase in hopes of finding a new audience for their application development products. On close examination, though, I often wonder whether a given product and the term have anything to do with one another. With existing products redefining themselves as business rule tools and with new entrants in the field, I decided that the business-rule marketplace is mature enough to warrant serious investigation. The often-quoted definition for a business rule comes from the Business Rule Group’s (BRG) (formerly GUIDE) Business Rules Project: Final Report (revision 1.2), October, 1997: “A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.”

By focusing on the business rule, an organization can manage itself at its most basic level, the individual policies that it puts in place as a guide to accomplishing its goals. By manipulating its business rules, an organization can fine-tune its activities to be more responsive to a changing business environment.

Vendors take on a lot of responsibility when claiming to support business rules. With existing products redefining themselves as business-rule tools and new products entering the field, I decided that the business-rule marketplace is mature enough to warrant serious investigation. In this column, I’ll provide you with a framework by which to judge tools claiming to support business rules.

In the most general terms, a business-rule tool should help with your goal of being able to generate the business policy and procedure manuals from the same business-rule repository you use to create the code that enforces those rules. Within that general guideline, business-rule products fall into three major categories: management, enforcement, and excavation.

Business-rule management tools should do the following:

• Provide an environment where business rules are captured, documented, secured, distributed to the relevant parties within both the business and technology organizations, and modified as the business evolves
• Support business rules from the business perspective using your enterprise’s unique business vocabulary
• Provide mechanisms that let the user navigate from “business speak” into the terminology that describes how the information resource supports those business rules
• Identify, record, and track the resolution of any conflicting business rules
• Incorporate a strong change-management facility so that the introduction of new or evolving business rules occurs only after the appropriate level of impact analysis has been performed.

I detailed the requirements for a business-rule management facility in my Data Architect column “Business-Rule Management Facility,” Database Programming & Design, Sept. 1998.

Business-rule enforcement tools should:

• Let you enforce business rules in the applications that support the organization’s operations. When these types of products are integrated into an application’s architecture, business rules are held separately from the database and processing code. An inference engine, which serves as the repository of executable business rules, is consulted to determine whether any special considerations exist that affect the behavior of the current business transaction. The business-rule engine can perform numerous processes, such as determining whether the data represents a valid business state, identifying the next task to be performed, or setting or calculating values, all based on the state of the objects involved in the transaction.
  
• Be tightly integrated with the business-rule management environment to ensure that changes in one environment are properly reflected in the other.

Business-rule excavation tools:

• Plow through existing information systems to uncover business rules held captive within code or textual documents
  
• Transform business rules uncovered from code into something that is meaningful to human beings.

At this point in the excavation, you can validate the business rules to determine their appropriateness for the current environment. Business-rule excavation (or reverse engineering) is often the first step in migrating to an application architecture that incorporates a business-rule enforcement component. I detailed the requirements for a business-rule excavation tool in “Reverse Engineering Tools” and “Getting Your Business Rules Automatically” (Enterprise View, Database Programming & Design, June 1997 and October 1997, respectively).

Classification Scheme

The common component of all three product types, the business-rule classification scheme, is for ensuring that a business rambling is transformed into a well-formed, atomic business statement. This scheme also provides a guideline for transforming business-rule statements into supporting information-management components.

Naturally, you can also use the scheme when evaluating a business-rule tool. The three main questions you want answered are:

• What type of business rules can you specify in the business-rule repository?
• What types of business rules can it enforce?
• What types of business rules can it excavate from code or documents?

I base the following evaluation criteria on the BRG’s business-rule classification scheme, the most comprehensive one to date. In this scheme, the fundamental business-rule types are structural assertions, action assertions, and derivations.

Structural Assertions

A structural assertion is “a statement that something of importance to the business either exists as a concept of interest or exists in relationship to another thing of interest. It details a specific, static aspect of the business, expressing things to be known or how known things fit together.” The building blocks of structural assertions are terms, facts, and the grammar that relates them.

Terms: A term is a phrase that references a specific business concept. The totality of the terms an organization uses to communicate the nature of its business is its vocabulary.

Business terms are independent of how you choose to represent them within the information resource. You should be able to build up a glossary of terms without worrying whether the term identifies an entity, attribute, object class, or business state. Alias terms for the same business concept can exist. Likewise, one business term may have different meanings, based on the context; it can vary by industry, organization, line of business, or business discipline. For example, when saying “account,” a sales person really means “customer account,” whereas the accountant means “general ledger account.” You need to know which area of the business uses which definition for a term.

Terms should be phrases that are meaningful to the business community. They should be expressed in title case, using spaces or any other character that is typical to the business. Technology naming constraints, such as the length and acceptable characters, have no place in the business term glossary.

Facts: Facts are “relationships that exist between two or more terms.” Attribute facts state that one term identifies a property (or attribute) of another term, such as a “Person’s Social Security Number.” Generalization facts specify that one term represents a proper subset of the objects that fall within the scope of another term. For example, a “Person is married or unmarried” is a generalization fact. Participation facts describe an interaction that can occur between the real world objects that the terms describe, as in “Business Party owns Accounts.”

Participation facts further subdivide into association, aggregation, and role. You use aggregation facts to describe a collection of things, as in “Contract contains Terms and Conditions.” A role relationship exists if the object that one term describes behaves as an actor with respect to the other term, as in “person is the sales person in a contract” while another “person is the customer in the contract.” Any other participation fact not classified as an aggregation or a role is an association.

The user of a business-rule management environment must be able to build facts from the available catalog of terms. You should build facts using the business concept alias that is preferred within the business area under analysis. For example, if one business area uses “Customer” and another prefers to use “Client” for the same business concept, each area should see its own terms used in the facts to which it subscribes. Users must be able to ask questions such as “What other facts do these terms participate in?”

Derivations

A derivation is “an algorithm used to compute or infer a derived fact.” A derivation business rule specifies either a mathematical calculation or an inference using logical induction (from particulars) or deduction (from general principles).

Mathematical Calculations: To specify mathematical calculations, a product should provide a full range of functions and mathematical operators. The business-rule management environment should be able to lead the user through the calculation’s development, prompting with terms from the concept catalog, as necessary. The business-rule repository should be able to answer the following types of questions: What attributes are input to this calculation? What attributes are the target of these calculations? To what other calculations is this attribute input? Are there any other calculations that output the same attribute?

Inference: Inference is the process of creating new information based on a set of underlying facts. In essence, an inference finds all the objects that qualify as members of the business state of interest because their underlying facts satisfy specific criteria. Many of the terms used by the business really identify business states. For example, “Customer” identifies those business parties in the owner role with respect to one of your organization’s products. The condition is derivable because the algorithm provides the selection criteria from the underlying facts of “Business Party owns Product.” Those business parties that satisfy these criteria are called “Customers.” You can define one business state in terms of other business states. The business state “Preferred Customer” applies to any “Customer” with a combined monthly revenue greater than $500. Similarly, a “Watch List Customer” may be any “Customer” whose payment is more than three months past due.

The product must provide the full range of Boolean operators to define inference rules. As with mathematical calculations, it should lead the user through a series of point-and-click dialogs so that all inferences are based on the terms in the concept catalog.

Action Assertions

Action assertions are the business rules that directly affect the organization’s behavior. All the other business-rule types represent the knowledge base on which the action assertions draw to determine what behavior should occur. An action assertion is a “statement that concerns some dynamic aspect of the business. It specifies constraints on the results that actions can produce.” Several types of action assertions exist.

Condition action assertion: Similar to an inference business rule; the testing part of the condition specifies the business state of interest using Boolean logic. However, often the business state is not significant enough to warrant its own term. A system triggers the action part of the condition when it finds the business state to be true. Under these circumstances, several actions may occur, such as modification of the database, triggering other business rules or causing initiation of actions.

An integrity constraint specifies a condition that must be true. It states that the conditional part of the business rule must be true for the action part to occur. You use this type of business rule primarily to enforce the integrity of the organization’s knowledge base. For example, we already know that the statement a “Person has a social security number” is a fact. The statement a “Person must have a social security number” turns the fact into an integrity constraint.

Authorization action assertion: Identifies who is able to perform some action.

Subclassification by technique: Each type of action assertion is further subdivided according to the technique used to govern the behavior the assertion triggers. The categories are enabler, timer, and executive. An enabler causes the creation of an associated object. A timer waits until a specific state occurs, such as the passage of a certain amount of time, initiation of another action, or whenever the knowledge base achieves a certain business state. An executive action assertion spawns other actions when the conditional part of the business rule is true.

As with inferences and calculations, users should be led through the process of creating action assertions. Each type of action assertion has its own pro forma method for specifying the business rule. A condition’s syntax is very similar to that of the inference. However, the action states what to do if the conditional portion of the rule fails — such as prevent the transaction from posting to the database or simply issue a warning message. The integrity constraint assertion often contains words such as “must” or “required,” to indicate that an attribute must be specified about its corresponding business concept. Likewise, the integrity action assertion is used to impose “how many” contraints, such as, “How many customers can own an account?” The business-rule management facility should be able to answer the following types of questions: How many business rules trigger the same actions? What are all the action assertions that affect a given business concept?

A business-rule product must be very easy to use, since its intended audience is as much the business analyst as the business-rules programmers. The language used to specify business rules and the techniques that the product uses to incorporate its business rules into an application are also essential evaluation criteria that I will address in a future article.

ETL Tools Don’t Count

But what about data transformation tools, you may ask? Their vendors claim that they support business rules. This phenomenon is an excellent example of the marketing hype that occurs when a term like “business rule” achieves buzzword status. The extract, transform, and load (ETL) tools have nothing to do with business rules. Their primary purpose is to massage the existing, disparate data into something more palatable to the business analyst. The success of ETL products is a sad commentary about an application portfolio that evolved without incorporating good data management practices. While these products can help derive and summarize data, their primary purpose is to transform data from one format to another. Do these products support transformation rules? Absolutely. Business rules? No way!

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. She authored Enterprise View (originally the Repository Report and later the Data Architect) column for Database Programming & Design. You can reach her via email at terry@inastrol.com.