Terry MoriartyTerry MoriartySeptember, 1998
When Barbara von Halle and Alice Sandifer published their first business rule articles,1 I wonder if they realized that they were starting a revolution of sorts. The interest in business rules has grown throughout the decade as numerous articles and conferences have been devoted to the topic. Advocates have espoused that the business rule approach allows the development of flexible applications and databases that are amenable to change. These articles have raised the interest level in the business rules approach as an alternative to the more traditional information analysis approaches, such as information engineering and structured analysis and design. Analysts have invested considerable effort to determine how the business rule approach can be integrated with object-oriented concepts.
The analysts have been successful in raising the expectations of what the business rule approach can do for an organization. But to what degree can you use the business rule approach to manage the information resource? It's been five years since I proclaimed the business rule approach as the next paradigm.2 Just how far into that paradigm shift have we come? Unfortunately, we've only taken a few baby steps. The most notable developments are the business rule categorization schemes that we can use to analyze the business statements to determine whether we have a good, atomic business rule set. Some vendors have delivered products that claim to be business rule driven, most notably Usoft and Vision. However, their products focus is on implementation of business rules in an automated system, not on the discovery and analysis of business rules.
Analysts approach business rules only from the perspective they are interested in, but we need to step back and view business rules from the more global perspective. What facilities must be available to manage business rules across the entire life cycle? How do we know which business areas subscribe to a given business rule? How do we manage conflicting and evolving business rules? Can we predict how a business process will execute based on the state of the related business objects and the business rules that control the process's behavior? How do we manage the release of a new business rule set into the business environment?
To answer these questions, there must be a business rule management facility available through which the evolution of the enterprise's business rules are managed. The facility must support the following business processes for business rules:
• Discovery
• Business area "line of business" subscription
• Conflict management
• Business rule classification
• Information resource object mapping
• Change management.
This process involves the discovery, analysis, and documentation of business rules from the perspective of the subject matter expert (SME). Currently, most business rule analysts are developing their own database applications to support the need to represent business rules consistently. However, the business rule management facility must be much more robust than such home-grown attempts. As our SMEs become more comfortable with the business rule approach, they may enter their business rules directly into the business rule management facility. Consequently, the interface must meet the needs of the SME, as well as those of the business rule analysts. A variety of approaches to specify business rules must be available, such as natural language parsers or approaches that let the user use the point-and-click approach to specify their business rules based on the knowledge already acquired from analyzing prior business rules. SMEs should be able to enter business rules without knowing how the analysts will eventually classify them. But we must also present the SMEs with some easy-to-understand classifications of business rules that lead them through a process yielding a business specification consistent with the type of business rule being captured.
The business rule management facility must also provide access to powerful report writing capabilities. Impact analysis, business rule review reports, and entire deliverables must be generated from the business rule management facility.
Different areas of the organization often believe that what they do is entirely unique to them, when in reality, each business area must respond to the same types of business events, have similar information available to complete those events, and establish business rules to ensure that the organization's goals are met. However, each business area supports a "line of business" that may have its own vocabulary, procedures, and approaches for allocating resources to fulfill their missions. So what appears to be uniqueness may really be a verbal smokescreen that disguises the commonality of the business processes, information, and rules.
When we take an enterprisewide view for business rule management, we can share business rules across the lines of business. We can present existing business concepts to a new business area as a starter set. A business area subscribes to a business concept if it agrees that the concept is applicable to its line of business. It is possible that the terms the business area uses when referring to the business concept are different from those the other business areas already analyzed. Because the terms a particular business area uses when referring to a concept may differ from another business area's, we must cross-reference the terms across all business areas. At this point, the known business rules for the business concept can be presented to the business area's SME, who can then determine whether to subscribe to these existing business rules or introduce new ones.
A line of business may also subscribe to scenarios supporting a business concept. It takes a lot of time to develop a robust scenario, so there are advantages to reusing scenarios across business areas whenever possible. Scenarios are easy to share when different business areas offer the same products to different markets based on geography. For example, the scenarios developed by the domestic retail bank to illustrate consumer households may be readily usable by the international retail bank. If the business rules vary between the domestic and international banks, then they can use the existing scenarios as a basis for enhancements.
A business assumes ownership when it subscribes to a business rule or scenario. It is co-owners with the other business areas that subscribe to the same business rule, so we must assess the impact of any change to a business rule or scenario for all the co-owners. A stewardship program must exist through which business concepts, business rules, and scenarios are validated.
Business rules are considered to be in conflict when they cause the same business process to behave differently. For example, one business area's business rule may state "an account is owned by only one customer," while another business area's business rule is "an account may be owned by many customers."
A conflict exists if, for some reason, the enterprise is at risk if the business rules are implemented. You cannot analyze conflicts at the business rule level. To resolve conflicts, we must consider the context in which the business areas conduct business. For example, the first business rule may have come from the Individual Retirement Account business unit where this business rule is mandated by federal regulations. The second business rule may support both the lending and deposit business areas, which are not subject to the same regulations. So while on the surface, these business rules appear to be in conflict with one another, in this case, the business rules are not in conflict; they are simply variations of the same business concepts: account ownership and customer.
Resolving conflicting business rules is one of the most important functions your business rule stewardship program performs. As business rule analysts, we can't resolve the conflict. Our role is to identify business rules that may be in conflict, notify the appropriate business area stewards (that is, the SMEs), and if necessary, facilitate the process of resolving the conflict. The stewards have the responsibility of determining whether the business rules are truly in conflict or simply variations of one another.
A business rule classification scheme provides a mechanism for extracting essential, atomic business rules from business ramblings. If a statement can be classified in more than one business rule category, that statement does not yet qualify as a business rule statement. The most widely accepted classification scheme was developed by the GUIDE Business Rule project.3
Using a business rule classification scheme, we should be able to answer a number of questions. First, is the statement a well-formed business rule? Given a business statement, we should be able to use the classification scheme to extract atomic business rules, each mapping to one business rule category. Next, are there any other business rules about the concept being analyzed? For example, if the natural language statement provides a definition for the term customer, what other types of business rules can exist for a term? The first question is aimed at ensuring that all the business rules are accurately stated, while the second leads to a complete and consistent set of business rules.
The business rule classification scheme seems to be very personal to an organization. I've yet to have a client that was willing to accept an existing classification scheme as its own. The process of defining the business rule categories seems to be fundamental in becoming comfortable with the business rule approach. Consequently, the business rule management facility must let the classification be customizable.
An information resource object is a component of the information resource used to represent the organization's business concepts and business rules from an information management perspective. The objects depicted in our data and process models are information resource objects. In fact, the information resource object types are dictated by the modeling methodology the organization uses. Those employing information engineering will represent their information resource objects as entities, attributes, relationships, functions, processes, and tasks. Object-oriented approaches will represent the same business rules using objects, object classes, attributes, associations, methods, actors, and responsibilities.
You must map business rules against the associated information resource objects. To facilitate this process, each business rule category is mapped to its supporting information resource constructs. Business rule researchers are identifying formalisms or language patterns for each business rule category. The most widely understood formalism is the "noun-verb-noun" pattern which can be transformed into "object class-association-object class." If the links between the business rule statements and the information resource objects are to be created automatically, a formalism needs to exist for each business rule category in your classification scheme.
The business rule classification scheme is instrumental in mapping business rules into the information resource objects required to support the business. Several information resource objects may need to interact to ensure that the business rule is properly enforced. Likewise, the same information resource object may have a role in enforcing many different business rules. This link between the business rules and their information resource objects is essential to understanding why a specific information resource object is defined in a specific manner. If the assertions depicted by our information resource models do not support the SME's business rule statements, then we must be able to identify rapidly which SME business rule statements we used when designing the information resource objects. Often the SMEs' business rule statements may change during the information resource model validation sessions, as they realize that nuances of the business rules have been overlooked.
The information resource objects are also linked to the application portfolio objects that automate the enforcement of business rules. The application portfolio objects include programs and control statements; DBMS objects such as tables, views, and columns; and test cases, plans, and test data. Consequently, the information resource objects are pivotal within the business rule management environment, simultaneously providing a view into the SMEs perspective of the organization's business rules and into how the business rules are enforced by the application portfolio.
Business rules are fluid, constantly changing in response to the business environment. They change when the business achieves a goal and establishes a new one. They change when the business fails to achieve a goal and modifies the strategy for attaining the goal. They change in response to external forces, such as regulations, actions by competitors, and the availability of new technology. While not all business rules change at the same rate, I can almost guarantee that somewhere within your organization, a business rule is changing.
A business rule doesn't normally stand alone. A change to one business rule must be coordinated with modifications to other business rules. Therefore, release management is an essential responsibility of the business rule management facility. A release is a set of business rules to be introduced into the business environment as a unit at a specific point in time.
Business rules are continually assessed to determine how effective they are in achieving the organization's goals. If we find a deficiency in the business rule or in the support for the business rule, we must take actions to correct the situation. The deficiency generates at least one requirement against the information systems, and those requirements identify enhancements that we must make to the organization's applications, which are assigned to specific application release. The implementation of a business rule release must be carefully coordinated with any supporting application releases. When a business rule requires a corresponding modification to the information management and application portfolio objects, we must take care to map the new version of the business rule to its counterpart version within the information management environment.
The business rule management facility must be able to track business rule changes as they occur and control the process by which the enhanced business rule set is introduced into implementation. The capabilities associated with impact analysis, version control, and release management must be available to the business rule management facility.4 When a business rule is targeted for change, the impact analysis must report the effect on the entire business systems, including the affected information resource and application portfolio objects. Over time, a business rule may have many versions. In some cases, the older versions must remain available so an organization can perform an assessment of the business. For example, when trying to understand why an organization didn't achieve a goal under the existing business rules, management may want to simulate business under the prior set of business rules to contrast performance.
Ideally, the business rule management environment is the point of all changes to the enterprise's business rules. Business rules can be implemented as data values held in tables or rule specifications that are input to expert systems rule engines; hard-coded within the database as tables, columns, foreign key specifications or as stored procedures or triggers; or hard-coded within the application programs or as object methods. The business rule management facility should know how each business rule is implemented. For those that are supported through data values or rule specifications, the changes should be made directly from the business rule management facility. However, if the business rule is supported by hard-coding within the application portfolio, the business rule management facility should generate the necessary change requests to the IT organization.
The business rule management facility must provide access to a business rule testing and staging environment through which changes can be executed to ensure that the business processes continue to behave according to plan and then are implemented into production. While this facility may already exist for testing the changes made by IT, such facilities may be new to the businesspeople who have the authority to make direct changes to their business rules.
To date, I have not found any product that supports these business rule management needs; however, these needs are so similar to our information resource management requirements that repository technology should be readily adaptable to the business rule management needs. But repositories have historically been weak in the two aspects of the business rule management facility that are essential: easy-to-use interfaces and change management, so I'm on the hunt for products that we can use as a business rule management facility. I welcome responses from anyone who represents this type of product, has developed an approach to managing business rules, or who is simply struggling to make business rule management a reality in his or her organization. This is fledgling technology, but without it, I fear that the business rule approach will fail.
References
1. Sandifer, A. and B. von Halle. "Designing by the Rules." Database Programming & Design. January 1991; "A Rule by Any Other Name." Database Programming & Design. February 1991; "Linking Rules to Models." Database Programming & Design. March 1991.
2. Moriarty, T. "The Next Paradigm." Database Programming & Design. February 1993.
3. GUIDE. Business Rules Project: Final Report (revision 1.2). October 1997.
4. Struck, D. and M. J. Willshire. "Business Rule and Database Schema Version Management Issues." Database Design Summit Handout. September 1997.
A more complete list of business rule-related references can be found at scis.nova.edu/~louisl/rules.html.
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