From Business Logic to Decision Model Structure

A quick way to learn about the Decision Model is to start with a business statement and translate it into
a structural element of a Decision Model.

Suppose a financial institution provides various kinds of loans. Recently, the number of customers
defaulting on loans has increased so significantly that the business experts want to sharpen the business
logic that determines the likelihood of such default. The business experts, therefore, need a Decision
Model that comes to a conclusion about a person’s likelihood of defaulting on a loan. This new Decision
Model needs to be put into action. The business then needs to monitor the frequency and magnitude of
subsequent loan defaults. A comparison of past to future defaults measures the effectiveness of the
new Decision Model. If the improvement is not what the business anticipated, the business logic within
the Decision Model will be changed, perhaps tested against sample loan applications, put into play in
the business, and the results measured again.

Gathering Business Logic Input

So, experts gather for a meeting to provide insights into what the new business logic ought to be. There
is much discussion. The following statement represents a conclusion reached about the likelihood of
defaulting on a loan based on certain business facts:

A person who has a poor employment history, a poor mortgage situation, and a high miscellaneous
loans assessment is highly likely to default on a loan.

Creating the Decision Model Structure

The next step is to translate this free-form textual sentence into a representation in a Decision Model.
The fundamental structural element of a Decision Model is a two-dimensional table relating conditions
to one—and only one—corresponding conclusion. So, which part of this statement is the conclusion and
which parts are the conditions?

Apparently, this statement evaluates three business facts (i.e., conditions): a Person’s Employment
History, Mortgage Situation, and Miscellaneous Loans Assessment. The statement comes to a conclusion
about a Person’s Likelihood of Defaulting on a Loan.

So, the two-dimensional structure is created, called a Rule Family, as shown in Table 2.1, representing
three condition columns that are tested to arrive at the conclusion column. Rule Families throughout
the book adopt a naming convention for column headings that does not include the apostrophe.

Populating the Decision Model

Content In Table 2.1, the first column contains the phrase “Rule Pattern,” which is explained later in this
chapter. For now, note that Table 2.1 has one column heading “Conditions” and another heading
“Conclusion.” Therefore, it is obvious where to put the conditions and the conclusion. Looking closer at
Table 2.1, each column has another heading. Under “Conditions,” the column headings contain the
name of the fact being tested: Person Employment History, Person Mortgage Situation, and Person
Miscellaneous Loans Assessment. Under “Conclusion,” the column heading contains the name of the
conclusion being reached, Person Likelihood of Defaulting on a Loan.

The rows below these column headings are populated using two cells for each label. The first cell is for
an operator to apply against the column heading and the second cell is the operand for that operator.
The first condition column in the first row has an operator of “Is” and an operand of “Poor.” Because
this is a condition column, these are interpreted as testing whether Person Employment History is Poor.
If this test is true and if the corresponding tests of Person Mortgage Situation and Person Miscellaneous
Loans Assessment are true, the conclusion column delivers a conclusion that the Person Likelihood of
Defaulting on a Loan is High.

It is easy to see that additional rows can be added to the Rule Family in Table 2.1, each of which will test
Person’s Employment History, Mortgage Situation, and Miscellaneous Loans Assessment and come to a
conclusion about the Person’s Likelihood of Defaulting on a Loan. Likewise, it is easy to imagine deleting
rows and updating rows until the business logic conforms to what the business experts prescribe.

However, although it is possible to populate the condition columns with rows that evaluate the Person’s
Employment History, Mortgage Situation, and Miscellaneous Loans Assessment, it is not possible to add
a row that tests Person’s Credit Rating. If a Person’s Credit Rating is to influence the conclusion about a
Person’s Likelihood of Defaulting on a Loan, another condition column is needed. So, the column
headings restrict the kinds of evaluations that can populate them.

Now, some questions arise about the Rule Family in Table 2.1:

 Do all decision makers agree with these conditions leading to this conclusion?
 What exactly is meant by Person Employment History? What are values other than Poor?
 What is meant by Person Mortgage Situation? What are its other possible values?
 What about Person Miscellaneous Loans Assessment? Which kinds of loans are included and
