A business rules approach to systems development promises to be the most practical and desirable way to build systems. It can help you build better, easily changeable systems faster than any previous approach. With this in mind, there is a need for a step-by-step practical approach for building systems using a business rules approach. This article provides insight into such an approach.

A system built according to the business rules approach has many advantages over other systems. However, given the pressures of e-commerce, the two most important advantages are that a business rules system can be built faster and is designed to easily accommodate changes in the business with minimal disruption. Therefore, a business rules approach places a new emphasis and formalism around capturing, validating, and automating the rules of the business so that the business can easily change those rules as it sees fit.

The most significant aspect of the business rules approach in Business Rules Applied: Building Better Systems Using a Business Rules Approach is the introduction of a Rule Track into a systems development methodology. The steps, guidelines, techniques, and examples of activities in this track guide the reader in understanding what business rules are, why they are important to the business, why it is important not to bury the business rules in code again, and how to analyze and deliver the rules as a valuable, changeable aspect of the resulting system. The Rule Track leads to fascinating new possibilities, precisely because it delivers, for analysis and management, a business rules asset. The business rules asset may turn out to be the most important deliverable that information technology professionals can deliver back to the business.

In a Nutshell

A business rules approach to systems development, like most systems development methodologies, has six conceptually different phases (even if carried out incrementally). These are shown in Figure 1 as scoping, discovery, analysis, design, implementation, and testing. Figure 1 also illustrates that four phases (Discovery, Analysis, Design, and Implementation) have four discrete tracks: Technology, Process, Rules, and Data.

The figure does not intend to suggest an old-fashioned waterfall approach to systems development. However, for tutorial purposes, it is important that you understand the conceptual differences among the phases. For example, it is very important to do a thorough job with scoping and planning. Keep in mind that a business rules approach aims to deliver up front a strong architectural foundation (to accommodate future business changes). This means that incremental systems delivery may become the adding, changing, and retiring of rules or rule sets within that foundation. This requires that the first increment include the stabilizing aspects of the information architecture, rule jurisdictions, and rule stewardship. When this is so, the discovery phase can occur in incremental pieces, followed by analysis, design, and delivery, while more discovery occurs in parallel.

The Subtle Differentiators

Following a business rules approach, during the Scoping Phase, you pay special attention to the business motivation for your project. Aspects of this motivation may include objectives, goals, strategies, tactics, and policies as outlined in Organizing Business Plans: The Standard Model for Business Rule Motivation (www.BusinessRulesGroup.org). These motivational aspects are extremely important because they are the fundamental justification for the rules you uncover, deliver, and change during the life of your system.

As you move into the discovery of requirements, a business rules perspective drives you to seek important decisions behind the target system and dissect these into atomic rules, capturing them in a rules repository. You can extend an existing repository, utilize an existing CASE tool, or build a simple rules database. Figure 2 illustrates a correlation between use case interactions and decisions. This use case has 9 user interactions and 6 decisions so far. You would create another table (not shown) to correlate decisions to individual rules. From here, you can group decisions in responsibilities and assign responsibilities to object classes if you were not using rules technology.

As you progress into analysis, your business rules perspective becomes most intriguing. You employ steps and techniques specifically aimed at unveiling a logical rule model. A logical rule model, like a logical data model, has several components. First, it contains a set of high quality rules in much the same way that a logical data model contains a set of high quality attributes. Figure 3 summarizes criteria for high quality rules and how you can achieve these.

A logical rule model also depicts the dependencies among rules, sometimes graphically. This is not unlike the way that dependencies among attributes are depicted graphically in a data model diagram. Third, the logical rule model associates each rule to the information it references and the knowledge it creates, if any. This keeps the rules grounded in semantics. It also facilitates impact analysis when rules need to change.

Finally, in the design phase, you consider alternatives in implementation options. However, you pay close attention to those options that enable the delivery of rules in a way that accomplishes four significant objectives. It is easy to remember these objectives as the STEP principles because the first letter of each one, when concatenated together, spell STEP:

• S is for separating rules from the rest of the system so you can reuse them
• T is for tracing rules to the reasons they exist and where they are implemented so you can assess change
• E is for externalizing rules so everyone know can know what they are and challenge them, and
• P is for positioning rules for easy and quick change at any time.

Figure 4 summarizes, for each phase, how the four STEP principles are achieved when following a business rules approach.

Onto Design

This article is not meant to be a complete design methodology for designing systems. Instead, it highlights those aspects of system design that have a different emphasis and approach when delivering a business rules system. The steps below focus on introducing a rules capability into your system design and how the rules capability influences the design of the rest of the system.

