Book Excerpt: WHAT Not HOW: The Business Rules Approach to Application Development

Architects build buildings from specifications, so can IT management do the same? A new way of building applications, known as business rules processing, offers the prospect that IT might be able to do just that.

In this article I want to show what business rules might look like in practice and highlight some of the advantages of this new way of doing things. The information presented here is based on material in my book, WHAT Not HOW: The Business Rules Approach to Application Development, published this year by Addison Wesley Longman Inc.

We need to start with an explanation of business rules and their possibilities. An interview with Val Huber of Versata Inc. (in Data Base Newsletter 25, No. 2, March/April 1997) spells out very clearly what business rules are about and what their potential is.

Huber says: "Years of experience with information system development have taught us two important lessons--it takes far too long to turn a relatively simple set of requirements into a system that meets user needs, and the cost of converting existing applications to new technologies is prohibitive.

He goes on to say, The factor underlying both of these problems is the amount of code it takes to build a system. If code is the problem, the only possible answer is to eliminate the coding by building systems directly from their specifications. That's what [business rules do]."

A Sample Database and Application

Consider a simple customers and orders database (click View the Image below, and see figure 1: The Customers and Orders Database).

Just to be definite in our example shown in figure 1, assume the database is an SQL database specifically and the boxes represent SQL tables. The arrows in the figure represent foreign key relationships; for example, there's a foreign key from the ORDER table to the CUSTOMER table, corresponding to the fact that every individual order must be placed by a customer.

Those foreign key relationships can be thought of, in part, as existence dependencies; an order can't exist unless the corresponding customer exists. And those existence dependencies are business rules. Foreign keys correspond to an important special case of business rules in general.

The database definition in figure 2 gives some self-explanatory SQL definitions for this database (click View the Image above, and see figure 2: Database Definition).

Now let's consider a typical business function on this database--"insert line item." At run time, the end user asks for a form corresponding to the LINE_ITEM table to be displayed on the screen. That form will include fields for the customer number, the order number, the part number, and the quantity ordered. The end user fills in those fields appropriately and clicks "enter." The "insert line item" application is then invoked and does the following:

A. It checks the customer's credit limit.
B. It computes the order total.
C. It determines whether the part needs to be reordered.

Here, A, B, and C are business requirements that must be met in order to carry out the overall business function. Incidentally, there's an important point here that I'll come back to in a moment: Those very same requirements might also need to be met as part of certain other functions (for example, "delete line item.") But let's concentrate on "insert line item" for now.

For each of these requirements, then, the application developer will specify a corresponding set of business rules. In the case of "check credit limit," those rules might look like this:

1. If TOTAL_OWED > CREDIT_LIMIT, reject

This rule, obviously enough, means the new line item must be rejected if it pushes the total owed by this customer over the customer's credit limit. But what does "total owed" mean? Clearly, we need another rule:

2. TOTAL_OWED = Sum (ORDER_TOTAL where not PAID)

Note that there isn't any "total owed" column in the CUSTOMER table shown in figure 1, so the total does need to be computed as indicated.

Observe now that this second rule refers to the order total. So it leads us directly into the second requirement, "compute order total," for which the rules might look like this:

3. ORDER_TOTAL = Sum (LINE_ITEM_AMOUNT)
4. LINE_ITEM_AMOUNT = QTY_ORD * ORD_PRICE

QTY_ORD and ORD_PRICE are both specified as part of the line item, so LINE_ITEM_AMOUNT can be computed directly.

Here's the rule for the third requirement: "determine whether reorder is required":

5. If QTY_ON_HAND - QTY_ORD < REORDER_LEVEL, reorder

"Reorder" here can be thought of as the name of another application, part of the same overall integrated application system.

Alternatively, and this is a very important point, "reorder" might mean "send an e-mail message to some external agency." So we're not just talking about calling subroutines. And we're not just talking about applications in the classical sense.

Business Rules Advantages

As you can see, the rules in our example are fairly declarative (nonprocedural) in nature. But they can be compiled into procedural code; in other words, they're executable, loosely speaking. So we've specified our application in a purely declarative way. We haven't explicitly written any of the usual procedural code at all, and yet we've still wound up with running code--an application that can be executed on the machine.