excluded?
 What is mean by Person Likelihood of Defaulting on a Loan and what are its possible values?
 What if Person Employment History is not Poor? What rows are needed in this Rule Family?
The answers are needed so that the Rule Family can be interpreted properly and so that its business
logic is complete and consistent. Naturally, some questions may spark interesting political discussions
and debates, depending on the importance and sensitivity of the conclusion itself. If there are
disagreements among business experts, appropriate accountability and stewardship will need to be
established for resolving these.

Distilling Sentences from the Decision Model

As mentioned earlier, it is possible to convert each row in a Rule Family into a sentence that sounds
natural to a business audience and is more precise and correct than the statement from which it is
derived. That’s because the translation from the original statement to its representation in a Rule Family
requires analysis leading to properly named labels as well as adherence to the remaining Decision Model
Principles.

For now, the row in the Rule Family in Table 2.1 can be translated into any one of the following
expressions:

 If/when Person Employment History is Poor and Person Mortgage Situation is Poor and Person
Miscellaneous Loans Assessment is High, then (the business concludes that) the Person
Likelihood of Defaulting on a Loan is High.
 A Person with Poor Employment History and Poor Mortgage Situation and High Miscellaneous
Loans Assessment has a High Likelihood of Defaulting on a Loan.
 A Person has a High Likelihood of Defaulting on a Loan if all of the following are true:
 Person Employment History is Poor
 Person Mortgage Situation is Poor.
 Person Miscellaneous Loans Assessment is High.

All of these expressions are equivalent to the row in Table 2.1. These expressions are referred to as the
natural language form of a business logic statement. There is no need, from a Decision Model
perspective, to enforce one particular kind of natural language expression over another, as long as the
expression is equivalent to the representation in the Rule Family. What is important is that the labels be
named and defined correctly and the corresponding conditions and conclusions be expressed correctly.
It is not intended that the natural language form will be executable by a computer, but it should be well
understood by a human who may be validating the business logic or even carrying it out manually.

Changing the Decision Model Content

Suppose that tomorrow, the business experts want to change some of the business logic in Table 2.1. In
particular, the business experts decide that a Person whose Employment History is Poor, Mortgage
Situation is Poor, but whose Miscellaneous Loans Assessment is Medium (instead of High) is highly likely
to default on a loan. Where would this change be made? The answer is easy. The Decision Model will
have only one Rule Family for each type of conclusion column. So, there is only one place to make this
change in Table 2.1 because there is a Rule Family that already makes conclusions about Person
Likelihood of Defaulting on a Loan. It already has columns for these conditions. So the change is simply
made in the appropriate row.

Suppose that after more discussion, the business experts decide that a conclusion about a Person’s
Likelihood of Defaulting on a Loan really ought to consider an additional fact: the Person’s Outside
Credit Rating. Where is this condition added? Fortunately, again, the change occurs in this Rule Family
because it reaches conclusions about Person Likelihood of Defaulting on a Loan. No other Rule Family is
needed. However, a new condition is needed, as shown in Table 2.2.

It soon becomes obvious that there is more to know about this new fact, such as what should be its
name and what kinds of values it can have. And, working with the partly populated Rule Family in Table
2.2, questions arise about how the new condition impacts the values in the already populated rows.

These examples illustrate that changing business logic in a Decision Model is straightforward. That’s
because a Decision Model is constrained such that each conclusion has a home in one—and only one—
place.

The next section looks at the need for more than one Rule Family in a Decision Model and how Rule
Families relate to one another.

Relating Decision Model Structures

We return to the example of the financial institution. Table 2.2 raises the need for more information
about its condition columns. Starting with the first condition, where do the values for Person
Employment History come from? Does someone simply provide the values, such as Excellent, Good, or
Poor? Or do the values come as input from a Web page or a file? Or are the values the results obtained
by evaluating other facts?

At this point, assume the business experts point out that the value for this condition column is actually
determined by evaluating other facts. The business experts come to a conclusion about Person
Employment History based on facts such as a Person Years at Current Employer and the Person Number
of Jobs in the Past Five Years. So, an additional Rule Family is created in which these two facts form
condition columns and where the conclusion column contains the heading “Person Employment
History” as shown in Table 2.3. In this way, the Decision Model now contains two Rule Families.