The term rules capability is the automated functionality that manages and executes rules, in a sharable manner across applications if possible. The rules capability may be a commercial product, homegrown software, or may be part of application code or the database management system. It may be a combination.

Because the goal is to introduce the concept of a rules capability, the physical rule design addresses four considerations:

• Specifications on how the rules capability functions
• Assignment of rules enforcement to the appropriate system tier
• Detailed specifications on how each rule is implemented in its target tier, and
• Insights into how all layers communicate with the rules capability.

To keep it simple, let's consider three options. Option 1, called a Fast Path, is aggressive in that it leads you to fully leverage a rules product for all that it can do. Option 2, called a Common Path, presents a middle ground whereby it leads you to delegate traditional integrity rules to the DBMS while you enforce remaining rules in a rules product. You are likely to consider the differences between two general types of rules products: service-oriented and data-change-oriented.

A service-oriented rules capability executes rules upon request by a running application, not because the application directly attempted to touch data. In this case, the rules service waits until an application calls on it to apply rules to data. Usually the application passes the data to the rules service, the rules service may also retrieve and update data from a database, the rules service executes the rules, and the rules service sends the results of the rule execution back to the calling application. The application can then decide to abort the transaction, update the database, or carry out other actions. Also, the application handles all other logic such as session management, database calls, and user interface management.

A data-change-oriented rules capability executes rules in response to a running application touching data for which rules have been declared. With this approach, as an application attempts to update data, the rules capability watches for conditions that must be true about the data as well as conditions that should cause a reaction, such as the creation of new data. The data-change-oriented rules capability watches out for the complex conditions specified in rules.

Finally, there is Option 3, called a Comprehensive Path. This option leads you to consider all alternatives from purchasing a rules product to building your own and from enforcing rules in the rules capability to enforcing them elsewhere.

Option 1: The Fast Path

If you are interested in conducting a quick prototype to test the business rules approach and corresponding technology, you can apply the steps below rather than spend a lot of time on detailed design decisions reflected in the fuller design methodology. These steps prescribe that you put all possible rules into the rules product.

1. Select a rules technology product that is easy to use. This means selecting a product based on only four criteria. First, the product supports either the data-change-oriented or service-oriented rules approach, depending on what your system seems most appropriate for. Second, it supports the rule classifications that are most important to your prototype. Third, it uses a rules language that is intuitive to you. And, fourth, it integrates easily with your technology environment.
2. Select a relational DBMS product. The reason to select a relational DBMS product is that most rules products work most seamlessly and effectively with these products. In a prototype, you don't want to spend time tuning the data structures or making up for deficiencies in integrating a heterogeneous data environment. You want to focus primarily on the rules aspect and how it can work for your organization. If you already are using a relational DBMS product, review its functionality for the prototype.
3. Define the data or objects to the rules product. Quickly sketch a logical data model (or object class model) and enter it into the rules product. Do not, at first, worry about how to share such models from your modeling tool with the rules product. Do not even focus on creating an extremely high quality model. The goal is not on how to create these definitions in the rules product. Instead, you want to focus on gaining an understanding of what the rules product needs to know to execute rules.
4. Place all rules in the rules product. Rather than agonize over selecting the optimum tier for rule execution, be brave and put all rules in your rules product that it can handle. You want to focus on learning how to manage rules separately from other components and on learning the advantages and disadvantages of your selected rules product.
5. Determine, confirm screen/page flow and create screens. You can accomplish this by creating the workflow analysis deliverables. Or you can simply sit down with business people and quickly sketch a preliminary flow. You need to do this because it establishes the first sense of rule execution sequence. Create the corresponding screens or Web pages. Do not focus too much on screen design. You want to learn how intuitive it is to make the connection from the screen to the application to the rules, as well as how to make rule violation messages intuitive to the business community.
6. Change rules. This is perhaps the most important step. Invite participants to suggest rule changes. Make the changes and illustrate the changed system. The focus is on how easy it is to change rules and how difficult it might be to change underlying data structures.
7. Evaluate the experience. Have participants document their comments. In particular, ask them to consider how such capability (to add and change rules easily) can change the way they perform their jobs and how this may positively impact the business as a whole.

Option 2: A Common Path

If you are interested in using rules technology quickly, but you are comfortable supporting certain rules in the DBMS, you can consider the steps that follow. These steps prescribe that you put standard data integrity rules in the DBMS and other rules in a rules product.

