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.