It is worth noting that Table 2.3 introduces the concept of an interim decision. An interim decision is a
conclusion determined during the course of a transaction but which may not be permanently stored in a
database. In this case, the interim decision is Person Employment History. Its value is determined by
executing the corresponding Rule Family, but the value may never be stored permanently. The value
may simply serve as input to another Rule Family, sort of an in-flight conclusion.

As discussions continue with the business experts, the need arises for yet another Rule Family. This one
comes to a conclusion about Person Miscellaneous Loans Assessment, which is based on two facts: a
Person’s Student Loans and a Person’s Business Loans. Table 2.4 illustrates the three Rule Families.

It is critical to note that the conclusions in the first and third Rule Families also serve as conditions in the
second Rule Family. There is a need to show these relationships. The best way is to create lines that
connect related Rule Families. However, a diagram showing the full content of a Rule Family and the
relationships among all Rule Families in a Decision Model quickly becomes unmanageable. It is easy to
imagine rapidly creating many Rule Families and soon being unable to fit them into an easily viewed
whole. So, another kind of diagram is needed, as illustrated later in this chapter.

For now, the next section emphasizes two more points about Rule Families: the role of Rule Patterns
and a comparison to decision tables.
The Role of Rule Patterns
Suppose business experts in the financial institution continue to populate the Rule Families. As some
point, the populated Rule Family is as shown in Table 2.5.

Table 2.5 comes to a conclusion about a Person’s Miscellaneous Loans Assessment and requires careful
inspection to understand its business logic.

First, there are three types of conditions that influence this conclusion: Person Student Loans, Person
Business Loans, and whether a Person is a current customer. For now, for the sake of simplicity, the
value of a Person’s Student Loans and Business Loans is a simple yes or no, rather than loan amounts.
However, not all three conditions contribute together to the corresponding conclusion. The first and
third rows consider only whether a Person has student loans and is a current customer. In fact, if a
person is a current customer and has a student loan, the business considers this as carrying a low risk
(probably because the financial institution is involved in these loans). If a person is not a current
customer and has a student loan, the business considers this as carrying a medium risk (perhaps
because the financial institution is not able to know much about those loans).

The second and fourth rows only consider whether a person is a current customer and whether the
person has business loans. A person who is not a current customer with a business loan carries a higher
risk than does a person who is a customer with a business loan.
The point is that not all three types of conditions need to be evaluated to reach a conclusion about
Person Miscellaneous Loans Assessment. In fact, rows two and four evaluate two conditions. Rows one
and three evaluate a different set of two conditions.

In the Decision Model, a set of Rule Family rows with a common set of condition cells that are populated
is called a Rule Pattern. Therefore, Table 2.5 is a Rule Family comprising two Rule Patterns. Rows one
and three form one Rule Pattern, and rows two and four form another. Rule Patterns become important
when the Decision Model Principles are applied to Rule Families.

The second point about Rule Families is a comparison with the traditional notion of decision tables.

Not Just a Set of Decision Tables At first glance, the Rule Families of a Decision Model appear to be
nothing more than familiar decision tables, but this is not so. A common definition of a decision table is
“a table of all contingencies and the actions to be taken for each” (Wordwebonline “Decision Table”). It
is true that a Rule Family in a Decision Model resembles a decision table in that both are two-
dimensional structures of contingencies leading to actions or conclusions. However, the Rule Family in a
Decision Model differs from a decision table in two important ways.

First, each Rule Family adheres to a full set of principles whereas a traditional decision table does not do
so.* Second, not only may each Rule Family be related to other Rule Families, but Rule Family
relationships are managed carefully. Traditional decision tables are not so related. So, out of these
disciplined and related Rule Families, a Decision Model is formed.
Decision Model Notation and Supporting Software Tools
To fully represent the Decision Model and its principles, a Decision Model notation is needed for at least
two different kinds of diagrams: the Rule Family table and the Decision Model diagram.

The Decision Model Diagram

The Decision Model diagram depicts only the Decision Model’s structure and not the detailed content of
its Rule Families.

