Document the decision logic

The next step is to document the logic that the decision uses to reach its conclusion. In Blueworks Live, we do this with decision tables, as shown in Figure 3-10, which organize the logic into rows and columns. Decision tables are a very straightforward and intuitive way to document decision logic, as many people are familiar with spreadsheet applications and so are comfortable both documenting and understanding this kind of tabular representation. If you would like to understand more about the logical structure of decision tables and how we use them in this paper, read the next section. Otherwise, it is fine to skip this for now and learn more about decision tables when you get into the AIC example that is presented later in the paper. To learn more about decision tables in general, there are some excellent references in the appendix that you can leverage, should you want to explore this topic further.

Figure 3-10 Example of a decision table containing decision rules

Decision table conventions

There are several different types of decision tables, and various options for documenting and interpreting them. In this paper, we use unique, single-hit, and rules as rows decision tables because these are usually the easiest to understand and work with in the beginning. We will also follow some best practices of decision design to ensure that both the decisions and decision rules described in these decision tables are atomic and readable.

The decision table conventions followed in this paper are described below:

Column headers in a decision table

The facts to be considered (the considerations) and the conclusion reached (the conclusion) are identified in the column headers of the table:

򐂰 The considerations in the decision table typically map one-to-one to the decision inputs that are documented in the Blueworks Live decision diagram. However, sometimes a

consideration may be derived from one or more decision inputs, in which case it will not map directly to a single decision input.

A consideration column heading may contain a decision input or any combination of addition, subtraction, multiplication, division, and exponentiation of decision inputs and literals.

򐂰 By definition, a decision has a single output (that is, reaches a single conclusion). There must be a single conclusion column in the decision table that maps directly to the decision output in the Blueworks Live decision diagram. In some cases, you may choose to create an additional conclusion column to capture a key piece of information related to the conclusion (typically a message column, describing the reason the conclusion was reached in natural language business-friendly text). But only one of these conclusion columns can be designated as the decision output in the decision diagram.

Cells in a decision table

We have to look at two types of cells:

򐂰 Each cell in a consideration column contains some sort of expression that is applied to the consideration identified in the column header:

– These condition cells typically contain operators such as =, !=, <, <=, >, >= that test the consideration in the column header against a literal, another decision input, a range, or a list of these. You can express these operators in natural language, or use the symbols. Do whichever produces the most understandable decision table for your organization.

– When a cell is left empty, it means that any value for that consideration will cause the condition to be evaluated to true.

– If there is no operator in a populated cell, then we assume the operator to be =.

򐂰 Each cell in a conclusion column contains some sort of expression that is used to assign a value to the conclusion identified in the column header (that is, the decision output):

These conclusion cells often contain a simple literal or numeric value, but can also compute a numeric value using arithmetic operators (+, -, *, /, and so on) and decision inputs.

Rows in a decision table

Each row in the decision table represents a decision rule.

Each decision rule has a single path to the conclusion. In other words, the cells in a row are implicitly ANDed together to reach the conclusion. ORs are not supported between columns.

Decision table best practices

In addition to following the above conventions, the decision tables in this paper are documented with the following best practices in mind:

򐂰 It is a good idea to limit the number of consideration columns for readability purposes. If you find yourself with more than seven or eight consideration columns, you might want to consider breaking the decision up into sub-decisions.

򐂰 Each decision rule should be unique in that no more than one decision rule should be able to evaluate to true for any given set of inputs. In other words, there should not be overlap between rules.

򐂰 There should be no implied order of evaluation in a decision table, no notion of sequence.

Rather, your decision tables should be organized in the way that most clearly reflects the business knowledge, and is easiest to understand.

򐂰 A decision table should be as complete as possible.

򐂰 A decision table should be as easy to understand as possible. For readability purposes, we sometimes make an exception to these last three guidelines. It can become quite tedious filling out endless rows of a decision table just to make sure that every possible combination has been accounted for explicitly. Similarly, it can sometimes be hard to read such a decision table:

– When it makes sense, we may use empty cells, rather than creating a decision rule for every single possible combination of considerations. In these cases, we may relax the uniqueness constraint described above….as long as the overlapping decision rules all reach the same conclusion. The Analyze Driving Record decision table in Figure 3-11 shows an example of how you might document a decision table like this in Blueworks Live.

Figure 3-11 Making a decision table more readable by using empty cells

– When it makes sense, we may create an exception table for a decision table that provides an else, or otherwise clause. This way, the decision table does not have to be cluttered with many decision rules that essentially have the same meaning. The Validate Salary decision table in Figure 3-12 shows an example of how you might document a decision table like this in Blueworks Live.

Figure 3-12 Making a decision table more readable by using an Otherwise clause