The Decision Model Column – “MIT Industry Symposium on Information Quality, The Decision Model, and an IQ Framework”

Conference Overview

The Massachusetts Institute of Technology (MIT) Information Quality Industry symposium (IQIS) is an annual premier event. It fosters leading edge discussions to create synergy among academic, business, and government leaders.

This year’s event took place July 14-16 at the MIT campus in Cambridge, MA. Keynote speakers were Mr. Michael Krieger (Deputy CIO, Office of the Army CIO.G6) and Mr. John Bottega (Vice President and Chief Data Officer for the Federal Reserve Bank of New York). High-level management representatives from Global 1000 organizations attended the conference. The size and importance of attending organizations underscores the magnitude and concern about information quality across all industries.

Of particular interest is that some attendees were of the opinion that a major cause of the current economic crisis is Information Quality (IQ). In Session 3d, The Decision Model surfaced as a solution for part of the Information Quality challenge. Interest in The Decision Model for IQ ran high and experience demonstrates its value. With this in mind, below we summarize the emerging role of The Decision Model in an IQ Framework.

The Decision Model Presentation at IQIS

Larry Goldberg was an invited speaker on Decision Modeling and Business Rules in Session 3d chaired by Charles McKinney of Freddie Mac. Fred Lyne of Freddie Mac also spoke in Section 3d about managing business rules and information quality across an extended enterprise.

Larry introduced The Decision Model in a presentation titled “The Decision Model: a Business Logic Framework Linking Business and Technology.” He covered the following:

• The Problem of Logic in Our Business systems
• Comparison of the Relational Model and The Decision Model
• Introduction to The Decision Model
• Profound Impact (of Decisions) on Business
• The Decision Model and Information Quality.

