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