THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com January 2002

[The following is an excerpt from chapter one from the book titled Business Rules Applied by Barbara von Halle, copyright 2002, Wiley & Sons Publishers.]

A business rules approach is a methodology—and possibly special technology—by which you capture, challenge, publish, automate, and change rules from a strategic business perspective. The result is a business rules system, an automated system in which the rules are separated, logically and perhaps physically, from other aspects of the system and shared across data stores, user interfaces, and perhaps applications.

As you can see, at the heart of a business rules approach is an appreciation for rules as a valuable asset for a business organization. In fact, a business rules approach to systems development elevates the importance of business rules to the business and carries that importance into the organization’s systems development function and approach.

In some cases, organizations are truly leveraging the business rules approach by incorporating it into business process engineering or reengineering initiatives. To these organizations, a business rules approach is an avenue through which to drive change across large business scopes.

Business rules are a formal expression of knowledge or preference, a guidance system for steering behavior (a transaction) in a desired direction. On the grand scale, business rules, then, are the guidance system that influences the collective behavior of an organization’s people and information systems.

A business rules approach aims to deliver that guidance system as externalized rules, automated as an integral and active component in systems architecture. Therein lies the new emphasis: a knowledge-focused way of designing new systems. It is no longer acceptable to bury that knowledge deep in code where no one knows what it is. It is equally no longer acceptable to have that knowledge locked in bondage where it cannot change on demand.

A business rules approach, by deploying technology so that it externalizes and manages the thinking or decision-making capacity of an organization, empowers the business to use that technology as an extension of intellectual power.

Where the Business Rules Approach Is Effective

 The pressures facing many businesses today can seem insurmountable. Most of these pressures require changes in the way the business operates through its underlying automated systems. Even more challenging is the realization that customers, competitors, or legislative requirements impose many of these pressures. The following nine common scenarios in today’s business world can be improved by applying a business rules approach:

1. The business needs to change, but its systems are barriers to change. Most of today’s operating systems are similar to black boxes because there is a lack of documentation and knowledge about them. Without proper documentation and knowledge, the task of upgrading the systems is time-consuming and costly at best, and impossible at worst. The lack of knowledge of internal and buried system logic became apparent in the costs of the Y2K projects. Also, the average shelf life of a software release is measured in months and customer expectations have accelerated. The need to deliver upgrades to software is greater than ever before.
2. New legislative mandates and directions are underway that not only require adherence, but also open the doors to new business opportunities. Adherence to new legislative mandates usually requires changes to existing systems. New business opportunities may require changes to existing systems or the building of new systems. For example, the healthcare industry is an example of changing rules and emerging opportunities. In the area of healthcare providers, new types of medical benefits and rules for payment and pricing have emerged. Also, in pharmaceutical research, for example, some changes involve reducing clinical trial times for treatment possibilities for life-threatening diseases.
3. Emerging products, services, and partnerships are arising out of the Internet marketplace. For example, BtoB (business to business) relationships are emerging through the Web where the rules of these relationships need defining and will evolve over time.
4. Virtual competition looms. Virtual competition can appear if similar products and services are available through a competitor who has only a Web presence, not a walk-in presence.
5. Mergers and acquisitions are prominent. When this occurs, there is a need to consolidate information, customer bases, and purchases, all requiring evaluation of existing policies, practices, and rules.
6. Business process reengineering continues. Some of these efforts sometimes aim to create a consistent global perspective for a given process. Or a BPR effort can aim for a customer-centric process. Regardless, these efforts take a top-down view to streamline a business, make it more effective and smarter. BPR initiatives often change culture and strive for consistent or at least visible policies and rules across organizational barriers.
7. The application backlog is unending. There is an increasing desire for e-business applications. IT functions need to develop new systems and change existing ones faster than ever before.
8. There continues to be a never-ending shortage of application system developers. This is especially true for the Web development world. Resources become more expensive.
9. There are shortcomings of other approaches and technologies. These include information engineering and object-orientation.

