The Decision Model’s Best Kept Secret

The goal the Decision Model (TDM) is to achieve two simple uncompromising intentions. The first is that TDM be based on sufficient theory so as to lead to stable decision models and so that TDM itself will stand the test of time. To achieve this, TDM is defined by its principles. These address all of its aspects – from its structural look-and-feel to the integrity of its detailed logic content [1].

The second uncompromising intention is more elusive, but may be even more important. It is that TDM serve the business community first (and the technical community second). The phrase “business community” refers to people who have primarily business, not technical, responsibilities. Therefore, it includes business managers, business subject matter experts, business analysts, and requirements analysts, for example. To serve the business community, TDM must be easily understood by this audience. There should be no need for this audience to know anything about supporting or underlying technology.

The Decision Model (TDM) Difference
The idea of serving the “business community first” is a differentiator. It is different from other approaches primarily for, or by, technology professionals. For example, some decision modeling and business rules approaches rely on data-oriented models to start with. This not only requires knowledge of how to build or interpret these models, but often requires that these models exist before a business person can express rules or logic. That’s because these approaches require the business person to use to such models as the vocabulary for expressing the rules or logic.

However, practice proves that this is backwards. Business audiences are not typically interested how data is represented in models. Instead, when it comes to decision models, business audiences simply want to focus on converting business logic, policies, or requirements into decision models that reflect business meaning and whose quality is measurable. These audiences do not need data models to do that. So, serving the “business community first” means understanding exactly how the business community wants to carry out their decision modeling. From this understanding, we can craft the means by which they can do exactly that, without unnecessary distractions and delays. We have learned that the best-kept secret by which the business community can “do it their way” is the TDM business glossary. So, what exactly is the TDM business glossary?

Business Glossary Defined
In TDM, the business glossary is simply a managed list containing an entry for every fact type used in a community of decision models [2]. So, the business glossary is the complete collection of fact types appearing either as column headings (for conditions and conclusions) or appearing within Rule Family cells. A fact type is simply a piece of information that is tested (in a condition) or is the result (a conclusion). Sample fact types are: Person Credit Score and Person Employment History. The TDM business glossary is also the foundation behind validating some of TDM principles and is an important source for some TDM functionality, such as generating test cases. For these requirements, the business community needs only a list, not a model.

Power to the Business
To do decision modeling their way, the business community wants eight important capabilities listed in Table 1. Some of these are surprising and all are interesting and potentially, game-changing. Let’s explore these and corresponding solutions (in software and practice) for delivering them.

Table 1: Eight Business Capabilities for the Business Community

Business capability #1: Just-in-Time Fact Types
The business community wants to create just-in-time fact types. In other words, they want to create fact types when the fact types are needed in the decision models, not before. That is, the business community typically doesn't want to be forced to create the list of fact types (or a model of them) prior to creating decision models because doing so slows down decision model creation. The business community wants instead to get started immediately on decision modeling not on fact type listing or modeling.

Solution: Practice (and software if using) must support dynamic fact type creation as the norm. Often, the decision modeler (not even the glossary administrator) is the first one to create new fact types in the business glossary in support of decision modeling efforts. Of course, good practice is to reuse fact types that already exist before creating new ones on-the-fly.

Business capability #2: Business-Friendly Fact Type Names
The business community definitely wants to use their own vocabulary in naming their fact types. Their vocabulary usually comes from actual business sources, such as a compliance or eligibility documents. These names are called business-friendly names to differentiate them from more formal or technical names that may exist. Business-friendly fact type names are the way every decision model in the glossary community references the fact types.

 Solution: Practice (and software if using) must not impose restrictions on fact type names. Nevertheless, in practice, it is useful to provide guidelines for naming fact types to best reflect their meanings. Or, allow total freedom in fact type names, but capture an additional fully qualified name for each fact type (perhaps governed by a data professional). Either way, the decision models contain only the business-friendly names for all fact types. The point is not to force unnatural fact type names on the decision models.

One common (simple) guideline for coming up with business-friendly names for fact types is as shown in Table 2. To use it, start with a fact type and express it using “of language,” such as “the first name of a patient on a claim.” Following the sequence of columns in Table 2, the business source for this fact type is “Claim”, its normalization/organizing factor is “Patient” [3], its descriptive word is “First”, and its business data type [4] is “Name”. This results in a business-friendly name of “Claim Patient First Name” as shown in the bottom row of the table.

Table 2: One common set of guidelines for naming business-friendly fact types

Business capability #3: Simplified Flattened Fact Types
To repeat, to the business community, a fact type is either a column heading or appears in a Rule Family cell. More often than not, the fact type is not how the actual data is represented in databases. Databases represent information in its most atomic state (maximum decomposition) so that everyone can use it. However, in a decision model, fact types need only to be as atomic as the decision models need them to be. This means that fact types in decision models are decomposed only to a level referenced in decision models, not necessarily decomposed as they would be in a fully decomposed and normalized data structure. In other words, in decision models, fact types are flattened if that is how they are best referenced for business usage in business logic. Flattened fact types include more adjectives in their names because their names conceal codes in look up tables or joins of data tables.

 Solution: Practice (and software if using) must be the norm. The previous example of Claim Patient First Name is flattened. It may actually exist in a database as attributes in four tables: The first name of Person (in a Person table) who plays the role of Patient (in an intersection table of Person/Claim) on a Claim (in a Claim table). Decision models do not include, as a column heading, the join of four tables. Flattening it into one composite fact type and naming it (as illustrated in Table 2) is simple for the business community. How that fact type value is actually stored in a database is not the business community’s concern.