1. Select a rules technology product. In this case, do a thorough product comparison and select the product you believe will be strategic for your organization.
2. Select a relational DBMS product. The reason for this step is the same as in the steps above. The first prototype or system aims to test the rules layer, not so much the idiosyncrasies of data integration and connections. Again, if you already are using a relational DBMS product, review its functionality for the prototype.
3. Enforce all traditional data integrity rules in the DBMS. This is often a common decision because people are most familiar with this enforcement of data integrity rules, performance is known and understood, and these rules cannot easily be circumvented. These include primary key constraints, foreign key constraints, column null constraints, and column value checks.
4. Enforce computations and aggregations in the DBMS. Often this is a good design decision because these are data-intensive operations and perform best or comfortably in the DBMS.
5. Enforce other rules (inference, action enablers) in the rules product. Many organizations view the rules layer as the place for inference rules, action-enabler rules, and complex constraint rules. Inference rules control the flow of decisions within the system. Action-enabler rules influence the flow of control to a component outside the system. Complex constraint rules prevent unwanted database updates. Following this option, the other rules (computations, traditional constraints) are seen as data-oriented rules and are delegated to the DBMS.
6. Determine, confirm screen/page flow and create screens. This is the same as the similar step above. In this case, you may need to design and develop application interfaces to the rules layer.
7. Change rules. This is the same as step 6 in the Fast Path list above.
8. Evaluate the experience. Again, document the advantages, disadvantages, opportunities, and lessons learned.

Option 3: A Comprehensive Path

In a business rules approach, you define the business logic layer to have two different types of functionality. The traditional functionality is that which controls the specific process flow for the target application, but not the (shared) rule execution. The new functionality is a rules capability that manages execution of shared rules on behalf of applications.

You need to determine in which tier you will enforce rules. If rule technology were perfect, you would put all rule enforcement in the rules layer. You will need to tune the underlying database(s) for performance and perhaps functionality requirements. You can also tune the rules by relying on product-specific transparent tuning options. When performance or functionality limitations are not acceptable, you can tune rules by moving enforcement to another tier, duplicating the enforcement, or changing the expression of the rules. These concepts are not unlike those you apply to database design.

Figure 5 illustrates how the design of data, process, and rules integrates. Essentially, the first box in the rule track represents your focus on planning for or acquiring a rules capability as part of your technology and application architecture. Naturally, all design specialists (database designers, rule designers, process designers, and network designers) should be involved in this decision.

The second box indicates that you will make some design decisions regarding the rules capability, whether you buy or simulate one. At this point in time, you translate your logical rule model to a preliminary rule design. The preliminary rule design is independent of your implementation environment, except for acknowledging at least three separate layers: one for core process flow, one for data management, and one for rule execution. The preliminary rule design represents, within your architectural tiers, the ideal data-driven, rule-driven, process-driven approach to design. If you do not carry out the tuning steps in the other sections of this chapter, you delegate total performance responsibilities to the technology you selected for each layer.

Because technology is not perfect, the third box illustrates that, should functionality or performance is an issue, you consider tuning the database design before tuning the rule design.

Finally, the last box indicates that you design the rest of the system. The rest of the system, if you have designed the database and rules, means designing for the process track.

Details on these steps are in the book, along with guidelines and a case study. These steps are summarized in Figure 6. Details on how to implement aspects of the case study using representative rules products are also provided in the book.

Parting Thoughts

Needless to say, the design of your system is key to its success. A good quality design, however, is based on a solid foundation of good business analysis. This foundation is most solid when you have analyzed each perspective of the system (data, process, and rules) using techniques and criteria for quality that apply specifically to each of those perspectives. Most systems development methodologies lack steps, techniques, and deliverables for rules.

In the end, the business is likely to measure the value of your system by how easily and quickly it accommodates business change. It will be most useful if the STEP principles and corresponding techniques become a yardstick by which to measure rule products, software development approaches, and the quality of new systems themselves.

If you follow a business rules approach to completion, your system will distinguish itself from all previous systems in four important ways, consistent with the STEP principles:

• Its rules will be separate from other aspects of the system so the business can know them, challenge them, and optimize them.

• Its rules will be traceable to the business objectives they aim to achieve and to all implementations where they are carried out so the business can know where the rules are actively guiding its operations and decisions.

• Its rules will be externalized so everyone can know what the rules are, thereby creating a knowledge-rich enterprise.

• Its rules will remain always positioned for change so that the business can proactively exploit those rules (its collective intelligence) to become whatever it wants to become whenever it wants to do so.