Why Decision Tables are not enough: From Decision Tables to Decision Models

(This article assumes knowledge of the Decision Model. If you are not already familiar with the theory of the Decision Model, you can download a brief primer from www.TheDecisionModel.com.)

Portions of this article are drawn from the book, The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis, LLC. This article consists, in part, of abstracts from the book; directly quoted passages, diagrams, and tables are cited, and are copyright © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.

Decision tables have long been a successful technique for representing structured logic. Being visual, they circumvent the need for unnatural formal language or grammar. We use them not only to communicate that logic, but also to automate it. They are especially useful for validating the logic’s completeness and consistency.

The Next Generation
Yet, this article advocates that this is not enough. The single, unconnected decision tables should evolve into whole models behind business decisions. The transition from decision tables to Decision Models is a fundamental leap in maturity that is beginning to take hold. This leap has fascinating implications for the business and an imminent new kind of software.

The inherent structure in business logic is similar to the structure Dr. Codd detected in data almost 40 years ago. This is very exciting and is the reason this article compares this hidden inherent structure to today’s decision tables.

The Transformation
This article starts with a typical decision table and applies rigorous principles not available before. The transformation leads to a Decision Model.

In practice, we do not create Decision Models from decision tables. Instead, we create top-down skeletal Decision Models and populate them directly from business policies or business people (Ditch Your Business Rules? Five Reasons Why and How). However, the transformation steps below reveal some important differences, one at a time, between a decision table and the foundation of the Decision Model.

Getting Started
Let us start with a simple decision table.

A common definition of a decision table is “a table of all contingencies and actions to be taken for each” (Wordwebonline “Decision Table”). See Figure 1 as an example.

Figure 1: Typical Decision Table

This decision table has four conditions listed under the column heading of Conditions. The conditions are Candidate Initial Interview Rating, Candidate Compensation Expectation, Candidate Personality Rating, and Candidate Cognitive Rating. This decision table also has three actions listed under the heading Actions. The actions are Candidate Ranking, Candidate Culture Fit, and Make Job Offer to Candidate. This decision table also has five sets of business logic or rules, numbered 1 through 5 across the top row. For example, we interpret #2 as:

If the Candidate Initial Interview Rating < 3 and the Candidate Compensation Expectation is aligned and the Candidate Personality Rating is good and the Candidate Cognitive Rating is excellent then the Candidate Ranking is 1, the Candidate Culture fit is Yes, and Make a Job Offer to Candidate is Yes.

Principle #1 of the Decision Model specifies that the fundamental structure of Decision Model, the Rule Family, is a two-dimensional one, with heading and body. A decision table is such a structure, so it serves as this article’s starting point.

Transformation Step 1: Turn it Sideways

Sideways means represent the condition and actions as headings across the columns rather than as entries down the first column. See Figure 2.

Figure 2: Conditions and Actions as Headings across Columns

Why Step 1 is Important:
Step 1 is not that important. However, most Decision Modelers prefer the sideways presentation. It is similar to the structure of look-up tables and relational tables. In addition, Decision Model normalization reduces most Rule Families to fewer headings than entries, so sideways is more practical (but not necessary).

Transform Step 2: Convert Headings to Valid Fact Types
A Rule Family consists only of conditions to test and conclusions to decide. A conclusion is not an action. It is an intellectual product derived from the conditions. Therefore, Principle #2 states that a Rule Family heading is a set of fact types, representing different kinds of information.

Therefore, we change the Action heading to Conclusion and make sure each heading has a proper fact type name, supported with definitions, and domains. Sample glossary entries are in Figure 3.

Figure 3: Fact Type Glossary Entry

The glossary will contain fact types whose values come from persistent storage (persistent fact types) as well as those whose values are conclusions (interim fact types). In Figure 3, Candidate Ranking does not represent persistent data because it is a conclusion value, not one from a database, file, or a human. In addition, we transform the conclusion “Make Job Offer to Candidate” from an action into a fact type, so it becomes Candidate Job Offer Eligibility.

Why Step 2 is Important:
Fact-based headings serve three purposes: (1) ensuring that everyone understands the logic through supporting definitions (2) providing input to I/T regarding data and object models and (3) validating that the logic covers complete fact type domains.

Transformation Step 3: Separate Each Conclusion Fact Type

Principle #5 requires that a Rule Family have only one conclusion fact type.

To accomplish this, we decompose a table with more than one conclusion column into multiple tables, specifically one for each conclusion column. The table in Figure 2 decomposes into three tables in Figure 4.

Figure 4: Only One Conclusion Column

