What is a Business Rules Approach?
Published: January 1, 2002
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:
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 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:
Benefits to Software Engineers
Software engineers also realize at least eleven benefits in applying a business rules approach. These include:
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
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:
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.
Recent articles by Barbara von Halle
Barbara von Halle - Barb von Halle is Managing Partner of Knowledge Partners, Inc. (KPI). She is co-inventor of the Decision Model and co-author of The Decision Model: A Business Logic Framework Linking Business and Technology published by Taylor and Francis 2009. She is the fifth recipient of the Outstanding Individual Achievement Award from International DAMA, inducted into the Hall of Fame in 1995. Known as a business rules pioneer, she has consulted in this area for more than 10 years. She is an invited keynote speaker at conferences in the U.S. and Europe.
Her first book, Handbook of Relational Database Design has sold more than 21,000 copies. She was the most popular in Database Programming and Design magazine for many years.
Other book publications include Business Rules Applied and The Business Rule Revolution. Her recent article in
Intelligent Enterprise magazine features case studies from Oregon State, Freddie Mac, Dell Financial Systems, and Pershing LLC.
Barb can be found at www.TheDecisionModel.com where new announcements and materials on the Decision Model appear as well as a link to
purchase The Decision Model: A Business Logic Framework Linking Business and Technology.