Understanding Behavior through Business Rules

11/97
Copyright, 1997

I’ve been fortunate in my career to be able to observe several competitors within the same industry formulate their business rules for managing the relationships with their customers. My responsibility was to develop the data and process models to support those business rules. What I discovered was that the same models moved from one company to the next with little change. What really amazed me was when those models transitioned virtually unchanged to support the customer relationship information management needs of companies in other industries.

Each company is unique, with its own values, corporate culture and way of doing things. These companies compete in highly volatile industries, such as financial services and telecommunications, which are undergoing massive restructuring with respect to the products being delivered and the make-up of the competitors. New companies are entering the market, others are withdrawing or consolidating and alliances are being forged both among former competitors and with companies in other industries. In fact, a competitor in one market may be an alliance partner in another.

With all this volatility in the marketplace, how can the data and process models be so similar? I’ve concluded that what it takes to participate in an industry, from an information management perspective, is quite stable. What the organization needs to know (its data) and what it needs to do (its processes) are unique to an industry, not to an individual company. In fact, much of that data and processes are dictated simply by what it takes to be in business, whether that business is a for-profit, not-for-profit or governmental enterprise.

What is distinct to each competitor is how it chooses to configure and price its products, how it markets its products and services and how it decides to select and configure its resources to deliver those products. If the "what" of being in business is universal, the "how" of business reflects the personal beliefs and values of each organization. The "how" of business is manifested through an organization’s business rules, as embodied in its policy, and its workflow, as described through its procedures. In fact, an organization’s procedure manuals describe how the organization is expected to behave in response to any event. This is an ever-changing aspect of the organization.

How an organization chooses to respond to an event can give it competitive advantage over its competitors. The business rules an organization establishes to control its behavior are a reflection of its values. For example, many organizations’ published "vision and value" statements include a commitment to being customer-focused. They believe that they should to always behave in a manner that is in the best interest of their customers. Often, there is no corresponding indication of the degree to which "risk aversion" is also valued by the enterprise. You must gleam how risk averse an organization is by observing its behavior when it encounters a potentially threatening situation.

Table 1: Values Dictate Behavior

When an organization establishes its business rules, it is constantly balancing the trade-off between risk and its other values. With respect to overdraft policies, the trade-off is between financial exposure and the degree to which it trusts its customers. After all, paying those overdraft checks is equivalent to extending an unsecured, interest-free loan with no guarantee that the funds will ever be repaid. Rick aversion is a major determinant that influences how an organization formulates its business rules.

To achieve an edge over its competitors, companies are attempting to refine their business rules by controlling the scope to which they apply. For example, Bank 1 may decide to limit its financial exposure in overdraft situations by only paying the checks for their best customers. Today, if the decision to pay checks for an overdraft account is embedded in application code, implementing the new business rule may be a costly, time-consuming effort. Companies are looking for ways to refine and test their business rules on a more timely basis. Our information systems need to be architected so that they are amenable to change, allowing an organization to rapidly prototype, implement and refine its business rules in response to market fluctuations. To meet the challenge of these competitive environment, information systems must be able to respond to events in a manner that is appropriate to the business objects involved and the business rules in effect at that specific point in time. These information systems must be designed to control behavior, not just processes.

Behavior is controlled by three constructs: the type of Event that has occurred, the state of the Business Objects on which the event operates and the organization’s business rules (Figure 1). A business object state specification, which is itself a business rule, identifies a set of property values that the business object(s) must assume to be considered to be in that state (e.g. Overdraft is a state of a checking account that occurs when its balance falls below zero). Many business rules are specified in terms of the business object states of interest to the organization (e.g. If an account overdrafts and the account is owned by a preferred customer, pay the checks. Otherwise, bounce the checks). Business rules are specified independent of the events they constrain, so that they can be used by any event that causes the related business objects to achieve a state which may invoke the business rule, even those events that we have not been able to anticipate.

When an event occurs, it follows its prescribed procedure plan, selecting the related business objects when required. At the point of selection, the business objects are in their "initial" state. The event may causes changes to that state as it continues performing its operations. If a business object state is encountered that triggers a business rule, the event’s standard behavior changes to conform to the business rule. The event is completes until it all its tasks are finished and the business objects’ state has been committed to persistent storage.

Figure 1: Behavior Architecture

An organization’s business rules are an essential component of its collective knowledge. Unfortunately, this knowledgebase isn’t always documented in an accessible, integrated and consistent manner. Often, like folklore, the knowledge is passed between the business players and down through the generations of business policy makers without actually being recorded. As the business information analyst, we are often not part of that knowing group. For example, suppose you are the information analyst facilitating the business players in determining how they plan to become more customer-focused. They’ve decided to provide preferential treatment to their preferred customers. During the brainstorming session, one participant explains "we don’t want to bounce a preferred customer’s checks". Everyone else heartily agrees (except the audit guy who’s worried about the financial exposure implied by this business rule). But this simple statement only makes sense if you are "in the know" about overdraft accounts and customers and all the rest of the knowledgebase (tables 2 – 5) that provides the context to our business rule statement.

We serve as the scribes who record the organization’s business rules. We structure and diagram them so they are easily understood by both business and information technology stakeholders.

Table 2: Definition Business Rules

Business State business rules are a special type of definition business rules that describes a subset of related business objects that satisfy a specific set of qualification criteria. Business State business rules can be the most volatile. The business, especially marketing, always seems to be identifying new states that they wish to track or changing the definition of the business state by altering the qualification criteria. Business States are defined in terms of the values that can the assumed by the properties of business objects. For example, we see that a "Preferred Customer" is that set of customers who:

• are people
• have a cross-sell index greater than or equal to 3
• a rolling twelve month average balance that is greater than or equal to $5,000
• a rolling twelve month average revenue of at least $125

Table 3: Business State Business Rules

A Derivation business rule specifies how the value of one business object property is derived from the values of other business object properties (table 4). It can be argued that business object states are really derivation business rule because you can derive the state from the qualification criteria. However, I believe that business object states have a distinct enough pattern to be treated as a separate business rule category.

Table 4: Derivation Business Rules

Constraint business rules have the most direct impact on the behavior of the organization. They describe how an event is to respond when the specified condition is detected. The action to be taken may be procedural, specifying the dependencies between the tasks to be performed. In the overdraft example, the tasks span two days. On day 1, all customers whose accounts are in the overdraft state are to be notified to give them a chance to cover their negative position. Once the current day’s financial transactions have been processed, the debits for those accounts that are still overdrafted, but are owned by a preferred customer, are paid. The debits for the remaining accounts are refused. In other words, if you are not a preferred customer, your checks will be bounced.

Table 5: Constraint Business Rule

Our final responsibility is to maintain a repository where the business rule statements are maintained and linked to their information systems component counterparts. The business rule repository represents the enterprise’s information asset warehouse. It can be navigated so that the interplay between business rules can be traced. The business rule repository should be able to answer the questions: "what’s the impact on my business systems if I change this business rule?" and "how will my business behave if I change my business rules in the following manner?".