Author: C.J.Date
Publisher: Addison-Wesley (ISBN 0201708507)
What Not How: The Business Rules Approach to Application Development is a very interesting book, but so brief as to leave you wanting more. It is divided into two parts. Part one is called
“Business Rules Overview.” Part two is called “A Relational Perspective.” The flow of the book is choppy and redundant in places, as it was pulled together from lecture
notes on business rules and relational theory.
Part I
The first part of the book is a business rules overview. The first chapter states: “What’s the Problem?” Date says that low level, procedure coding has progressed until
today’s use of high level objects and declarative programming has raised the level of abstraction to make programming more productive. The handling of details that distract from solving the
business problem leads to reduced productivity.
Then Date decrees that “Business Rules are the Solution!” Business rule capture and codification allow for automation of business logic without step-by-step procedural coding. There are
three areas within computer applications where business rules apply: Presentation, Database, and Application.
Presentation rules are useful to define how users interact with a computer application. This includes control of colors, application flow, edits, and so on. A business rule might state that a
supplier name should turn red when a credit limit is reached, for example. Database and application rules control the state of objects when events occur that change their state. This is where Date
references a good taxonomy of rules, from James Odell. Date describes the types of rules and how business rules are classified into Constraints and Derivations. This section is very brief, and I
wish there had been more information in it. I assume that Date feels we can find more information in the references on these topics.
The next chapter defines what Date means by The Data Model. He then goes on to state that if all business information is defined in a database, then it makes sense to implement business rules as an
engine that is either part of the DBMS or on top of it, to control logical transitions between entity states. He then states that this results in a declarative model of the business, which
eliminates a tremendous amount of procedural coding and leads to improved impact analysis. Thus, productivity is enhanced, as well as quality in our systems. The chart on page 52 captures the
potential for automation at a glance, showing all steps in systems development that can be automated. Disadvantages include difficulty in implementing rules based logic in systems development tools
and compilers, so that performance is acceptable and programmers can easily define systems logic.
Part II
Part II of the book is relational perspective on all that has gone before. If relational database implementation is assumed for business modeling and running the enterprise, then it makes sense to
implement the rules as well at that level to properly maintain integrity and reap benefits of declarative programming.
The next five chapters bring anyone up to speed on the basics of relational theory. As a database professional, I found them interesting. Even though I work with databases all the time, the
overview was thought provoking and interesting. If someone was new to the subject, it would be difficult material, but not impossible. The simple concept that the relational world is based on a set
of logical propositions, that domains are sets of thing we can talk about, and relations are true statements about those things, (page 102), I think anyone can grasp. Thus it makes a strong
argument to capture business rules closely bound to the database, to preserve integrity of the enterprise.
The final chapter claims that business rules should be made part of the data model, in both its implementation as part of the database and as part of the methodology we use for modeling. Date makes
the point that ERD’s do not capture integrity constraints beyond those of foreign key constraints. He also references a notation called ConQuer and the UML notation and quotes those who state
that these pictorial methodologies must be reinforced with textual integrity constraint definitions.
Overall, I believe the book is a good introduction to the topic of business rules. As a database professional, I like his bias towards implementing declarative rules close to or within the DBMS,
although others may not. As just an overview, I feel that perhaps it does not go into enough depth on business rule types and taxonomies, nor does it grapple much with the daunting issues of
implementing automated declarative systems. However, this is a good book to read when starting to learn more about business rules, and it did the job for me.