Why Step 3 is Important:
Step 3 addresses simplicity by ensuring that there is only one way to represent, interpret, and change business logic. With only one structure for a conclusion fact type, a change in its logic takes place only there. It also encourages re-thinking about whether the original conclusion fact types should have the same conditions. Normalization will also challenge what appears to be similar logic.

Transformation Step 4: Create a Diagram Showing only Structure
This step addresses the bigger perspective of logic. It produces a diagram representing only the structure of that logic (i.e., its condition and conclusion fact types) without the details.

Figure 5 contains an icon for the top structure in Figure 4. The conclusion fact type appears at the top above the solid line. Condition fact types appear below the solid line.

Figure 5: Rule Family Icon (Only Structure, Not Details)

Why Step 4 is Important:
It is all too easy, but not always necessary, to get lost in the details. Step 4 creates a structural representation based on best guess, before investing in details. This is an early deliverable, which, while incomplete, is useful. I/T can align fact types with data sources, build object models, and create prototypes.

Transformation Step 5: Connect Together Related Rule Families
This is where the magic happens. The magic does not happen with single decision tables.

Suppose the business states that it wants to specify logic insuring the hiring of people with the appropriate personality. Therefore, they decide that a candidate’s personality rating is determined by testing Candidate Maturity Rating and Integrity Rating. Figure 6 shows a possible Rule Family structure for this.

Figure 6: Rule Family for Candidate Personality Rating

Notice that the conclusion fact type in Figure 6 is a condition fact type in Figure 5 . This forms an inferential relationship, represented with a graphic connection as show in Figure 7.

Figure 7: Inferential Relationship

Why Step 5 is Important:
Without additional effort, Step 5 merely materializes an entire and orderly web of business logic as a cohesive model. There is no guessing. Business people can read and analyze it. The model elevates business rules and business logic to a deliverable that is larger, hides complexity, and attracts higher management attention.

Transformation Step 6: Confirm the Remaining Principles of the Decision Model
The 15 principles of the Decision Model define its full rigor. These principles address the declarative nature of the model. They also address first, second, and third normal forms.

A sample Decision Model is in Figure 8 ¹. A condition fact type in one Rule Family that has a supporting Rule Family appears below the solid line, above the dotted line. Condition fact types below the dotted line are those whose values come from persistent data stores or data entry.

Figure 8: Completed Decision Model

Why Step 6 is Important
The principles result in a deliverable that is more valuable than its pieces. The resulting model is:

• Comprised of the most atomic pieces of business logic (no Ors, no ELSEs, no OTHERWISE, one conclusion fact type)

• Based on disciplined fact types

• Normalized to minimize redundancies

• Predictable in structure and

• Aligned with business performance and directions.

Summary
Single decision tables are just the tip of the iceberg in capturing and managing business logic. Like the Relational Model, the Decision Model has the potential to change completely the way to capture, think about, and leverage business logic. For starters, think of a complete change in impact analysis! You can easily see structural changes, detailed changes, and how they influence other related Rule Families. Impact analysis becomes much more comprehensive than with decision tables.

Moreover, with a disciplined model rather than individual decision tables, innovative advances become possible. One is the notion of Decision Model views, customized for regions, customers, or compliance (Evolving the Decision Model with Views). Another advance is the emergence of a new generation of software (A BRMS is not a DBMS: Ten Ways in which Dealing Business Rule Vendors can be Frustrating for Business Analysts). Yet another is the potential of applying normalization to business logic. None of these advances is possible with single decision tables. Moreover, when business leaders view their decision-making logic in a tangible, rigorous model, it becomes a target for improved business thinking. This has a profound effect on organizational maturity and actual business performance. And it is easier than you think.

Authors: Barbara von Halle and Larry Goldberg of Knowledge Partners International, LLC (KPI)

Larry Goldberg is Managing Partner of Knowledge Partners International, LLC (KPI), has over thirty years of experience in building technology based companies on three continents, and in which the focus was rules-based technologies and applications. Commercial applications in which he played a primary architectural role include such diverse domains as healthcare, supply chain, and property & casualty insurance.

Barbara von Halle is Managing Partner of Knowledge Partners International, LLC (KPI). She is co-inventor of the Decision Model and co-author of The Decision Model: A Business Logic Framework Linking Business and Technology published by Auerbach Publications/Taylor and Francis LLC 2009.
Larry and Barb can be found at www.TheDecisionModel.com

¹ The figure does not include Rule Families for Candidate Culture Fit and Candidate Job Offer Eligibility. Interested readers can add these as an exercise.

NOTE: Top image © Tom Mc Nemar - Fotolia.com