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” 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.

Here are some of the advantages that accrue from this way of doing things:

Productivity.The declarative rules replace many pages of hand-written procedural code. Each rule could easily correspond to a couple of hundred lines of 3GL code.

The rules are “fired” (to use the jargon) on all relevant updates.I touched on this point before, when I said that the very same business requirements might need to be met as part of several different business functions.

In our example, although the rules were specified as part of the process of building the application “insert line item,” they’re relevant to other applications, too. For example, the application “delete line item” should also clearly cause the rule “compute order total” to fire, and so it does.

To make the point more simply: The application developer doesn’t specify when the rules are to fire or what events have to occur in order to trigger them. (We don’t want to have to specify those triggering events, for all kinds of reasons. One obvious and important one is that we might get them wrong.) Instead, we simply say what the rules are, and the system figures out when they should fire.

It follows that there’s no need for the application developer to get into the business of writing that complicated “on event” hand code that’s required with certain 4GLs.Note: Actually, this point is slightly overstated; sometimes we do have to define rules that look a little “event-driven.” Rule 5, the reorder rule, is a case in point (though it can hardly be described as “complicated hand code”).

It also follows that rules are automatically shared across applications and reused across applications.It’s rather like the situation with the database itself: The data in the database is also shared and reused across applications, as we all know. And the advantages of such sharing and reuse for rules are analogous to those for sharing and reuse for the data itself. In effect, just as the relational model originally allowed us to integrate, share, and reuse data, so business rule technology allows us to integrate, share, and reuse applications.

Another advantage is what might be called the “single-level store” advantage.To be specific, the rules make no mention of any kind of artificial boundary between the database and main memory; data is data, wherever it resides, and there’s no need to move data out of the database and into main memory in order to process it. (No need to, that is, as far as the user is concerned. Of course, the data does have to be moved under the covers. But why should the user care? Let the system do it.)

Finally, note that the rules can be stated in any sequence.To say it another way, we have ordering independence for the rules. Business rule technology allows us to get away from the tyranny of the von Neumann architecture, which forced us to think everything out in a highly procedural manner, one step at a time.

As Gary Morgenthaler, a founder of Ingres Corp. and now a general partner of Morgenthaler Ventures, has said (in a private communication): “[With the business rules approach,] programmersare freed from the burdensome task of having to redefine their business problems in the deadening pursuit of stepwise instructions for the program counter.”

Down with the Program Counter!

Of course, the procedural code that’s compiled from the rules does have to pay attention to the program counter (the rules have to fire in some well-defined sequence). So how does the system figure out that sequence? Basically, it does so by means of what’s called a dependency graph. In our example:

1. In order to check the credit limit, the system needs to know the total owed;

2. In order to compute the total owed, it needs to know the line item amounts; and

3. In order to compute the line item amounts, it needs to know the line item quantity and price. But it does–these values are given by columns in the LINE_ITEM table (or are provided by the end user, in the case of a line item that’s currently being inserted).

So the dependency graph shows that 1 depends on 2 and 2 depends on 3. So, obviously enough, the system fires the rules in the sequence 3, then 2, then 1.

By the way, note the reliance in the foregoing on the foreign key constraints (which are rules, too, of course, as we already know). For example, the rule

TOTAL_OWED = Sum (ORDER_TOTAL where not PAID)

implicitly makes use of the foreign key from ORDER to CUSTOMER (the order totals to be summed for a given customer are precisely those for orders that have a foreign key relationship to the customer in question). //

C. J. Date is an independent author, lecturer, researcher, and consultant, specializing in relational database technology, a field he helped pioneer.

This article is based, with permission, on material from his book WHAT Not HOW: The Business Rules Approach to Application Development (Copyright (C) 2000 Addison Wesley Longman, Inc.). All rights reserved.
It can be purchased at DigitalGuru.com for $19.71.