We all know about systems that don't work, systems that don't do what they're supposed to do, systems that can't be changed. Business rules offer a completely new approach to systems development that may change all that.

C. J. Date has written a new book that attempts to explain why business rules are something new, different, and better. In this book, he presents and defines some basic business rules concepts and then later deals with these ideas from a relational point of view.

There are excellent sections in this book. Part I is a good general introduction to the topic of business rules. Those seeking material to present to management on why to take a business rules approach will find it here.

Budding business analysts can get a quick run down of the types of business rules from Part I. Although there is more to business rules, the Odell taxonomy that Date includes is a good start. The appropriate conclusion to Part I is the business rules mantra, Declarative not Procedural.

Today, innumerable lines of code contain most the business rules for many organizations. Date makes the point well and often that stating business rules declaratively, rather than procedurally in code, is the basic idea behind all the advantages of the business rules approach. If readers get that point only, the book will be a valuable contribution to improved system development.

The summary to Part II is good in that it briefly states the technical relational material in a short and simple way. Those who do not care to delve into the innards of relational theory could read the summary and skip the preceding Part II chapters.

Business Analysis

To the best of my judgment, almost everything Date says in this book is correct. He is a widely-published author of books and magazine articles, with a justly deserved reputation for good writing that indicates clear thinking. He is also the author of other writings in this same on-line publication. Still, I feel that some things in this book warrant discussion.

The first part of the Preface talks about business rules as an exciting new technology. Business rules are exciting, but as Part I makes clear, it is not necessary to get into any discussion of technology to reap the benefits of business rules.

In a brief discussion on why entity-relationship modeling is incapable of dealing with integrity constraints, a major type of business rules, Date points out that drawing pictures may not be the best way to do database design. A point well taken. But the role of modeling of any kind is not limited to database design.

The more difficult task is involving business people directly in the process of business analysis. A good picture, say an effective E-R diagram, with complete definitions, is a useful human communications tool.

It will be harder to implement systems that do work, systems that do what they're supposed to do, and systems that can be changed more easily, if the necessary human communications are truncated or ignored. Pictures are a good way to do this and a good place from which to start deriving business rules.

Gathering business rule statements, business ramblings. or proposed business rules, and discussing them with appropriate business people are necessary for better logical database design, applications, and systems. These are the first steps in starting the human-technology communication necessary for physical design.

Date and I differ on the definition of the scope of the topic of business rules. A good discussion of business rules and other business topics is as, or even more, important in producing good systems as the appropriate supporting technology in the form of databases, rule engines, and a good query language.

Zachman Framework

As previous readers of my writings know, I try to place almost everything I encounter into the Zachman Framework. The Framework is a useful tool for classifying any aspect of a business. The set of business rules describing a business are a model of that business, and the Framework is very useful for classifying business models.

Because What Not How covers two subjects, the "how" of business rules and also various relational and technical concepts, the book includes different kinds of material that can be put into different places in the Framework.

Date's ideas on justifying why business rules are a good solution fits into the "Why" column of the Framework, which covers motivation issues. The relational and technical material, more weighted toward implementation issues, seems to me to belong in Framework row 3 (a systems analysis view) and row 4 (a design view). Some may even touch row 5 (a systems building view).

Audience

In Part I, Date attempts to lay out an understanding of what business rules are. Proceeding systematically, he takes us through a set of eight short chapters. These include a problem statement, examples of kinds of rules, how rules are connected to a data model, and some potential advantages and disadvantages of a business rule approach.

If the intended audience is managers, then I think Date has succeeded in putting business rules into a useful general perspective. Since the book subtitle includes the phrase "Application Development," technical people still may be looking for that content as they finish page 66, the end of Part I.

Part II is just the opposite. Proceeding like a mathematician solving Fermat's Last Theorem, Date marches us through a set of eight short rigorous technical chapters. He goes through many essential relational ideas in a compact review. Date ties in business rules in Chapter 14, just before the Part II summary.

Framework rows 3, 4, and 5 people will easily zip through the relational material, since it is explained in simple and easy-to-understand terms in the text. Analysts, designers, and programmers will finally get to see why they had to read through the introductory ideas in Part I.

Row 1 and 2 people will have a tougher go of Part II. The distinctions between values and variables, relation values and relation variables, relation and relvar, and base tables and views, though important, will tend to cause managers' eyes to glaze over.

So I disagree with the comment in the Preface that "the primary target audience is still basically as for Part I."

Style

Ordinarily, an author's style should have little effect on the value of good material. Especially after I've already said that almost everything he says in this book is correct and that I agree with it. There are three separate annoying style issues that affected my reading of Date's book.

The first concerns the constant references to another book, which is in press, The Third Manifesto, by Date and Hugh Darwin. It's one thing to point out that some topics are covered in more detail in another publication. But enough references are made as to suggest that What Not How functions as a press release for the other book.

The second style issue has to do with the inclusion of so many different styles of examples. These include SQL, more than one form of pseudo-SQL, and Tutorial D. Readers who use SQL regularly may puzzle over the inexplicitness; nontechnical readers may look for hidden meaning in the changing syntax. It's good that, in a book aimed at managers, Date omitted examples of predicate logic or UML, both of which he mentions and over which even some technical people puzzle.

A last style issue derives from the fact that the book text is derived from live presentation material. That leads to a certain feeling of bouncing around, with many parenthetical comments such as, I'll tell you about that later and here's now what I said before I'd tell you later. Date does warn about this in the Preface.

What Not How has an excellent bibliography, index, and table of contents. I found only one typographical error -- not bad in this day of quick publishing turnaround. Page 103, second paragraph should conclude, "...it's a 'true fact' that part P3 contains 9 of P5, and so on." (Not P2.) Be sure not to miss the humorous, and thoughtful, statements about rules on the dedication page.