An example helps. Consider the driver’s license in Figure 1 and specifically the fact type labeled DOB.

Figure 1: Driver License as Input

In creating logic that tests the value of DOB, a business person simply thinks of it (using Table 2) as Driver Birthdate. In reality, it may exist in a database as shown in Figure 2. That is, Person Birth date is an attribute in a Person table which has a relationship (one-to-many) with a Driver License table. Therefore, to turn the data from Figure 2 into the flattened Driver Birth Date in Figure 1 requires a two-table join. But the business person need not worry about that.

In fact, DOB in a database could be even more complicated than in Figure 2. It could be decomposed into attributes within four tables if there were Person table, Vehicle Stop table, Person Role table, and Person/Vehicle Stop/Role intersection table. Again, the business people don’t care. To them, it is simply Driver Birth Date - a very simple flattened fact type.

Figure 2: DOB in Database

It is even possible for DOB to be represented in two different data sources in two different ways. The business audience need not worry about that because the same business glossary entry, Driver Birth Date, is how it would appear in all decision models. Behind the scenes it can correlate to two different sources.

So, flattened fact type names are likely to include adjectives which usually represent table joins in the database world. Sometimes there can be so many adjectives as to make naming a bit confusing. It may be useful to suggest a sequence of types of adjectives as shown in Table 3.

Table 3: Sequencing Adjectives in Fact Type Names

The second through seventh columns in this table expand the third column in Table 2 because they represent different kinds of adjectives that may apply to a flattened fact type name.

Using Table 3, if useful, results in uniformly named fact types, such as the following:

• Row 1 fact type: Loan Monthly Estimated Total Closing Cost Amount
• Row 2 fact type: Loan Issue Date
• Row 3 fact type: Loan Property Taxes Escrow Indicator
• Row 4 fact type: Loan Monthly Principal Amount
• Row 5 fact type: Loan Monthly Total Payment Amount

Not shown in Table 3 are units of measure as an additional adjective. It is often more useful to append units of measure at the end of the fact type name for clarity. Examples of business-friendly fact type names containing units of measure are: Truck Oil Amount in Gallons, Tanker Oil Amount in Barrels, or Person Weight in Kilograms.

Business capability #4: Minimal Business Fact Type Metadata
The business community wants to provide only information about their fact types (i.e., metadata) needed for decision modeling. This means only four core pieces of metadata for fact types: a business-friendly name, business definition, business data type, and business domain values (the latter two are covered below).

 Solution: Practice (and software if using) must support these four pieces of metadata, with other optional pieces. See Table 4 for one possible partial business glossary containing the four core pieces.

Table 4: Sample Business Glossary with Four Pieces of Metadata

Business capability #5: Interim Fact Types
The business community wants to include in the business glossary not only entries for stored data, but also entries for decision model interim fact types. Interim fact types are the conclusions of Rule Families that are conditions in other Rule Families. Since these represent conclusion values during execution of decision models, interim fact types are not typically stored and so are absent from most data centric models. However, these are the glue that holds together the decision-making logic of the organization’s decision models and are therefore of utmost business importance.

 Solution: Practice (and software if using) must allow for the capture of interim fact types in the business glossary in exactly the same way as persistent fact types. There is no distinction in the glossary between interim and persistent fact types. In fact, all fact types in Table 4 may be interim fact types. For example, the Supervising Driver Age in Years may be calculated in a supporting Rule Family. The Supervising Driver License Validity may be determined in a supporting Rule Family by testing state code, vehicle type, etc. The Supervising Driver Compliance may be the conclusion of a Rule Family whose conditions are Supervising Driver Age in Years and Supervising Driver License Validity, both determined in their own Rule Family.

Business capability #6: Business, not Technical, Data Types
The business community wants to assign business data types. While data types play an important role in data modeling and database design, they play a different role in decision modeling. Specifically, in decision models, domain values determine which operators [5] in Rule Family cells are appropriate for that fact type. For example, the business data type for Supervising Driver Birth Date in Table 4 is “Date”. This means that only operators specific to dates are appropriate, but operators for interpreting (free-form) text are not. Validation of decision models uncovers these kinds of inconsistencies based on the business data types in the business glossary.

The business community does not need to consider all data types that are possible in a database. They only need only those that make sense in their decision models regardless of physical data types.

 Solution: Practice (and software if using) must allow for a set of business-oriented data types and use these to validate decision model operators.

