Business rules have been around since ancient times. Sumarian cuneiform tablets and Egyptian wall paintings show examples of business transacted according to well-understood rules. The Biblical law of an eye for an eye and a tooth for a tooth, while a bit severe for modern thinking, is a statement of a kind of business rule.

Discovering and documenting business rules has emerged as an important new discipline over the last few years. Before this emergence, business rules were found scattered through many parts of the system development life cycle, especially in computer program code. With an emphasis on the system instead of the business, the rules tended to look more like code or database procedures than things business people cared about.

Practical

David A. Ruble’s book states how important business rules are even though they may be discovered and documented in different parts of the system development life cycle. His book has several related ideas, many mentioned in the long title, that are worth looking into. He discusses planning, analysis, and design of systems. In addition Ruble covers in detail the concepts behind client/server and GUI (graphical user interfaces.)

Many books contain the word practical in their title. Some turn out to be practical but many actually aren’t. This book is definitely a practical book on system development. It contains useful and detailed charts, tables, drawings, and examples, and a complete case study in an appendix.

Each technique covered in the book is presented in detail. Types of appropriate automated tools are mentioned to assist in doing the work. Ruble also suggests some simple, low-tech and low-cost methods that he has found effective.

In a business where there is precious little that is funny, Ruble fills his book with humor. He includes many cartoons, drawn by himself. Even the inside and outside front and back book covers are decorated with cartoons, patterns, and icons in a mock Egyptian hieroglyphic format. I continued reading the book past the part that I was most interested in because I didn’t want to miss any jokes. A technical book I couldn’t put down? Now that’s practical.

Planning

In the book’s introductory Chapter 1, Ruble defines the difference between analysis and design. He covers the roles and skills of analyst and designer. He also lays out the need and criteria for a good methodology as an essential part of good project management. Readers who find themselves in a position of justifying the use of a methodology will find applicable material, stated succinctly. There is no question that less than adequate project management leads to failed projects.

Chapter 2 lays out the need for a good project charter, which is in essence a plan. While he doesn’t explicitly refer to business rules here, Ruble intends the charter to be a contract among all the project participants, detailing why the project is to be done and what things should look like at the completion of the project.

The statements written down in the project charter are the first business rules the project may encounter. While not the kind of business rules that can be easily translated into computer code, they nevertheless are the rules by which the project will operate. Also, the statements about the parts of the charter documentation required by the business are business rules. A rule can be changed if it needs to be, but at any one time, everyone can agree on what the current project rules are by looking in the charter.

Analysis

The analysis section of the book, Chapters 3 through 7, includes detailed explanations of techniques for producing context models, event models, and information models. It is here that Ruble starts mentioning business rules by name. A formal definition of business rule is in the book’s 11-page glossary. To paraphrase that definition, a business rule is a constraint placed on an information system due to business policy.

There are no references to the terms business rule or rule in the otherwise adequate index, although these terms occur about nine times throughout the text. Different concepts are called rules or business rules. Perhaps the book was written before business rule was a more well defined idea, and the omissions mentioned should be viewed in that context.

The first mention of business rule is in the chapter on event modeling. Ruble carefully explains the necessity for the analyst to ask many questions about significant business events. Event is defined in relation to the system of interest. The event model provides a place to record the answers, in the form of procedural business rules. While these procedural statements wouldn’t be formally labeled as business rules according to the Business Rules Group taxonomy, the event model would be a rich source from which to mine them.

Information Model

The second mention is in the chapter on the information model. Included here are definitions of entities, attributes, relationships, and entity value state transitions. The reference to business rules involves the state transitions. The rules for these transitions are definitely business rules. They state the constraints under which an entity value could change from one state to another.

Omitted is any mention that entity definitions, or terms, and relationships, or facts, are kinds of business rules in information models. In addition, relationships can have cardinalities and optionalities, which are also constraint business rules. Even if these types of business rules in an information model are not identified as such, this kind of model is another valuable source of them.

During the process of business analysis, the analyst will probably encounter many questions and answers that apparently conflict with existing business policy or for which there is none. Ruble insists that these must not be ignored. Rather, they must be dealt with appropriately. Both he and I agree that, whatever their outcome, these questions and answers, and the policies that are touched by them, may be the most significant source of business rules an analyst encounters.

Up to this point, the book has been describing work in the first three rows of the Zachman Framework. Once done with Chapter 7, which wraps up analysis, the book leaves the world of finding and documenting business rules.

Design

The rest of the references to business rules occur in chapters on architecture modeling, which deals with client/server concepts, and design, which covers database design, graphical user interface (GUI) ideas, external interface design, and internal component design. These references discuss where to put business rules in the technical architecture, not what the content of them is. This is definitely Zachman Framework row 4 territory.

The ideas and suggestions in these technical chapters should be taken to heart by organizations that have an on-line presence. While not stating exactly what the rules should say, Ruble emphasizes that such an organization needs to have many business rules concerning how screens should look, what information they should contain, and how all the behind-the-scenes work should take place. We used to call these standards, but they are really in-house business rules for developing systems. There is no reason why these kinds of rules shouldn’t be automated like the ones that operate the business and carry out the organization’s intent.

Systems

Since this is a book on systems development, it emphasizes systems. Unfortunately, many legacy systems are currently being built. But if the practices described in this book are followed, then good logical models will be created that include many of the business rules a business wants to track. These models present a valuable opportunity for a business rules analyst to gather, reconcile, and generalize the rules in a place where they can be managed by the business.

No mention is made about a business rules engine as a possible place for business rules. Again, that’s reasonable considering when the book was written and that it was written from a systems, and not an enterprise, view. Perhaps the business will be fortunate enough to add a business rules engine to its physical architecture. It is only when business rules are managed and viewed from an enterprise perspective that their economic value will be appreciated.

This book has a handful of missing words, spelling errors, and punctuation inconsistencies that don’t seem to change the meaning. Ruble’s jokes and hyperbole occasionally result in a hard to follow sentence. Each chapter ends with some exercises and answers, in text book style. The examples, exercises, answers, and case study are filled with funny material. Why didn’t I have texts and teachers like this when I went to school?