Designing Decision Tables Part 2: Fundamental Styles
Extracted from Decision Tables: A Primer: How to Use TableSpeak™, by Ronald G. Ross, 2013, available (free) on http://www.brsolutions.com/IPSpeakPrimers
See [glossary definitions] for terms colored like this: decision table
The basic structure of all decision tables is based on rows and columns that intersect in a physical matrix. If there are m rows and n columns, the matrix can contain m × n cells.
No cell means anything until you indicate what it means. All cells are empty until you populate them. The physical matrix is simply a blank canvas.
TableSpeak makes two fundamental (and common-sense) assumptions about how this blank canvas can be used to represent decision rules.
Assumption 1. Each cell should always (a) represent just one kind of thing, and (b) hold just one kind of thing. If not, there's no way to guarantee uniform meaning in use of the physical matrix. All bets are off in trying to interpret and implement the result.
Assumption 2. All parts of each decision rule should be represented such that they are easily understood as a unit. Decision rules are strings of meaning, like sentences. The strings can't be represented randomly; the parts have to come together or the 'sentence' meaning is lost.
TableSpeak is a BRS set of conventions for business-friendly representation of decision tables and their meaning (semantics) in declarative fashion.
Central to TableSpeak are:
- Highly pragmatic guidelines and thresholds for selecting the best decision-table format. TableSpeak avoids simplistic and counterproductive one-size-fits-all approaches.
- The principle of single-sourcing, essential for achieving true business agility.
- Restrictions — business rules for ensuring the integrity (correctness) of decision-table content.
TableSpeak optimizes for readability by non-IT professionals and business people.
Decision tables based on TableSpeak are free of hidden assumptions and implicit interpretation semantics.
- The question the decision table answers is always emphasized.
- Scope (applicability) is declared explicitly.
- Unnecessary complications to decision-table structure (such as exceptions) are externalized.
- Meaning is comprehensively expressed.
- Business vocabulary is carefully used.
The most basic question in formatting decision tables is therefore how many kinds of things can decision rules involve?
The answer is three kinds of things:
- One or more consideration(s) and their elemental cases.
- Intersection cases (assuming more than one consideration).
Fortunately, the options in that regard are quite limited. In fact there are just three fundamental styles in employing a physical matrix to create decision tables. Two of the styles are simply variations on the same theme.Each style is introduced below, using the example in Figure 1. This decision table addresses the question What coat should be worn?
Figure 1. Example of a Simple Decision Table
The simplest format for decision tables — the one friendliest for business people — is the intersection style (sometimes called crosstab style).
Figure 1 is organized using this style. As that example illustrates, considerations are organized using each of the two dimensions (rows and columns). All elemental cases for each consideration are literally 'intersected' using rows and columns.
The cells of the leftmost column and of the topmost row represent elemental cases. Cells where these rows and columns meet represent intersection cases. To illustrate, all the cases represented by the What coat should be worn? decision table in Figure 1 are labeled in Figure 2.
Figure 2. How Cases Are Represented in the What coat should be worn? Intersection-Style Decision Table
Although the physical cells where rows and columns meet in Figure 2 represent intersection cases, those cells hold outcomes (and can therefore be called decision cells). Figure 3 illustrates.
Figure 3. Outcomes in the What coat should be worn? Intersection-Style Decision Table
The intersection style is physically notable in two basic regards:
- No extra cells are required to hold outcomes. The cells representing intersection cases do double duty.
- No elemental cases are ever repeated anywhere in the decision table.
One-Rule-Per-Row StyleA second format for decision tables is the one-rule-per-row style.
In this style each row in its entirety (below the topmost) represents a decision rule. Figure 4 recasts the What coat should be worn? decision table in Figure 1 into this style.
This format features:
- One column per consideration, starting on the left. The consideration is labeled in the top row of the column, then elemental cases appear in the cells below it.
- An additional column on the right provides decision cells; that is, physical cells to hold the appropriate outcome for each row (decision rule).
The additional column could have just as easily appeared on the left of the physical matrix. Since most Western languages are written from left to right, however, the right-hand side generally proves more natural for speakers of those languages.
Placement on the right unfortunately does nothing to discourage practitioners from using the style to express or interpret the content of the rows as If … and if … then do this. Such use represents a procedural rather than a declarative approach. We recommend never using a decision table for that purpose.
Figure 4. The What coat should be worn? Decision Table in the One-Rule-Per-Row Format
Figure 5. Elemental Cases and Outcomes Identified for the What coat should be worn?
Decision Table in the One-Rule-Per-Row Style
Figure 5 explicitly identifies the elemental cases and outcomes evident in Figure 4.
To simplify the representation of a one-rule-per-row decision table, elemental cases in consecutive rows that are alike are often consolidated. Figure 6 illustrates such consolidation for Figure 4.Starting with that Figure, elemental cases are also simplified from this point forward in the discussion to just yes and no to avoid wordiness.
Figure 6. The What coat should be worn? Decision Table with Consolidation of Elemental Cases in the Leftmost Column
Now this revised version of the decision table avoids repetition of elemental cases in the leftmost column, rendering the decision table a bit more approachable. Note that repetition of elemental cases in the second column remains.In the one-rule-per-row style there is no literal intersection of rows and columns to produce intersection cases. Rather, elemental cases are effectively concatenated (united in a series) to form intersection cases. Figure 7 illustrates.
Figure 7. Intersection Cases Addressed by the What coat should be worn? Decision Table in the One-Rule-Per-Row Style
Compared to the intersection style, the one-rule-per-row style:
- Employs an additional column to hold outcomes.
- Repeats elemental cases for each individual consideration to produce intersection cases.
A third format for decision tables is the one-rule-per-column style. In this style, each column in its entirety (except the leftmost) represents a decision rule. Figure 8 recasts the What coat should be worn? decision table in Figures 1 and 4 into this style.
Figure 8. The What coat should be worn? Decision Table in the One-Rule-Per-Column Format
This format features:
- One row per consideration, starting at the top. The consideration is labeled in the leftmost column of the row, then elemental cases appear in the cells to the right of it. (Like elemental cases in the topmost row could have been consolidated.)
- An additional row at the bottom provides decision cells; that is, physical cells to hold the appropriate outcome for each column (decision rule).
Figure 9. The What coat should be worn? Decision Table in the One-Rule-Per-Column Format with Outcomes Along the Top Row
We recommend (but do not insist upon) this top-row-for-outcomes arrangement for two reasons:
- It most closely aligns with the subject-orientation of well-written
business rules. For example, the first decision rule (in the second physical column) would be best written: A lined raincoat should be worn if it is cold and rainy.
- It physically emphasizes that decision rules are declarative, rather than procedural. Putting the outcome at the bottom makes it tempting to express or interpret a decision rule as If … and if … then do this. As before, we recommend never using a decision table for that purpose.
Figure 10. Elemental Cases and Outcomes Identified for the What coat should be worn? Decision Table in the One-Rule-Per-Column Style
Figure 10 explicitly identifies the elemental cases and outcomes evident in Figure 9.
In this style there is no literal intersection of rows and columns to produce intersection cases. Rather, elemental cases in effect are effectively concatenated (united in a series) to form intersection cases, as illustrated by Figure 11.
Figure 11. Intersection Cases Addressed by the What coat should be worn? Decision Table in the One-Rule-Per-Column Style
Compared to the intersection style, the one-rule-per-column style:
- Employs an additional row to hold outcomes (at top or bottom).
- Repeats elemental cases for each individual consideration to produce intersection cases.
The one-rule-per-column style is very much like the one-rule-per-row style on the two points above.The difference between the two styles (more perception than substance) is simply that the former uses rows, rather than columns, to hold decision rules and outcomes. Therefore we often refer to these two styles jointly as the row-or-column-style. Both styles are less friendly to business people than the intersection style, and as discussed momentarily, are more prone to certain kinds of anomalies.
Basic Advantages of Intersection-Style Decision Tables
Besides being very approachable for business people, intersection-style decision tables have additional advantages, ones so basic that at first they might not be obvious.
Assume that the elemental cases of each consideration of an intersection-style decision table are listed exhaustively and non-redundantly — that is, each elemental case appears one and only one time. (Software might be needed to ensure this, but it's a relatively simple matter.)
Then it is physically impossible for any intersection case:
- Not to be represented at all (i.e., missing).
- To be represented more than once.
Why are these characteristics so important? The former helps ensure completeness. The latter provides a single point of change (single-sourcing) for each decision rule.To illustrate these advantages, Figure 12 includes revisions of the What coat should be worn? decision table in Figure 1.
Figure 12. Empty Decision Cell and Changed Outcome in an Intersection-Style Decision Table
Completeness. The upper-right decision cell in this version of the decision table is empty. The omission is highly visible.
In the intersection-style format an empty decision cell signals clearly that an outcome — more precisely a decision rule — is missing. In other words, such an omission signals the decision logic is not complete.
No matter what style is used, a decision table should never leave any doubt about what outcome is appropriate for any given case in scope.
An empty decision cell is always problematic in decision tables.
Single-Sourcing. Suppose the appropriate outcome for a rainy-but-not-cold day (unlined raincoat) were to change (say, to umbrella). In the intersection-style decision table above, there is one and only one place, one quite obvious, to make that change.
Single-sourcing is always a best practice in business rules.
The reason is simple — things change constantly. So modifying any part of decision logic should always be intentional (and traceable), not accidental or haphazard.
Row-or-Column-Style Decision Tables
Achieving these important goals in the row-or-column-style is not quite so straightforward — at least without specialized software support.
Decision Rules. To illustrate potential problems, deliberate mistakes have been made in Figure 13. Keep in mind these mistakes are relatively easy to spot because the decision table is so small.
Figure 13. Mistakes of Redundancy and Omission in the One-Rule-Per-Row Style Decision Table
Completeness. The first deliberate mistake in Figure 13 is the omission of the last row in Figure 4 (indicating no coat should be worn if it is not cold and not rainy). Unlike the intersection style, there is no blank cell to warn you; the row just isn't there. So it's not so easy to see that the decision logic is incomplete.
Single-Sourcing. The second deliberate mistake in Figure 13 is the repetition of the decision rule for a cold, rainy day. The decision rule is not single-sourced, which leaves the door open to integrity (correctness) problems. Redundancy like this is not so easy to spot either.
Challenges for the Row-or-Column Style
Intersection Cases. One challenge for the row-or-column-style is that intersection cases, rather than elemental cases, need to be exhaustive and non-redundant. (In technical jargon ensuring strict, logical uniqueness of intersection cases is called single-hit.)
Since the style does not exploit the physical matrix in that regard, specialized software is inevitably required to support it. Surprisingly, some software tools don't provide it.
Elemental Cases. In the row-or-column-style, elemental cases for all considerations cannot be listed non-redundantly. In fact, the elemental cases for every consideration except one are listed redundantly in order to set up intersection cases. (Use of the special symbol does not matter (dash) often reduces the total number of repetitions.)
In general, a large number of elemental cases will not be single-sourced. Refer to Figures 6 and 9 for illustrations. Managing such redundancy can prove non-trivial.
Clarification Regarding Outcomes
Two points concerning outcomes on which all the styles discussed above do not differ:
- One or more potential outcomes might be absent from a decision table. A decision table is not required to use the complete set of potential outcomes.
- Outcomes need not be unique within a decision table. Any potential outcome can appear multiple times — that is, as the outcome for more than one decision rule.
The third and final part of this 3-part series explains the core 'must-knows' of conveying what a decision table means.
# # #
About our Contributor:
BRSolutions Professional Training Suite
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.
How to Define Business Terms in Plain English: A Primer
How to Use DecisionSpeak™ and Question Charts (Q-Charts™)
Decision Tables - A Primer: How to Use TableSpeak™
Tabulation of Lists in RuleSpeak®: A Primer - Using "The Following" Clause
Business Agility Manifesto
Business Rules Manifesto
Business Motivation Model
Semantics of Business Vocabulary and Business Rules