The most common business-friendly data types are indicator, code, enumerator, date formats, quantity, amount, and percent. A business data type of indicator simply means there are two mutually exclusive values. A business data type of code means a set of more than 2 values, such as a fact type of state code. A business data type of enumerator is an ordered set of values. A business data type of quantity is an integer value indicating a count of something. Amount is a value of currency. Percent is a rate, amount, or number of each hundred of something.

It is good practice to include the business data type in the fact type name (as indicated in Table 2 and Table 3) if doing so adds clarity to the fact type.

Business capability #7: Business, not Technical, Domain Values
The business community wants to assign business domain values. Like data types, domain values play a role in data modeling and database design, but they play a different role in decision modeling. First, business domain values should be business-friendly with specific business semantics for clarity. So these values are not necessarily the same as those stored in the corresponding database. For example, for a fact type of Driver Seat Belt Status Indicator, its two domain values may be “worn” and “not worn”.

It is usually undesirable to have domain values, in general, of “yes” or “no”, “true” or “false” or encoded values as found in some data sources. Such domain values obscure the meaning of the fact type itself.

Consider Figure 3. The Rule Family on the left consists of fact types with domain values of “yes” and “no,” fact type names that include ”?” and fact type names that include the actual values being tested, in this case “650,” “unstable,” and “high”. How easy is it to understand this Rule Family at quick glance? The Rule Family on the right has clearer fact type names (i.e., nouns, not questions) and they do not include the values being tested. The semantics of this Rule Family are easy to grasp at quick glance as its values being tested are more visible within the Rule Family cells. Also, to add logic that checks for another Person Credit Score value, the Rule Family on the left requires a new column which is a structural change. The Rule Family on the right requires only additional rows, which leaves the decision model structure intact.

 Other examples of meaningful domain values are {eligible, ineligible} for fact types about eligibility, {valid, invalid} for fact types about validity, and {compliant, noncompliant} for fact types about compliance.

Domain values also play a role in validating decision models against TDM principles. For example, TDM principles include checks for completeness (or overlap) of logic in a Rule Family and these are determined based on the fact types domain values. For example, a Rule Family including a fact type of Person Credit Rating with business data type of code, with domain values of {A,B,C,D} must cover all four values one way. Otherwise, there are gaps in the logic.

Figure 3: Selecting Meaningful Business Domain Values

 Solution: The methodology and software (if using) must allow business-specific domain values for fact types.

Business capability #8: Total Fact Type Agility
The eighth business capability is an exceptional one – total agility. The business community wants to change anything and everything about a fact type at any time during the decision modeling process. They want an environment in which nothing is cast in stone while creating decision models, validating them against TDM principles, and even executing test cases against them. It is through those activities (creating, validating, and testing) that the business community optimizes fact types and Rule Families until satisfied with them. At that point, the business glossary is finalized and approved as are the decision models. This complete agility is necessary for the business community to get the logic right before turning it over for deployment.

 Solution: Practice (and software if using) must allow for manipulation of decision models in iterative fashion, allowing for updates along the way.

What is the Role of IT with the Glossary?
The TDM Glossary actually has two parts to it. The eight business characteristics above describe the business glossary for decision modelers and business SMEs. The other part of the TDM glossary is the technical part. It is in the technical part that IT correlates each business fact type to its data representations. There are three advantages to the separation of business and technology parts of the glossary.

The first advantage is that, in the technical part, each business fact type can be correlated to one or more data stores. This means the same decision model can execute against different data stores.

The second advantage is that the technical representations of the data can change. For example, IT may move it from one technology or design to another, but the corresponding decision models need not change.

The third advantage is that correlation of the business fact types to technology representations need not happen until after the specification, validation, and testing of the logic.

Of course, data-centric models can be useful during decision modeling. Sometimes they are necessary to fully understand the fact types. However, you may not need such a model to cover the entire scope of a decision model project up front. Sometimes, people find it useful to create a model for one Rule Family or one decision model, because these involve only a small well-scoped model snippet.

Wrap Up
While the TDM business glossary is one of the most important TDM features, it is often the least celebrated. Yet, it is the TDM business glossary that guarantees that business people can populate their own decision models in their own language, without any knowledge of technology considerations. It is the business glossary that puts the business firmly in control of its decision logic. In summary, the TDM business glossary is the home for naming conventions, data types, and domain values that are meaningful to, and defined by, the business audience. Best of all is that resulting decision models are exactly as the business community wants and in the business’s own terminology

But the TDM business glossary serves yet another important function. It is also the seamless gateway between the business community and the technical community, closing the gap. In the end, the TDM business glossary is the best-kept secret of The Decision Model. Nothing about it is backwards.

Author: Barbara von Halle of Knowledge Partners International, LLC (KPI)

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. It is expected that TDM will evolve over time with respect to its notation, syntax, and principles to support more complicated logic requirements.

2. Not covered in-depth in this article is the concept of TDM community. A community can be as small as a single project or as large as a whole business unit and even larger to encompass an entire enterprise and its partners and customers. A community’s business glossary is the means for sharing fact types.

3. Or role

4. Business domains are discussed below.

5. TDM supports a set of business-friendly operators