Building a Business Rules System, Part 1

By Barbara von Halle

No one doubts that we are in the midst of a major flurry of systems development. 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 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 we keep up with the business? Is there a simple but elegant alternative to how we historically have built systems?

Consider the following statement by C.J. Date, "An exciting new technology called business rules is beginning to have a major impact on the IT industry ­ more precisely, on the way we develop and maintain computer applications." He later says, "Business rules can be seen in some respects as the next (and giant) evolutionary step in implementing that... [original relational] vision."¹

The time has come to capitalize on the promises of building business rules systems.

What is a Business Rules System?

Simply put, a business rules system is an automated system in which the "rules" are separated (logically, perhaps physically) and shared across data stores, user interfaces and applications. Refer to Figure 1 for a simplified representation of this concept.

Figure 1: Possible High-Level Conceptual Architecture for a Business Rules System

To achieve this, the system must be developed according to a business rules approach. In this five-part series, the phrase "business rules approach" includes both a methodology by which rules of a business are captured, managed and automated as well as a technology for managing the rule automation (and change) process.

As you will 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. A business rules approach is a methodology by which aging rules are captured, challenged, published and positioned for ongoing change. A business rules approach in these cases includes technology (usually home-grown) for expressing, accessing, publishing and managing rules from a strategic business perspective.

Whether you consider a business rules approach a methodology for the business or for systems development, the business rules perspective focuses on the thinking or decision-making capacity of the organization. The business organization sets the rules by which relevant parties such as customers, suppliers, employees and corresponding systems are to behave. The rules (or absence of rules) represent the degrees of freedom that an organization allows for its customers, employees and partners. In the latter case, the business organization may allow the supplier or customer to establish (and change) his or her own rules of interaction. Doing so allows for customized interfaces to Web-based applications, for example.

Rules are a formal expression of knowledge or preference, a guidance system for steering behavior (a transaction) in a desired direction. A business rules approach aims to deliver that knowledge, externalized and automated as an integral and active component in systems architecture. Therein lies the new difference ­ a knowledge- focused way of architecting 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.

This five-part series will cover the major concepts behind building business rules systems: important business rules concepts (Part 1), the business rules difference in methodology phases (Part 2), road maps for business rules discovery (Part 3), new insights gained from business rules analysis (Part 4) and exciting differences in business rules design (Part 5).

The Time is Now

The timing of this series is particularly important. Six significant trends in the marketplace provide the motivation for a business rules approach. These are:

1. The increasing desire for e-business applications.
2. The insatiable pressure to develop applications faster. (The Y2K challenge has created a larger application backlog than ever before.)
3. The never- ending demand to deliver applications that we can easily and quickly change to reflect changing business environments.
4. An emergence of commercially available business rules technology products.
5. A never-ending shortage of application system developers.
6. The shortcomings of other approaches and technologies (such as information engineering, object-orientation, component design, enterprise frameworks).

The Uniqueness of Business Rules Methodology

A unique aspect of a business rules system development methodology is that it divides the systems development approach into a minimum of four separate, but integrally related tracks.

In Figure 2, one track represents the workflow/process perspective which includes the user interactions and processes, but without the rules in them. A second track represents the data perspective, with minimal rules embedded in it. A third track represents the set of rules behind the interactions and over the data ­ where the rules are managed as a separate, externalized, logical component. The fourth track represents the technology for the system. Today, you can choose business rules technology that is designed specifically to manage the execution of a rules collection. Alternately, you can utilize non- business rules technology (even home-grown Java), but in a way that leverages the concepts and advantages of a business rules system.

Figure 2: How Do You Build a Business Rules System?

The Major Advantages

A business rules system can be developed fast. There are fewer necessary deliverables out of the discovery, analysis and design phases and possibly less need for coding, depending on target technology. That's because with some technology products, the integrity and computational rules of the system are captured by analysts, and then expressed by developers as declarative rules. Some business rules technology 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. However, once captured and documented, a declarative rule can be implemented in rules technology within a matter of hours. Those hours are spent determining where and how to implement a rule. Previous procedural approaches implemented a rule in various programs or methods. Rules technology allows you to implement common rules in one place or even share common clauses among rules.