Implementing the Business Rules Approach Now

There are many motivating factors in today’s fast-paced, e-oriented business world to take an evolutionary step forward in systems development. Merely consider the far-reaching influence, promise, and pace of the Internet, in business and personal life. It’s enough to make your head spin.

New dot-com companies have but a short time to prove their worthiness. Traditional (non-dot-com) companies strive to conquer the Web, to be among the first to provide customer service, entice new customers and partners, and introduce new or enhanced services. The Web page is the new calling card. Competition is a mouse click away from your customer. The Internet is leveling some marketplaces and confusing others.

Regardless, the software behind the Web page is the new business image and often the first touch with the customer. The world of e-transactions is moving faster than ever and changing as it moves. How can you keep up with the business? Is there a simple but elegant alternative to how you historically have built systems?

A business rules approach to systems development promises to be the most practical and desirable way to build systems from now on. A business rules approach builds better, changeable systems faster than any previous approach. The time has come to capitalize on the promises of building systems using a business rules approach.

This seems also to be the opinion of C. J. Date, who states as the first sentence in his recent book, “An exciting new technology called business rules is beginning to have a major impact on the I/T industry—more precisely, on the way we develop and maintain computer applications” (Date 2000). He further suggests the eventual impact of a business rules approach when he states later, “business rules can be seen in some respects as the next (and giant) evolutionary step in implementing the [original relational vision].”

John E. Mann expresses a similar opinion (Mann 2000). “The Internet is apparently creating many cases in which the rules-based approach is the only one that makes sense.”

Unique Aspects of Business Rules Approach

Taking the business rules approach offers three unique benefits:

• The rule track
• Integration of object-orientation, information engineering, and rule formalism
• Correlation of rules to business motivation (strategy, objectives, goals, tactics)

The most unique aspect of a business rules approach is the introduction of a rule track. It represents the set of rules behind the interactions and over the data, where the rules are managed as a separate, externalized, logical component.

You can choose business rules technology that is designed specifically to manage the execution of a rule collection. Alternately, you can utilize nonbusiness rules technology, even homegrown Java, but in a way that leverages the concepts and advantages of a business rules system.

The second unique characteristic of a business rules approach is that it represents the integration of object-orientation, information engineering, and rule formalisms.

The third unique characteristic of a business rules approach is that it correlates the underlying rules to many aspects of business motivation. These include goals, objectives, strategy, and tactics. In this way, the business can evaluate the effectiveness of the rules in guiding the business toward its desired ends.

Advantages of Building Systems Using a Business Rules Approach

At a glance, ten advantages of building systems using a business rules approach include:

Simplicity. A business rules approach is simple to understand both for business and technical people. Specifically, the concept of a rule, even different classifications of rules, is fairly intuitive. Business people may not be overly interested in data models, process models, or object models. But they are definitely quite interested in business policies and rules. Indeed, it is through policies and rules that business leaders steer the business.

Theoretical base. The concept of rules as protecting data integrity has its origins in the relational model. Additional research has been conducted into active database systems. There is certainly much theory and practical experience with rules from the field of knowledge engineering.

Small number of necessary, nontechnical concepts. At the core of a business rules approach is the rule itself. There are a few concepts around a rule, such as decisions, rule patterns, rule families, and rule clauses. A decision is simply a logical grouping of rules. Rules can be grouped together into rule patterns for analysis purposes based on similar clauses in the rules. Rule patterns can be grouped together into rule families based on similar output from the rule. And, of course, rules are comprised of one or more rule clauses.

Rule independence. A business rules approach aims to express rules in a syntax that is independent of technology and applications. While there is no industry standard for expressing rules, this book provides sample templates.

Ease of application development. With the emergence of commercial rules technology, various kinds of rule processing are made easier. With some products, the application calls the rule product when the application needs a decision to be made based on the execution of underlying rules. With other products, the rule product supports the execution of rules as a result of data changes. In either case, a rule professional defines the rules once and these are executed on behalf of an application as needed.

