Business rules presentations at seminars, and even entire seminars about business rules, are becoming common.  They tantalize attendees with visions of business rule engines, provide ammunition on the value of business rules to organizations, and even show a few bullet-pointed how-to steps.  But how to do it all -- to do it really completely -- is frequently left to an attendee's imagination as something of a dark art.

Business Rules Applied is a comprehensive, extremely detailed explanation of just how to go about the entire process of implementing business rules.  It covers all parts of a system development life cycle, explaining specifically how a business rules approach alters every step in the cycle.  The book has a great deal in it, and every part of the book has something useful.

A technique von Halle carries over from her previous books is the use of lists.  Sometimes the lists are steps ordered to show a logical flow.  Others are compilations of all the useful things a user might need to know about a particular topic.  When you are performing activities involving one of these topics, you can use the list to see if anything is missing or to see if you are doing something that actually belongs somewhere else.  The lists appear to be derived from extensive experience.  If you use nothing else but the lists, it would be worth having the book.

An excellent case study runs throughout the book, showing in text, figures, and diagrams how an organization implements business rules using a business rules approach.  The case study examples show exactly what a deliverable from an activity looks like.  Previous readers who liked von Halle's articles involving kindergarten tee-ball players will enjoy the same subtle humor in the case study topic contents, a web-based after-school service for children.

Business Rules Applied seems to be several books in one.  It is a book about many things you need to know about business rules.  It also contains a system development methodology.  If you knew very little about such a methodology, you could develop a system having nothing to do with business rules by using this book as a guide.

A third topic in the book is data.  Recapitulating much about data from other books and articles, von Halle includes enough about data to do adequate database design.  Another topic is process.  There is enough about process analysis and design to reengineer, or create from new, a process flow for an organization.  There is also content about project planning and facilitated sessions.

The book has five parts plus a 46-page section in the front consisting of a foreword, preface, acknowledgements, and a section about the authors, followed by the table of contents.  The first of the five parts is on business rule basics.  The next section is on getting started, with chapters on scoping and project planning.  The final three parts are devoted to discovery, analysis, and design.

Systems Design & Development

This is essentially a technical book addressed to system builders.  There is no question of what this book is about -- development of systems using a business rules approach.  The title says it.  The first four lines in the preface mention 'systems' four times.  The first chapter has multiple lists explaining advantages to building systems using a business rules approach, benefits to business, and benefits to software engineers.  Even five out of the six listed points for benefits to business (p. 12) are about systems.  This places a lot of the book's content in rows 4, 5, and 6 of the Zachman Framework.

Quite a bit of explanatory narrative that is nicely non-technical is sprinkled around the technical material.  However, if you think of yourself as more of a business person than a technical one, you might start at the preface and pretty much be done with your part by the end of page 17.  From that point on, starting with what appear to be vendor-supplied comments on their products, it gets harder to see a business point of view.

Part four on analysis (chapters 9 through 11) seems to be the heart of the book.  You could read just those chapters and get a perfectly good picture of what business rules are and why they are so important to systems development.  Chapter 10 is the best part of the book.  Chapters 9, 10, and 11 contain some Zachman row 3 ideas, along with quite a bit of row 4 technical material.

Selling Rules

There is a lot of material useful for selling a business rules approach scattered around the book.  Extract these parts and you will have a pamphlet-sized declaration that might help a manager to understand why this is all so important.

Preface page xxxvi makes the assertion that business rules are an asset, just like data.  On pages 3-4 the importance of business rules is defined, along with a good definition of the business rules approach.  Page 16 points out the similarity to relational database technology.  Chapter 2 (pages 27-28 and 33-37) has good definitions of business rule and rule types.  Page 94 has good material on discovery of data.  Page 102 has material on good naming practices.  Project management is covered well on pages 142-144.

That good rules depend on good business decisions is covered on pages 161-162.  The summary of chapter 6 on pages 170-171 sums up well the discovery phase.  A piece on rule authentication on pages 194-195 explains the why and what of jurisdiction and consensus.  Page 219 notes that surprises and disconnects are inevitable.  Page 223 covers why facilitated sessions produce better quality rules.  Page 295 has more comparing the data and rule assets.  The introduction to process analysis on pages 345-347 contains some of the clearest writing in the book.

A diagram on page 377 shows how rule, data, and analysis tasks relate.  This helps present the big picture of how the same system can be shown in different aspects.  A "most common business rules design solution" (in list form on pages 402-402) tells you where you are going with all this.  A guideline about approval and commitment is very significant for managers to see.  

Some good, ready-to-use definitions appear in several chapters.  And finally, good tables, diagrams, and lists are found all through the book, though more technical in content.

Questions

A reader may wonder at some of the assertions in this book.  There are many, mostly useful and correct.  But some are questionable.

On page xxxiv the authors seem to say Ronald Ross and Chris Date say business rules equal constraints.  Those authors can speak for themselves, but that equality is not always the case.  On page 10 is a variation of this, saying that the theoretical base for business rules is data integrity.  Page 17 seems to imply that rules technology = rules = data rules.  All rules are about data, says page 37.  But data integrity is only part of business rules, not all of it.