A business rules system can be changed easily. A business rules developer can change one rule at a time (or many rules at a time) and have that change available to all relevant business transactions, 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. A rule in rules technology can be changed within a matter of minutes.

A business rules system can be designed around essential intellectual process flow. That is, by focusing on business rules, an analyst can distinguish the absolute dependencies in knowledge discovery (rule dependencies) from those that are interesting from a performance or user-preference perspective.

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

Why Now?

In 1988, Candace Fleming and I completed a book called, Handbook of Relational Database Design. It contains a step-by-step approach for building logical data models and transforming them into stable relational databases. The approach focuses on understanding the business rules surrounding those database designs. In 1988, the phrase "business rules" was not a buzzword. Even so, we strongly urged readers to take a methodological approach to capturing, documenting and implementing those business rules.

The good news is that readers successfully followed that step-by-step database design approach and created stable relational databases. The bad news is that those practitioners also ended up with an intriguing collection of "leftover" business rules. What to do with them? Specifically, who is responsible for implementing (and evolving) them and in what manner?

It comes as no surprise that these leftover business rules emerged as a fertile battleground over which database designers and application developers have waged territorial wars which still go on today. So, the step-by-step approach in that book, while it focused on business rules, remained unfinished and unresolved because it did not make a very formal separation between modeling the data and gathering business rules. This series, however, introduces a very clear separation by adding enough discipline to the rule aspect that it becomes a rule track.

This five-part series summarizes a more formal and complete step-by-step approach for capturing, documenting, managing, automating and changing those business rules. The series is not meant to be an in-depth tutorial covering all aspects of full systems development. Rather, the series aims to present the discriminating basics behind a business rules systems development methodology that lead to the design and implementation of true business rules systems.

What is a Business Rule?

Unfortunately, there is no industry standard definition for the phrase "business rule" or even "rule."² For this series, think of business rules as the set of conditions that govern a business event so that it occurs in a way that is acceptable to the business (or customer). The business people (or customer) state rules that define all possible and permissible conditions for the business event along with those that are not permissible or are undesirable.

It is important to keep in mind that business rules have a business flavor, regardless of how you choose to implement them. To preserve the business perspective, business rules should be written for and understood by business people (not programmers) in natural language and independent of target implementation or programming language. Business rules are meant to be challenged by business people and implemented in technology that allows for controlled, but spontaneous business change.

Different Types of Business Rules

There are different types of statements that qualify as business rules.² Unfortunately, there is no universal business rules classification scheme. You should choose a classification scheme that works for your target audience and serves your intended purposes.

This series presents a business rules classification scheme that has proven useful for a business audience, specifically for use during rule discovery. The purposes served by a business rules classification scheme for the business audience include:

1. Assist the business audience in understanding the full range of business rules that you are looking to capture from them during rule discovery efforts.
2. Guide the business audience efficiently through a useful sequence for discovering rules.
3. Enable business people to express each kind of business rule in its own kind of sentence template for better clarity.

A useful way to divide the world of business rules involves three major categories: terms, facts and rules. The terms and facts will be the foundation for a logical data model and physical database. The third classification ­ rules ­ is where the excitement lies in a business rules approach. Figure 3 further decomposes rules into five different types: mandatory constraints, guidelines, action-enablers, computations and inferences.

Figure 3: Rule Classification for a Business Audience

The World of Rules

Figure 4 provides a definition and examples for the terms, facts and five types of rules. Consider that a rule can do one of the following within the context of the business event:

• Constrain information created by the business event (mandatory constraint, guideline).
• Initiate an action outside the boundary of the target system or business event (action enabler).
• Create new information from existing information (computation, inference).