Rule reuse. If you choose to use commercial rules products, rules managed within them can be reused by various transactions and can interface with a variety of browsers, database management system (DBMS) products, and other kinds of software. Therefore, you can define and implement a rule, or set of rules, only once, but have those rules active for various purposes. You can even test the rules before you develop the rest of the application. Even if you do not use a commercial rules product, you can design your system so that rules are grouped in logical ways and can be reused and shared.

Simplified systems design. A business rules approach aims to separate core process flow from rule execution. This creates two separate flows: one for rules and one for system execution sequence. You design a business rules system around essential intellectual process flow. That is, by focusing on rules, an analyst can distinguish the absolute dependencies among rules from those that are interesting from a performance or user-preference perspective. In this way, rule execution can be delegated to special rules technology (or homegrown rules capability) while the core system flow (without the rules) is designed by a system designer. In this way, there may be fewer necessary deliverables and possibly less need for coding, depending on target technology. That is, with some commercial rules products, analysts capture the integrity and computational rules of the system and developers express them as declarative rules rather than procedural program code. Some commercial rules products manage these rules, compile them, and determine the point of execution, in much the same way that relational products manage data, select among appropriate access paths, compile access paths, and execute those paths. It may take weeks or months to discover what the rules ought to be, depending on the availability of business expertise. However, once you capture and document a rule, you can implement it in rules technology within a matter of hours. Those hours are spent determining where and how to implement a rule. If you were doing this with previous procedural approaches, you would likely implement the rule, not only using procedural code, but often in various programs or methods. Commercial rules products allow you to implement common rules in one place or even to share common clauses among rules.

Dynamic rules. While rule changes may not be instantaneously possible, you can change a business rules system easily. A rule developer can change one rule at a time, or many rules at a time, and have that change available to all relevant business transactions, again depending on target technology. In this way, a business rules system becomes a platform for business change. The rules themselves become the instruments of business adaptability.

Performance. Commercial rules products are designed specifically to manage and execute rules. Thus, they contain internal logic for how best to do so and for delivering optimum performance.

Incremental systems delivery. A business rules system can be delivered quite easily in incremental pieces. If the first increment includes a solid data foundation, cast with the future in mind, incremental system releases become the delivery of upgraded or additional rule sets to an existing infrastructure.

Benefits to the Business

Most of you realize that technology alone is rarely, if ever, a silver bullet. Yet technology deployed with intelligence becomes interesting and powerful. When you deploy technology so that it externalizes and manages the decision-making capacity or the rules of an organization, imagine the possibilities. You empower the business to use that technology as an extension of intellectual power.

In particular, there are six benefits to the business audience of a business rules approach:

• Change is no longer unnecessarily disruptive and costly.
• Business people are closer to the system specifications.
• Business rules are documented and accessible through a repository, no longer hidden in code. When business rules are in an accessible repository, they serve as a mentor to people operating in a collaborative work environment. Business people know where to find the rules.
• When error messages match to the business rules themselves, business people are able to act with complete knowledge, explanations, and business justifications behind a transaction.
• Systems are delivered faster and for less cost.
• Conclusions reached from data warehousing or data mining are more meaningful when you can associate them with active business rules. The correlation of trends or results to the underlying business rules provides a mechanism by which the business can experiment with changed rules so as to change results.

Benefits to Software Engineers

Software engineers also realize at least eleven benefits in applying a business rules approach. These include:

• A business rules approach can shorten development time because there may be less to do, commercial rules products are often easy to use, and you can reuse rule code.
• A business rules approach delivers systems that are designed to accommodate change.
• Developers can enter business rules into rules technology without needing to understand the full span of the processes using the rules.
• A business rules approach narrows the communication gap between requirements, analysis, and design.
• If application code is generated from rules there is less coding by humans, and consequently less opportunity for error. With less need to code, developers are free to focus more on business requirements.
• Because you can change rules easily, there is little need to freeze requirements. Instead, you can focus efforts on determining the priority of the rule change and proper authorization for doing so.
• A rules layer is a natural layer between the user interface and the database layers. It allows for the opportunity to experiment with rules technology.
• A business rules approach adds to existing methodologies the one link that has always been missing and that, it turns out, may be the most important of all.
• Developing a business rules system can be more cost effective than customizing packages.
• A business rules approach enables rule enforcement across technology environments allowing for migrations from one technology to another and interfaces to multiple technologies.
• A business rules approach positions you for technology evolution.

