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

Featured
17159 Views
7 Comments
5 Likes

(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.

Decision ModelThe 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.

Conditions

1

2

3

4

6

1. Candidate Initial Interview Rating

= 5

<3

 

<3

<=3

2. Candidate Compensation Expectation

 

aligned

excessive

aligned

 

3. Candidate Personality Rating

excellent

good

good

excellent

 

4. Candidate Cognitive Rating

excellent

excellent

excellent

average

 

Actions

 

 

 

 

 

1. Candidate Ranking

1

1

3

4

5

2. Candidate Culture Fit

Yes

Yes

Yes

No

no

3. Make Job Offer to Candidate

Yes

Yes

Maybe

No

no

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.

Conditions

Actions

Candidate Initial Interview Rating

Candidate Compensation Expectation

Candidate Personality Rating

Candidate Cognitive Rating

Candidate Ranking

Candidate Culture Fit

Make Job Offer to Candidate

=

5

 

 

Is

Excellent

Is

Excellent

Is

1

Is

Yes

Is

Yes

>

3

Is

Aligned

Is

Good

Is

Excellent

Is

1

Is

Yes

Is

Yes

 

 

Is

Excessive

Is

Good

Is

Excellent

Is

3

Is

Yes

Is

Yes

>

3

Is

Aligned

Is

Excellent

Is

Average

Is

4

Is

No

Is

No

<=

3

 

 

 

 

 

 

 

5

Is

No

Is

No

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.

Fact Type Name

Fact Type Definition

Fact Type Domain Values

Candidate Ranking

A value indicating where a job applicant fits compared to other candidates. Candidates who earn the same ranking are likely to offer similar qualifications. Candidates with lower numerical rankings are desirable to the company.

1-5

Candidate Job Offer Eligibility

A value indicating whether it is appropriate to make a job offer to a candidate

Eligible, Not Eligible

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.

Conditions

Conclusion

Candidate Initial Interview Rating

Candidate Compensation Expectation

Candidate Personality Rating

Candidate Cognitive Rating

Candidate Ranking

=

5

 

 

Is

Excellent

Is

Excellent

Is

1

>

3

Is

Aligned

Is

Good

Is

Excellent

Is

1

 

 

Is

Excessive

Is

Good

Is

Excellent

Is

3

>

3

Is

Aligned

Is

Excellent

Is

Average

Is

4

<=

3

 

 

 

 

 

 

Is

5

 

Conditions

Conclusion

Candidate Initial Interview Rating

Candidate Compensation Expectation

Candidate Personality Rating

Candidate Cognitive Rating

Candidate Culture Fit

=

5

 

 

Is

Excellent

Is

Excellent

Is

Yes

>

3

Is

Aligned

Is

Good

Is

Excellent

Is

Yes

 

 

Is

Excessive

Is

Good

Is

Excellent

Is

Yes

>

3

Is

Aligned

Is

Excellent

Is

Average

Is

No

<=

3

 

 

 

 

 

 

Is

No

 

Conditions

Conclusion

Candidate Initial Interview Rating

Candidate Compensation Expectation

Candidate Personality Rating

Candidate Cognitive Rating

Candidate Job Offer Eligibility

=

5

 

 

Is

Excellent

Is

Excellent

Is

Eligible

>

3

Is

Aligned

Is

Good

Is

Excellent

Is

Eligible

 

 

Is

Excessive

Is

Good

Is

Excellent

Is

Eligible

>

3

Is

Aligned

Is

Excellent

Is

Average

Is

Not Eligible

<=

3

 

 

 

 

 

 

Is

Not Eligible

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 1. 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


1 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 

 

Like this article:
  5 members liked this article
Featured
17159 Views
7 Comments
5 Likes

COMMENTS

marcthibault posted on Tuesday, July 6, 2010 3:49 PM
Good fun. I was sure you were headed for Zwicky boxes and GMA, then you took a turn into object-oriented design.

This diagramming approach should be very useful with stakeholders during the analysis phase and, as you intimate, should translate easily into the data design (not necessarily SQL).

One quibble: the part between the solid and dashed lines is redundant. A change here has to be reflected in two places.

One other thing: The candidate ranking "tree" will be different for different jobs. On the other hand different jobs may have some common components that we wouldn't want to duplicate. We wouldn't care about a manufacturing engineer's Java skills, but we would care about both a programmer's and engineer's industry knowledge. In non-trivial applications, this approach has all the issues to deal with that object-oriented design attracts. The tools and techniques of object-oriented design should be useful here.


LarryGoldberg posted on Wednesday, July 7, 2010 6:31 PM
Marc -

Thanks for your kind comments.

No sure what you mean about the the change between the solid and dashed lines require to be shown in two places.

On the "One other thing", you are correct about the need for the same decision model to accommodate potentially multiple different logic sets for different circumstances (you reference different jobs): we deal with this by the use of what we call "Decision Model Views", a subject that we tackle in the article "Evolving the Decision Model with Views" that is linked above. In that case study we deal with a multi-line, multi-state insurance company.
marcthibault posted on Wednesday, July 7, 2010 9:06 PM
Re the quibble: If you change the name "Candidate Cognitive Rating", you have to change it in its box and the reference in the "Candidate Ranking" box.

Most, if not all of the problems you're likely to encounter in elaborating this scheme have already been solved in the OO Design sphere. You may want to do some stealing.

In "Evolving..." another quibble: the Figure 2 Larger Version isn't larger.

In general, I'm concerned with the complexity of what you're proposing, the lack of techniques for abstraction and the need for a new view to say "unless..." The idea that we need something more usable than spreadsheets is a good one; I'm unsatisfied by the implementation.

I don't think I'd use it; I'd use an OO approach and one of the many powerful tools we have for managing OO designs. All the things you're doing can be modeled in much the same way with objects, but objects bring the possibility of abstraction, richer associations, and they add methods to the game (don't know what I'd do with methods, but they are there).

And then there are the use cases... A rule that has no possibility of being invoked is a waste of bits. The justification for a rule is a business activity that will or might invoke it. We call that a use case. If we're using this approach to make decisions about business rules, the use cases are necessary. In my experience, looking at the use cases often results in a rule being "clarified."
zarfman posted on Wednesday, July 14, 2010 10:54 PM

Aaahh, The old select one from many problem. Sometimes known as the kid in the candy store problem .i.e. the kid can have only one kind of candy.

Years ago I worked for a firm assigned the task of relocating an airport that had been destroyed by a major earthquake. The idea being to avoid that happening again sometime in the future. The airport is in good health as of today.

The problem was solved using decision analysis aka Decisions Involving Multiple Objectives

There are several books on the subject or you might contact Ralph Keeney at Duke, at least I think that's where he is.

Regards,

zarfman

paulsnx2 posted on Tuesday, August 28, 2012 3:20 PM
The first table has an error where you state <3 twice when you intended (as indicated by subsequent tables) >3.

That kinda confused me for a few minutes.
paulsnx2 posted on Tuesday, August 28, 2012 3:25 PM
Oh, and your condition numbering in that first table jumps from 1, 2, 3, 4, ... then to 6. There is no 5.
paulsnx2 posted on Thursday, August 30, 2012 3:16 PM
Another weird thing. If a guy is really smart (Cognitive_Rating is excellent), there is an advantage to asking for excessive compensation. Really?

And where you can accept good personality ratings in column 2, are you really intending to exclude an excellent personality ratings ratings?

If someone had a 4 initial interview rating, an excellent personality rating, and an excellent cognitive rating, well, they drop out off the table with nothing set.

This page is two years old. Does the methodology now have mechanisms to catch these errors?
Only registered users may post comments.




Latest Articles

Detailed Requirements for User Interfaces and Reports
Dec 01, 2019
0 Comments
For business analysts working in an environment where there is a gap between SMEs and the delivery of an IT-based solution for business needs, require...





Copyright 2006-2019 by Modern Analyst Media LLC