Figure 4: Definitions and Examples of Rules

As you can see, constraints can be mandatory or guidelines. A mandatory constraint is a rule that rejects the attempted business transaction. A guideline, on the other hand, does not reject the transaction; it merely warns about an undesirable circumstance. Because a guideline only warns and does not reject, it provides a freedom of choice. Guidelines are often very important to the business community. Since most business rules products do not support the management and specification of guidelines, the developer usually translates guidelines into warning messages.

Both computations and inferences create new information from existing information. It may be interesting to say that the result of computations and inferences is a piece of knowledge (not just information) because it cannot simply be known. An intellectual process is required to materialize its value.

In the computation example in Figure 4, the new piece of information (knowledge) is a new value for an attribute (total- customer-order-dollar-amount). A "rule-enriched" logical data model and perhaps the database design may reflect these new information pieces.

The result of executing an inference rule is to create a new piece of information. In database terms, this new piece of information can either be a new instance of an entity (e.g., a new instance of the preferred customer entity) or a new instance of an attribute (e.g., a new value for customer-order-discount- amount).

Again, a "rule-enriched" logical data model and perhaps the database will contain these new pieces of information. One of the future installments of this series will discuss the characteristics of a rule-enriched logical data model.

Are All Business Rules About Data?

Using the definition of business rules in this article, all business rules are about data. That is, terms define data concepts and details, facts define associations among data, constraints and guidelines test data values, computations arrive at a data value, inferences arrive at a data conclusion and action-enablers evaluate data values prior to initiating action. Therefore, all of these business rules are about data in one way or another.

You may discover other rules, such as workflow sequence rules, that are not purely about data. If so, these are rules of another kind. They are not considered "business rules" under this business rule definition and classification scheme.

A Moment in Time

At a moment in time in 1988, there were many unknowns relating to relational technology futures. Was relational technology a short-term fad or a long-term solution? Which relational products would survive? Which would evolve fastest to provide originally missing functionality? Which products would emerge as supporting large data and transaction volumes or distributed systems? What analysis and design techniques would be needed? Which ones would become common practice over the next decade?

Today we stand at the same frontier with respect to business rules methodology and technology. Is it a fad or is it a compelling necessity, driven by the pace of business trends? Which products will prove strategic? What intellectual inspirations related to the software engineering discipline are at our fingertips now? Those of us who grew up in the relational paradigm shift can only be excited about what is about to occur.

The ultimate payback of a business rules methodology is twofold. The first is a system development methodology that enables the discovery of essential intellectual process flow. The second is a system specifically designed to enable more spontaneous business change. A business rules methodology leads to the delivery of a system designed to change its rules, add new ones and retire old ones. A business rules approach puts the business back in charge of its destiny. So, rule discovery and rule change become a continuous dialog with the business community ­ a normal way of doing business, a normal way of building systems ­ and that's where the business needs to go now.

Next month, this series continues by taking a closer look at the business rules difference in methodology phases. It will address how those tracks and phases lead you to fascinating new possibilities, precisely because the methodology delivers ­ for analysis and management ­ a business rules asset. You will learn that the business rules asset may turn out to be the most important deliverable that information technology professionals can deliver back to the business.

Until next month, keep in mind that shared rules and shared data result in shared knowledge. Shared knowledge makes for a smarter learning enterprise. A smarter, learning enterprise is not only empowered to change, but is intellectually positioned to become whatever it envisions for itself.

References
1. Date, C.J. What Not How: The Business Rules Approach to Application Development. Addison-Wesley Longman Inc, 2000.
2. The Business Rules Group (http://www.businessrulesgroup.org/) is a group of professionals currently working to standardize various aspects of a business rules approach.

Acknowledgement: The material in this article is adapted from an upcoming book to be published by Wiley & Sons in 2001. Many ideas in this series and the book have been provided by Janet Wall, Art Moore, Linda Jeney Nieporent and Neville Haggerty.