In his introduction to The Decision Model, Larry presented material similar to that published in TDAN as The Decision Model Bottom Up (http://www.tdan.com/view-articles/11671) and Step by Step Decision Modeling for Data Professionals (http://www.tdan.com/view-articles/12800).

Attending the session were representatives from major American and foreign banks, insurance companies, government groups and other Global 1000 organizations.

Original Intent of The Decision Model for IQ

In the spirit of total honesty, we did not intend for The Decision Model to address information quality issues. In fact, our book state, “Business logic best targeted for a Decision Model is of a purely business nature, involves evaluation of facts leading to a conclusion, represents one business decision, is not easily represented by another means, and is subject to change.” It goes on to say, “Logic of a purely business nature does not include logic for determining data quality, data transformations, workflow routing, or driving interface sequences.”

But, we were so wrong!

In reality, organizations are using The Decision Model in various kinds of data-centric endeavors as a new technique that fills a gap. Even more interesting, Information Quality is emerging, as not only a top priority within organizations, but also The Decision Model turns out to be a unique solution for part of the IQ challenge.

The Role of The Decision Model in an IQ Framework

Typically, the primary goal of information quality is to ensure that information is trustworthy for business purposes. In Decision Model-driven enterprises today, an important and specific business purpose for trustworthy information is to serve as the basis for sound (and agile) business decisions.

Information is trustworthy when it successfully passes logic that measures Information Quality. Information Quality is measured in various dimensions, such as completeness, consistency, reasonableness, and accuracy. Each dimension requires its own kind of logic.

An IQ Framework is a means for managing these different kinds of IQ logic so that it is:

• Accessible and understandable by interested yet authorized people, with special emphasis on data and decision stewards
• Easily changed in a timely manner over time as needed
• Independently represented yet traced to its implementation in automated systems.

Synergy between Decision Logic and IQ Logic

There are at least two different kinds of logic relevant to this month’s column: business (decision) logic and IQ logic. They are not the same, but similar and related to each other as explained below.

A business decision is a conclusion that the business arrives at through business logic and which is important enough for the business to manage carefully. A Decision Model View best represents the logic behind a business decision because The Decision Model principles render logic in its atomic and least redundant form, maximizing its integrity. The conclusions reached by a Decision Model are only as trustworthy as the quality of the business logic within The Decision Model itself and the quality of the data referenced or created by The Decision Model. It is important that business (decision) logic and IQ logic be visible and agile. Visibility of IQ logic creates business confidence in the quality of enterprise information.

Therefore, the idea is to manage IQ logic in much the same way as business (decision) logic, specifically:

• Create and manage both for the purpose of achieving business objectives
• Monitor business metrics to assess the impact on business performance of both and
• Adjust both to remain aligned with changing business motivations.

The IQ Framework with The Decision Model

Figure 1 contains a portion of a simplified IQ Framework in which IQ logic becomes highly visible and manageable. A more complete IQ Framework would contain all relevant IQ dimensions, corresponding repositories for each dimension, authoritative sources for the IQ logic, and stewards.

Figure 1: Partial Information Quality Framework Using The Decision Model

The first column contains IQ dimensions; the second defines each dimension, indicating how Decision Model Views apply.

Put simply, a Decision Model View is like looking at The Decision Model through a filter, just as one may look at a complex database through the filter of an SQL View to focus on just the data that is of interest at a given time. We create, manage, analyze and implement Decision Models as Views of the underlying Enterprise Decision Model. In fact, best practice is not to manage Decision Models, but their Views. This is similar to the concept of never permitting application developers to directly address tables in RDBMS, but limit their access to Views only. This enables the Data Modeler to completely isolate and make changes to the schema without perturbing applications accessing the data, and the same with Decision Model Views(1).

Just as a business may need different Decision Model Views for specific flavors of business decision logic, so a business may need different Decision Model views for IQ logic based on different business needs or restrictions. For example, IQ logic to test the consistency dimension of an attribute may have one view for most US states. There may be a customized view for states requiring different consistency logic, perhaps due to differences in real estate values, average salaries, employment situations, or other criteria important to the business.

Compliance with the IQ Framework

Compliance with the IQ Framework is determined by testing IQ logic for each dimension at appropriate points in each business process or system. Essentially, the result of IQ logic execution determines whether the process or system stops completely or branches to an appropriate place that handles the resulting IQ.

Using IQ completeness as an example, a business process may have two branches depending on which data is available. One branch may be for the situation where all relevant data is available. The other branch may be for the situation where only a subset is available. Thus, the success or failure of the IQ logic affects the flow of the business process or system. Specification of IQ logic in Decision Model Views allows for all kinds of variations in IQ testing. It also enables a single business process or system flow to accommodate all exceptions through IQ logic views.

Let us look at some simple examples.

Completeness LogicFigure 1 defines completeness as the determination that all required fact types are present, presumably prior to the execution of a task or Decision Model needing those fact types. There may be fact types that are only sometimes required, called conditional completeness. According to the IQ Framework, Decision Model Views are the best place to document the logic by which a fact value is sometimes required or irrelevant (conditional completeness).

As an example, consider fact types needed to make a decision about a loan applicant’s income. Assume the loaning institution is interested in basing this decision on the applicant’s annual salary and supplemental income. Suppose, further, that the loaning institution is willing to make this decision based only on the applicant’s annual salary if the documentation about that salary is acceptable and reliable. However, if that is not the case, the institution wants to base the decision on both the applicant’s annual salary and supplemental income.

This situation requires logic to determine the circumstances under which the applicant’s supplement income amount is required. The conclusion, whether the applicant’s supplement income is required, determines whether its population is complete enough to proceed. Assume the loaning institution decides that the criteria for determining this include the source for the applicant’s annual salary documentation and the effective date of the salary. Specifically, the source must be reliable and the effective date recent. Further, these require logic to determine what it means to be reliable and recent (as discussed below).

Figure 2 contains a sample Decision Model View for this. The octagon represents the decision. The top Rule Family contains the conclusion fact type above the solid line. Below the conclusion fact type appears one of the criteria, Applicant Annual Salary Amount Documentation. It is between the solid line and dotted line because its values are, themselves, determined by other logic. The other criterion, Applicant Annual Salary Amount, appears below the dotted line because it is simply a piece of persistently stored data. Figure 2 also shows a supporting Rule Family whose criteria are two persistent pieces of data (Applicant Annual Salary Amount Source, and Applicant Annual salary Amount Effective Date).

Figure 2: Decision Model (View) Diagram

The corresponding Rule Family table for the top Rule Family in Figure 2 is in Table 1. The first row indicates that if the Applicant’s Annual Salary Amount Source is acceptable, the institution does not care whether the Applicant’s Supplementary Income Amount is populated or not. Either way, it is complete. However, if the Applicant’s Annual Salary Amount Source is not acceptable, the Applicant’s Supplementary Income Amount is only complete if it is populated.

Table 1: Rule Family for Decision Model (View) Diagram

Over time, the institution can update (and implement) both the Decision Model View diagram and corresponding Rule Families with minimal changes to corresponding processes or decisions relying on the changed logic(2).

Domain Value Logic

There may be circumstances in which the domain values of a fact type are restricted based on certain business or market circumstances. If so, a Decision Model View for IQ domain values is the appropriate place to specify conditions that are to restrict the domain values.

Consistency, Reasonableness, and Accuracy Logic

The consistency dimension requires logic to test whether fact values make business sense in the context of related fact types or values. The reasonableness dimension requires logic to test whether a fact type value is within an acceptable difference from expected values.

The accuracy dimension requires logic to compare a fact value from one source to that from another source. If the first fact value matches the one from the other source, it is likely to be accurate. If not, the accuracy may be in question. There are situations where the match must be exact and other situations where the match need only be within a predetermined percentage. Consider the three common sources for credit score and that each source produces a different score. If they are within a predetermined percentage, a business may consider them accurate – that is, close enough. Otherwise, the business may consider them unreliable or in error.

Consistency, reasonableness, and accuracy logic do not usually originate from business policies, but from analysis of internal and external data, insight from vendors, fraud detection programs, analytics, and organizational experience over time. Some subsets of this logic change slowly while others change more rapidly. Regardless, this logic improves the quality of decisions when the information in the decision passes up-to-date IQ criteria.

Because these three dimensions involve conditions leading to a conclusion, the Decision Model View is an appropriate vehicle for managing these specifications.

Wrap Up

Decision Model Views bring unanticipated benefits to IQ programs because they fill a missing gap. The missing gap is a rigorous, normalized model for representing only logic by itself, which now extends to IQ logic. The benefits of using Decision Model Views for logic-rich IQ dimensions are:

• The IQ logic is visible and tangible, more easily understood than textual statements
• Variations in IQ logic based on business needs (e.g., customized for favorite customers, geographical locations, regulatory compliance) are easily handled as views
• IQ logic can be housed in a Decision Model View based on an industry-standard glossary or dictionary, but contain logic based on organizational policies regarding quality of the information
• Individual Rule Patterns within a Rule Family in an IQ Decision Model View may be able to execute to conclusion with a subset of available data
• IQ error messages can be associated with individual Rule Family rows
• IQ conclusions can be given probabilities, such as 60% certainty that a fact type value is reasonable or consistent or accurate
• All IQ logic is managed in a form that is technology-independent, regardless of implementation technology.

In summary, if you are working on an IQ endeavor, now is the time to consider The Decision Model as a missing piece of the puzzle. To do so, think about the following:

1. Decide on the set of IQ dimensions that are most appropriate and important to your organization’s needs (if doing Decision Models, consider their need for IQ)
2. Identify those dimensions whose specifications are based on logic (i.e., conditions leading to IQ conclusions)
3. Create Decision Model Views for logic-rich IQ dimensions.
4. For each project, identify where in a business process or system those IQ dimensions need to be tested (Pay special attention to IQ tests needed for decision tasks and The Decision Models within a business process whose quality depends on those dimensions)
5. Trace IQ specifications to their implementation for maintenance over time.

If you follow these steps, armed with a glossary (or enterprise dictionary, ontology, model) and a set of well-constructed IQ Decision Model Views, you will have the infrastructure for a manageable, visible and agile IQ program.