A Decision Model diagram, such as the one in Figure 2.1, begins with an octagonal shape that represents
the entire business decision. It is this shape that relates to tasks within business process models and to
steps within use cases, precisely at places in those models where the business decision is in play. The
business decision shape also connects to business objectives, business tactics, and business
requirements.

The other shapes in the Decision Model diagram represent Rule Families. The Decision Model in Figure
2.1 has six Rule Families.

The Rule Family directly connected to the business decision shape is called the Decision Rule Family
because its conclusion is the conclusion sought by the entire Decision Model.
The name of each Rule Family is simply its conclusion column heading. (This is possible because one of
the principles of the Decision Model limits a Rule Family to having only one conclusion column).
Therefore, the name of the Decision Rule Family in Figure 2.1 is “Policy Renewal Method.”

All labels below the Rule Family name are the condition column headings that contribute to that
conclusion. So, the Decision Rule Family in Figure 2.1 has two conditions, one named Policy Tier Within
Bounds and the other named Policy Renewal Override.

The labels below the solid line but above the dotted line denote condition column headings that serve
as a conclusion column heading in another Rule Family. Therefore, in Figure 2.1, the Rule Family named
Policy Renewal Override has a condition column heading of Insured Major Ownership Change, which is a
conclusion column heading elsewhere in the Decision Model.

The labels below the dotted line denote condition column headings that do not serve as a conclusion
column heading in another Rule Family. These condition column values will be provided by known fact
values (e.g., persistent data).

The solid line terminated by the dot connects Rule Families that have an inferential relationship—
meaning that the conclusion of one Rule Family is used as a condition in another. The dot appears at the
end of the line connecting the Rule Family whose conclusion serves as a condition in the Rule Family at
the other end of the line.

The (Pnumber) denotes Rule Pattern numbers within a Rule Family. So, the Decision Rule Family in
Figure 2.1 contains three Rule Patterns.

A summary of this explanation is shown in Figure 2.2, which contains the complete Decision Model
diagram in the upper-left corner. The circle in that complete Decision Model diagram shows the area of
the model that is magnified in the figure.

Rule Family Table

A Rule Family table provides a complete view of the content of a Rule Family. Clearly, each Rule Pattern
in the diagram may represent from one to many rows of business logic statements. The Decision Model
diagram enables a view of the structure of the model without having to deal with the detailed content.

Figure 2.3 shows a Rule Family table within the context of a Decision Model diagram. Again, the Decision
Model diagram in the top left carries out the decision to Determine Policy Renewal Method. The circle
shows the portion of the Decision Model that is magnified. The Rule Family table is the populated Rule
Family named Policy Renewal Method, and this view enables a drill down to the details of all the
business logic statements of that Rule Family.

The rows are the set of business logic belonging to the Rule Family. So, each business logic instance is
represented by a single row in the Rule Family table. The condition and conclusion columns participate
in logical expressions in the body of the Rule Family. This Rule Family has two condition columns and
one conclusion column. The order of these columns is unimportant, but they are shown in a convenient
way whereby the condition columns are on the left and the conclusion column is on the right. Because
both these condition columns serve as conclusions in other Rule Families, the condition columns are
shown below the solid line and above the dotted line. The actual business logic instances appear as if
they were data in the Rule Family. A natural language translation of this Rule Family would be: “If the
Policy Renewal Override is … and the Policy Tier Within Bounds is …, then Policy Renewal Method is …”
Hopefully, it has become clear that the Decision Model serves as a universal communication of business
logic, regardless of industry. In fact, the person creating a Decision Model need not be an expert in the
underlying industry, business, or even business decision. Access to business expertise is always needed,
however.
Software for Building Decision Models and Diagrams Ideally, Decision Modeling software* allows the
creation of a Decision Model dia- gram even before it is populated. On the other hand, such software
also allows for the population of Rule Families first and automatic generation of the corresponding
Decision Model diagram. In either case, robust Decision Modeling software allows the viewing of the
Decision Model diagram and drilling down into its Rule Family tables. Such software also allows the
viewing of business objectives that drive the Decision Model and where in processes and systems that
Decision Model is in play. This kind of traceability is extremely important because it enables evaluation
of the impact of proposed business logic changes on processes, systems, and business objectives.