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.

About TableSpeak™ 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. 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. Decision tables based on TableSpeak are free of hidden assumptions and implicit interpretation semantics.

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:

1. One or more consideration(s) and their elemental cases.
   
   
2. Intersection cases (assuming more than one consideration).
   
   
3. Outcomes.

How can a physical matrix be used to represent these three kinds of things as easily-understood units (decision rules)?

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

Intersection Style

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:

1. No extra cells are required to hold outcomes.  The cells representing intersection cases do double duty.
   
   
2. No elemental cases are ever repeated anywhere in the decision table.

One-Rule-Per-Row Style

A 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:

1. Employs an additional column to hold outcomes.
   
   
2. Repeats elemental cases for each individual consideration to produce intersection cases.
   

One-Rule-Per-Column Style

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

The additional row could have just as easily appeared at the top of the physical matrix.  Figure 9 illustrates.

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:

1. Employs an additional row to hold outcomes (at top or bottom).
   
   
2. Repeats elemental cases for each individual consideration to produce intersection cases. 

Row-or-Column-Style

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.

Important:

An empty decision cell is always problematic in decision tables.

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.

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.

Important:

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:

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

In other words, no decision table laid out in any of the styles above ever needs to be exhaustive or non-redundant with respect to outcomes.  The styles cannot be differentiated on that basis.

---

The third and final part of this 3-part series explains the core 'must-knows' of conveying what a decision table means.

# # #