How Can a Business Rules Approach Deliver These Benefits?

The business rules approach in this book is based on the four very simple principles mentioned earlier, which together deliver the benefits above. This book refers to these principles as the STEP principles. They are:

(S) Separate. This means that you separate the rules from all other aspects of the requirements and in the system itself. You do this primarily so you can reuse rules. That is, if you manage them as an individual asset, you can apply techniques specific for optimizing them and you can change rules independently of other aspects of the system. This includes, optionally, separating rules into rules technology so rule processing is efficient.

(T) Trace. This means that you maintain a connection from each rule in two directions. The first direction is toward its origins. A rule has origins in aspects of the business’s motivation, such as business missions, goals, objectives, strategies, tactics, and policies. You will also keep track of specific metrics, which will be the yardstick by which the business wants to measure the effectiveness of a rule in guiding the organization. therefore, you will trace a rule to its origins so you can determine, over time, whether the rule remains a correct rule by which the organization wishes to steer its course. The second direction to trace is the rule’s implementation. You do this so that you can assess the impact of rule changes. That is, you record all of the places where the rule is executed. For systems, this may include cross-references from the rule to object methods, to DBMS triggers, and various other implementation options. For human execution of a rule, this may include cross-references to policy and procedures manuals.

(E) Externalize. This means that you express a rule in a format understandable to non-technical, business audiences and that you make the rule available to these audiences. You do this so that everyone knows what the rules are, where to find out what they are, and is able to optimize them. Doing this allows business leaders to inspect rules and consider challenging them or measuring their effectiveness from time to time.

(P) Position. This means that you always position a rule for change precisely because you expect rules to change as a regular course of doing business. You do this so that rule changes happen easily and quickly. Positioning a rule for change can mean implementing it in a technology that allows for easy change, such as a commercial rules product. Even without using a commercial rules product, positioning a rule for change means being able to conduct impact analysis when a rule needs to change, such that you know which business events, decisions, and organizations are impacted by the change. It also means that the data foundation supporting the rule is built in a flexible manner such that rule changes should not require expensive and time-consuming database changes.

Keep these STEP principles in mind because they will keep you honest in your own business rules approach. You can compromise any one of them at any time and for valid reasons. But should you do so, do it in an informed manner. That is, make sure you can justify the price paid and the benefits lost.

Table 1.1 contains the benefits of each STEP principle. Using it can help you determine what aspects of this methodology you can leave out, what sacrifices need to be made, and what benefits can be missed.

Table 1.1 STEP Principles and Their Purposes

1. Separate Rules (principle)
2. • To reuse rules
   • To apply special techniques to optimize rule quality
   • To change rules independently of othe system aspects
     
3. Trace Rules (principle)
4. • To determine, over time, if the rule remains a correct rule for guiding the business
   • To assess the impact of rule changes
     
5. Externalize Rules (principle)
6. • To allow everyone to know where the rules can be known
   • To allow everybody to know what the rules are
   • To allow everyone to challenge the rules
     
7. Position Rules (principle)
8. • for change To enable easy rule change
   • To enable quick rule change

When an organization coordinates the management and automation of its business rules in a rigorous way, the rules become an organizational intellectual asset. When the organization automates those rules across platforms, the business rule becomes an instantaneous and consistent guidance system, the electronic nervous system of the learning organization. If the organization can change those rules at will, the rules become a strategic tool for charting the future.

Before proceeding with this book, ask yourself the following questions:

• Does your organization change itself, from time to time? Might such a change be as small as a change in one rule at a time?
• When the organization wants to change a rule, how does the IT function respond? Does the IT function know where the rule is enforced? If so, is it enforced in a variety of technologies, thereby requiring several sets of skills and testing?
• How long does it take to make such a change? How much does it cost?
• Are there rules that cannot realistically be traced to all of their automated components or that are too expensive to change?
• Are these answers reasonable in today’s business environment?

•  

Barriers to a Business Rules Approach

Many simple and valuable ideas are met with resistance. While there are many reasons for resistance even to good ideas, the two major barriers are cultural discomfort and profit motive, that is, cultural discomfort and price-driven resistance.

Cultural discomfort arises because an organization is accustomed to developing systems according to in-house traditions (or lack thereof) and the pride that accompanies current practices. The idea of changing those traditions, even for a better way, may seem, at first, like an admission of failure. It is sometimes difficult to perceive the fine-tuning of an already successful approach as a sign of leadership.

As a comparison, it may be interesting to contemplate the original resistance to relational technology. When relational products emerged on the marketplace, some visible industry commentators proclaimed that the relational model could not work at all, or could not work well. As a small admission, some resistors hesitantly accepted that perhaps relational technology was appropriate for query systems, but that it certainly was inappropriate for transactional systems. Many people found it difficult to accept the fact that a DBMS optimizer could select a valid access path and perhaps do so better than an experienced programmer. Other people could not imagine a DBMS that did not rely on visible intrarecord pointers because these people could not conceive that a DBMS without such visible pointers could ever perform acceptably. Most of these resistances were either untrue or have been overcome.

Profit-driven resistance is interesting because today’s business world is accustomed to reducing all ideas to profit potential. Without very short-term profit realization, good ideas and approaches are slow to gain acceptance. The fast-paced world wants to see profit benefits well predicted and immediate, if possible.

The good news about a business rules approach is that it overcomes both kinds of resistances. From a cultural perspective, there is no doubt that most current systems development practices are seriously lacking in effective management and automation of business rules. Therefore, regardless of an organization’s favorite systems development approach, it is lacking in this regard, but so is everyone else. There need not be a sense of personal or organizational failure. It is simply a maturation process.

Not only that, but the impetus for cultural change usually requires the pain of changing to be less than the pain of not changing. Because the business world now needs new systems that can change on demand, the pain of not adopting a business rules approach may quickly become worse than the cultural implications of endorsing the business rules approach. Further, John E. Mann of Patricia Seybold Group (Mann 2000) states that evolution to a new approach becomes attractive when there are pressures of change and uncertainty, products deliver on a promise, and customer experiences with the approach and products are positive. No doubt today businesses face change and uncertainty. There are rules-technology products delivering on the promises of the business rules approach. There are a growing number of positive and successful customer experiences.

There is another cultural consideration. It is highly likely that your competitors are already investigating a business rules approach and corresponding technology. If these organizations benefit from the advantages in this chapter, other organizations who do not do so will be at a disadvantage and may need to catch up to remain competitive.

The profit motive is also present. As indicated throughout this book, a business rules approach (depending on target technology) can deliver systems faster. More importantly, it can deliver systems designed for change.

There is one more consideration to ponder. Relational technology made its initial successful entrance into the general IT community when it proved to satisfy a need not satisfied well enough by other approaches. In this case, relational first emerged as a technology for supporting decision-support, query-oriented systems. Structured DBMS products, such as hierarchical or network DBMS products, did not do this well at all and other approaches, such as inverted file technology, did not do this well enough. So, there was an immediate market need that was satisfied by relational technology. From here, the relational approach and corresponding products found their way into transactional systems and now into data warehousing capabilities.

As a corollary, the business rules approach makes its initial successful entrance because it satisfies the business’s need to work with systems that can change easily, especially where the business leaders themselves more directly guide those changes. A business rules approach begins with the language of the business people and traces those requirements to an implementation that allows for easy changes. This is a niche that is badly needed now. Over time, a business rules approach will become the standard way of developing almost all systems.