Chapter 4, on scope, says an automation decision is part of scope.  The project charter lists all project deliverables.  "Install and customize all technology" is shown as part of the design phase (p. 142).  A statement on physical keys and another on propagating keys are part of the analysis chapter (p. 275).  These all seem too much too soon, sort of a phase creep ... too much physical in the logical parts.

The most surprising statements (on pages 415-426 and again on 474) say If/Then clauses are declarative rules statements.  In most usages, an If/Then statement is usually considered to be a conditional statement, not a declarative one.  A statement that "if a polygon has three sides, then it is a triangle" may be just as true as a statement that says "every triangle must have three sides."  But the form of the first statement is conditional; the second, declarative.

Odd Things

A book with one author and three additional contributors may a have a certain amount of inconsistency.  It is the job of an editor to smooth these things out.  It is also the job of an editor to correct, or at least point out to the authors, misspellings, poor syntax, missing words or letters, extra words, subject-verb number disagreements, table and figure misnumberings, poor diagrams, generally awkward or garbled syntax, and other like errors ... things surely not intended by the authors.

Unfortunately it appears that the text was not edited -- not proof read, copy edited, technically edited, or style edited.  There are four editors listed on what would be page ii, if it had a number.  They did not do their jobs.  The authors should also have been more careful.  Some of the many errors are listed below.

People's names are spelled wrong.  On page xliii it should be Ken Molay (he is the son and nephew of men who were in Boy Scouts with me, as boys, at the dawn of time).  Mike Watson is really Mark Watson (p. 154 and index p. 546).  Most know Patricia Seybold is not Patricia Seymour (index, p. 539).

There is frequent use of 'this,' 'that,' 'the,' and 'it' with no antecedents.  There is mangled syntax several times, trying to avoid ending a sentence with a preposition.  A sentence in the explanatory paragraph under Guideline 15.11.4 (p. 510) is so garbled it is hard to tell what the sentence means.  Extra prepositions are here and there.  There is noting in text that there are a certain number of steps or items to follow, only to find one more or less in the table or list.  All these should have been found in editing.

There are mistakes, omissions, and wrong numbers in tables and figures.  Fig. 3.1 has sequential arrows, but tracks are not sequential.  The second and third lines in Table 4.17 are duplicates.  Fig. 4.5 has unlabeled lines -- what are they?  Fig. 6.1 says 'workflow,' but the matching text uses 'process.'  Text p. 150 says first two steps, but Fig. 6.2 has them as steps 6.1 and 6.3 with an intervening step 6.2.  Each of the following has either missing letters, misspellings, incorrect grammar, wrong content, or inconsistent notation:  Table 6.3, Table 7.1, Fig. 9.14, Fig. 9.7, Table 10.16, Guideline 10.2.6, Fig. 10.12, Table 11.1, Fig. 11.12, Table 12.2, Table 15.3, Table 15.6.

Typos abound.  Here are a few at random:  page xxxviii, 'one-one-one'; p. 6, 'T-ball' (or is it 'tee-ball'?, p. v); p. 101, extra 'to'; p. 161, 'use case' and 'use-case'; p. 167, extra 'usage'; p. 211, " a data of birth is be in the past"; p. 232, missing 'the'; p. 311, 'discover' not 'discovery'; p. 395, 'adapt' not 'adopt'; p. 468, "Date has past" should be 'passed'; p. 498, a missing 'are.'  There are several 'meta data' and 'meta-data' inconsistencies.  There are more.

A reference to the Zachman Framework refers to the 'motivation row' (p. 509).  There is no such thing.  It is the 'motivation column.'

Some Peeves

The table of contents, at 23 pages, is too long.  Titled entries are included down to the guideline level, of which there seem to be more than any other kind of entry.  Guidelines should have been left out of the table of contents or put in an appendix.  For example, Guideline 6.3.7 results in a 4-line long table of contents entry; Guideline 6.4.1, five lines.  This level of detail makes it harder, not easier, to find things.

The material copied from Versata, Usoft, and ILOG -- especially that in the design section (Part Five) -- is filled with references to other material not in the book.  Many examples for this section are on a web site, unavailable while carrying the book around to read.  Chapters 13 and 14 could have been condensed down to about five pages with all the vendor material left out.  The type font appears too small and the book is too long.  (So is this review.)

No glossary of terms is included and definitions are scattered through the text.  There are no definitions for the terms:  'business event, base fact, logical rule model, data activities, extraprise, intraprise, proactive -- terms not in dictionaries of everyday English.  The same is true for DDL, SQL-like, ANSI SQL, JDBC, JSP, COM objects, and XML schemas.  These are defined only by fully spelled out names in the index but not listed by acronym ... also, BtoB, EJB, JORS, VCI.  'XML' is in the index under "extensible modeling language" (under the letter 'E') -- no way to find it unless you already know what it is.  Why have any of these in the index?  They belong in a glossary of terms.

The words 'only,' 'merely,' and 'simply' are used several times in the book (pp. xxxv, 53, 157, 308, 338).  It's hard to tell if this usage is just writers' noise words or truly thinking any of this could possibly be easy.  The funniest one is on page 401 where both 'implementation' and 'simply' appear in the same sentence -- a perfect example of an oxymoron.

This is a book of great importance, despite the criticisms of form.  If you can wade through all the distractions, you will find it worthwhile.

# # #