Welcome to the first installment of the Decision Model column. We begin with a quote from last month’s
interview:
What rules were in place in certain transactions that were supposed to manage risk? Who was managing those rules? Most importantly, how do we ensure better management of important decision logic? The
Decision Model is part of the answer.
The Decision Model is a new development that brings rigor and sense to the management of business decisions. It is the first model of business rules and logic, complete with a well-defined structure
and three forms of normalization. Some say the groundbreaking work behind it can “change the game” between business managers and IT professionals and deliver a foundation for a new generation of
software. Early adopters and reviewers have stated that our book (The Decision Model: A Business Logic Framework Linking Business and Technology) has the
potential to emerge as a classic reference.
If so, this is exciting, but at least three questions probably come to mind. What exactly is the Decision Model? Why should you, as a data management professional, care about it? And, of immediate
curiosity, why is there now a regular column about it in TDAN?
Question #1: What Exactly is the Decision Model?
As TDAN readers, you are very familiar with a logical data model as a technology-independent model. Therefore, you would not find it difficult to consider that the Decision Model is much like a
data model but somehow different.
The most obvious distinction between these models is that each embodies a different resource. To state the obvious, a data model models data. It represents
data, which the business wants or needs to manage. Such data includes detailed facts, such as, a person’s first name, last name and birth date. Specifically, a data model represents data in a
way that reflects only the underlying nature of the data itself, based on technology-independent principles like data normalization.
On the other hand, a Decision Model models business logic (or the logic intended by business rule statements). So, it represents judgments (not data), which the business wants or needs to manage. Such judgments include the decision to pay a claim and how much to pay, for example. The judgments
include detailed logic, such as evaluating a diagnosis code, treatment code, provider code, and the service cost to arrive at a payment conclusion. So, specifically, a Decision Model represents
judgments in a way that reflects the underlying nature of the judgments themselves, also based on (new) technology-independent principles like decision model normalization.
Our book explains the decision model in the following way.
business is interested in storing business logic. Business logic includes testing detailed facts, such as a Person’s Annual Income and Person’s Credit Rating, and coming to conclusions
about other facts, such as a Person’s Likelihood of Defaulting on a Loan. These facts are nothing more than pieces of data. A business may have no control over some pieces of data, such as a
Person’s Credit Rating. Yet, using business logic, a business defines prescriptions for exactly how it judges a person having a specific credit rating value.” (von Halle and Goldberg
2009)
There are many similarities between a data model and a decision model. The most important similarity is that “each model represents a new way of thinking because each focuses on the
inherent properties of the modeled asset (i.e., data and business logic).” (von Halle and Goldberg 2009) This is extremely important because each having its own specific model means that we can
separate each asset into a manageable resource
On the other hand, the differences between these models are even more intriguing because “the two modeled assets, data and business logic, are not the
same asset. They are fundamentally different, serving different purposes and having different characteristics. It stands to reason that their models exhibit different native structures and different
guiding principles.” (von Halle and Goldberg 2009)
Question #2: Why Should You, as a Data Management Professional, Care About the Decision Model?
As fascinating as the decision model sounds, why would it be of particular interest to data management professionals? The answer lies in our experience to date.
After several years of delivering decision models in practice, we came to a startling and humbling realization. Its evolution and adoption is paralleling that of the data management industry!
Remember those early days – trying to explain a new idea, learning new theory, applying it in practice and today, enjoying the maturity of data management as a respected discipline? So far,
this seems to be the evolutionary path of the decision model as a natural next step.
How so? Our book summarizes the evolution of data management for comparison.
What Has History Taught Us About Data?
Once upon a time, early data practitioners separated data from process by creating lists of nicely named and fully defined data elements. Despite good intentions, this was insufficient for managing
data effectively. Why?
hierarchical or network data structures. There were also products based on inverted file structures. Each technology was proprietary, favored specific ways of accessing the data, and was
incompatible with others.
The goal of database designs was to maximize the target technology (e.g., using pointers, hashing algorithms, and indexing) and minimize storage space (e.g., introducing shorter “codes”
to represent the real data). However, eventually, the need became evident for a logical data organization. This is one based only on the meaning of the data, independent of and transcending technologies. Such a logical data organization would unify the various database design approaches across incompatible
technologies.
In the 1970s and 1980s, there were several important inventors and inventions addressing a way to unify the then incompatible ways of organizing computer-stored data. While these innovations were
important, the Relational Model was distinct in a very important way. It united the database field with a particular kind of science. The Relational Model and related technology made people rethink
the way to structure, organize, access, design, protect, value, and leverage data as a business asset. The Relational Model’s brilliance, simplicity, and far-reaching implications eventually
took hold. Not only was a new generation of software born, but a whole new age emerged, called the Information Age.” (von Halle and Goldberg 2009)
This brings us to the current state of managing business rules and business logic.
What Has Data Management History Taught Us About Business Rules and Logic?
solutions play a similar role, as did the proprietary data base management systems of the 1970s. That is, the products themselves are excellent and mature, but proprietary. As a result, design
approaches vary and are highly influenced by proprietary target technology. There is no universal technology-independent model that serves as a starting point regardless of language and target
technology. Learning from the data separation, large-scale success is more likely to come with the introduction and adoption of such a model.” (von Halle and Goldberg 2009)
Can We Leverage Lessons From the Past?
It therefore follows that we base the decision model only on the inherent nature of business logic and nothing else. Much like a data model, its structure is independent of how and where it is
executed, whether automated or not. Its rigor is defined through a set of principles addressing structure, declarative nature and integrity.
If this sounds intriguing, the next section should be even more so.
A Quick Informal Refresher: How Do We Represent Data with Rigor?
Consider data represented in Table 1.
Table 1: Two Tables of Data
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the
Publisher.
Five familiar characteristics emerge: two-dimensional structures, column headings, rows, and the notions of primary and foreign keys. Specifically, we represent data as attribute types, attribute
values, primary keys for uniqueness, and foreign keys for relating one entity to another. So, what does this have to do with the decision model?
How, Then, Do We Present Business Logic (or Business Rules) with Rigor?
The question to ask is whether we can represent business logic (or business rules) based on its own inherent nature and nothing else. For the answer, consider Table 2.
Table 2: Two Rule Families of Business Logic
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the
Publisher.
Surprisingly, the same five characteristics emerge, but with fundamental differences.
-
Two-dimensional structures: The business logic is populated into two-dimensional structures depicted as columns and rows. In the Decision Model, we refer to
these as Rule Families. -
Column headings: The column headings represent the names of pieces of information. TDAN readers know these as attribute types, but we refer to them as fact
types in the Decision Model because business logic derives conclusions from facts. The column headings represent fact types used in the business rule or logic statements. Some fact types are
conditions we test while one is a conclusion we reach.For example, the first Rule Family tests values of a Person’s Employment History, Mortgage Situation, Miscellaneous Loans Assessment, and Outside Credit Rating and concludes a value for the
Person’s Likelihood of Defaulting on a Loan. It is as easy as that.An important principle in the Decision Model is that a Rule Family contains only one conclusion fact type. In this way, atomic logic leading to a conclusion has only one home in a Decision Model.
There is no room for guessing or for creative alternatives. -
Rows: The rows represent atomic instances of business logic (or atomic business rules) consisting of condition and conclusion expressions conforming to the
headings. Therefore, the way we populate a cell in each row is to specify an operator (e.g., is) and an operand (e.g., High) conforming to the heading. -
Primary keys: Each Rule Family has a primary key uniquely identifying instances in the Rule Family. In fact, the primary key is simply the combination of its
condition fact types (ck). This makes total sense, if you think about it. For example, it would be inappropriate for the top Rule Family to have another row testing for Person’s Employment
History of Poor, Mortgage Situation of Poor, Miscellaneous Loans Assessment of Poor and Outside Credit Rating of Low to conclude that the Likelihood of Defaulting on a Loan is anything but
high. -
Foreign keys: A Rule Family may also have a foreign key. In the second Rule Family, the condition fact type labeled Person’s Employment History in the
top table is a foreign key. The values in this column that match the values in the Person’s Employment History in the bottom Rule Family indicate a logical connection or relationship
between these two Rule Families. This is referred to as an inferential key (ik). It simply means that we do not obtain the value for this fact type from raw input (from a web page or database,
for example). Instead, we obtain its value from other business logic. Hence, there is a relationship between two Rule Families and so emerges a naturally formed web of business logic.
What About Normal Form?
While the first three normal forms are similar in the two kinds of models, they are necessarily different. First normal in both is about atomicity. Second normal form in both is about functional
dependencies involving a partial primary key. Finally, third normal form in both is about transitive dependencies among primary key constituents.
As a data management professional, you probably understand that casting business logic in a model based on this kind of rigor, results in a predictable, correct representation. It is far superior to
simply creating lists of business rules in much the same way as a data model is superior to a list of data elements. The Decision Model does not force a particular grammar or technology for
automating it just as a data model does not imply a particular naming convention or technology.
Most importantly, every decision modeler will model the same business logic in a similar way just as data modelers model the same data in similar ways. In the Decision Model, it is difficult to make
a mistake and easy to find one, long before automation. Business people can also find the mistakes!
What Else to Know?
Figures 1 and 2 are instance tables with populated rows. But, data model diagrams and Decision Model diagrams do not reveal the detailed rows. They simply depict the normalized structure and
relationships. So, next month, we explore the Decision Model from bottom up and top down.
Question #3: Why is There Now a Regular Column about the Decision Model in TDAN.com?
This column is for data management professionals because of the similarities between managing data models (and databases) and Decision Models (and rule bases). This is evident in an important
quote by Ken Orr, Chief Scientist of Ken Orr Institute:
management.” (von Halle and Goldberg 2009)
The Decision Model has already achieved Orr’s vision. It truly makes business rules as independent as database management and, if history is any indication, it has an interesting future.
Data management professionals are likely to find the creation of Decision Models appealing and very natural.
Our goal for this column is to introduce and advance, the Decision Model and its adoption. We welcome questions, experience and suggestions for improving it.
We believe the Decision Model is exciting, and we are very pleased to be sharing it through a column in TDAN.com.
The Decision Model: A Business Logic Framework Linking Business and Technology can be ordered from www.TheDecisionModel.com.
