The Decision Model: Breaking Barriers in Real-World Projects

The number of successes with The Decision Model is escalating. Organizations are using The Decision Model to solve a range of business challenges and opportunities including some we did not expect. Therefore, this month we summarize three real world projects to illustrate how organizations are using decision models and how quickly project teams are delivering them.

It is important to remember that organizations classify most decision models as proprietary because they contribute to organizational excellence, differentiation and risk management. For this reason, the project summaries do not disclose the industry or organization for which the decision models were created. Nor do they reveal actual process models or decision models. The value of these summaries is that the characteristics of each project are common across all industries. You will learn about each project the following: (1) the business motivations justifying a decision model, (2) the numbers and sizes of actual decision model deliverables, (3) unique challenges, (4) elapsed time to delivery, (5) measurement of business impact, and (6) lessons learned.

The first two projects involve eligibility and compliance decision models.

Eligibility and Compliance Decisions are Everywhere
Eligibility and compliance decisions are prevalent in all industries and represent the majority of most organizations' decisions. They are a perfect fit for decision models. Eligibility is the state of being qualified or entitled to something while compliance is the state of adhering to a standard. Below, we use the words eligibility and compliance interchangeably as they are quite similar. For example, if a claim is deemed not compliant with the subscriber’s health care plan, the claim is not eligible for payment.

Industry Examples
The insurance industry makes eligibility decisions hundreds, if not thousands, of times a day to determine whether a claim is eligible for payment. Each individual claim may have a low economic impact on the insurer, but the huge volume of claims means that these eligibility decisions have a high economic impact on the insurer.

An insurer makes eligibility decisions to determine whether the dependent of subscriber is eligible for membership in the subscriber's plan usually based on the dependent’s relationship to the plan subscriber, dependent,s age, whether the dependent is disabled and other conditions.

The academic industry makes eligibility decisions to determine whether to accept a student into the institution and to determine whether a student qualifies for financial aid. Different conditions may apply to different kinds of financial aid programs - some conditions for loan eligibility, some for scholarship eligibility, and others for participation in work-study programs.

The financial industry makes eligibility decisions to determine if a customer qualifies for a specific kind of loan and with specific terms. When the monetary amount of loans and volume are high, these decisions stand behind huge amounts of borrowed money.

The logic of eligibility and compliance can be quite complex, but sometimes is simple. We begin with the characteristics of a simple eligibility decision before looking at a real world project that is more complex.

A Simple Eligibility Decision
A simple eligibility or compliance decision is one whose logic fits within a decision model containing only one Rule Family[1]. as Figure 1 illustrates. The conclusion fact type is the kind of eligibility - in this case, a dependent's eligibility to enroll in a subscriber's plan. This decision has recently undergone regulatory change.

Figure 1 shows three condition fact types leading to the conclusion: dependent relationship to subscriber, dependent age, and dependent disability status.

Table 1 illustrates a partially populated Rule Family table for this decision. There are two Rule Patterns. The "_" indicates that the Rule Family is not yet completely populated because it must consider other kinds of dependent relationships to subscriber.

Table 1: Simple Eligibility Decision - One Rule Family

Project #1: A Medium Complexity Eligibility Decision
In most cases, eligibility or compliance logic is too complex to fit into a single Rule Family. If the logic is of medium complexity, it fits into a set of dependent Rule Families, some related to others. A fictitious example from the Mortgage Industry is in Figure 2 consisting of seven Rule Families leading to the Credit Compliance conclusion.

Project #1 is a real world example of a medium eligibility decision.

Description: The purpose of the project was to specify the logic for one eligibility decision. The logic existed in policy documents and program code.

Motivations: The organization wanted to represent the logic in a way that business people could understand it. The organization also wanted to decrease the time it takes to analyze and automate changes in the logic.

Deliverables: The first deliverable was a preliminary decision model diagram similar to that in Figure 2, followed by populated Rule Family tables and a glossary. The final decision model consisted of 12 Rule Families and 24 fact types. A customized view of that decision model consisted of 7 Rule Families.

Challenges: The first (and common) challenge was that the project team had no experience with decision modeling. The project began with training and was led by an experienced decision modeler. A second challenge was that the policy documents provided only half the story, logic only for "ineligible" conditions. The team constructed the remaining combinations of logic and business people validated that each combination represented an "eligible" conclusion. A third challenge was that some of the data for the customized view was not available, so that the customized decision model view was not deployable until the organization obtained the data.

Time to Delivery: The team completed the first decision model in 38 hours and the customized view in five hours.

Business Impact: Business people immediately were active in specifying the business logic and analyzing it because they could see and understand it. The decision model decreased the time for making changes and putting them into production. The business people continue to play a key role in guiding these changes.

Lessons Learned: The team revealed 3 lessons from this experience. First, the glossary is critical to productivity. Second, creating decision model views for customized situations can be fast. Third, populating Rule Families according to normalization principles takes discipline but is well worth it.

Project #2: Highly Complex Eligibility Decision
In the most complex eligibility decisions, each aspect of eligibility becomes a whole decision model by itself. Specifically, each aspect stands alone, unrelated to other aspects of the eligibility decision. A task box in the process model contains the entire group of decision models needed for the eligibility decision. See Figure 3.[2] . As a fictitious example from the Financial Industry, there are four decision models, each for a different aspect of customer credit eligibility but unrelated to each other.

Project #2 is a real world example of a complex eligibility decision.

Description: The purpose of the project was to represent the business logic for a complex eligibility decision. The documentation existed in two places - hundreds of pages of policy documents in legal jargon and program code. The program code contained only a subset of the policies in the legal documents. The life cycle for making policy changes and automating them was laborious and time-consuming, interfering with business agility in a rapidly changing market.

Motivation:The organization needed to perform more complex, precise analysis against additional data elements to improve the eligibility decision. The organization also wanted to enable better agility in managing changes.

Deliverables: The project began with a short pilot to validate the usage of decision models. The pilot produced one high-level process model, a sub-process model with an anchor for the eligibility decision, 3 decision models and a plan to move forward. After the successful pilot, the project team produced 12 decision models for all aspects of eligibility, resulting in 33 Rule Families. Many of the 12 decision models evolved into six customized views for almost 90 Rule Families. From this success, the project team produced 40 additional decision models and 700 Rule Families. The project team also delivered a glossary of 1400 fact types, 750 for persistently stored data.

Most interesting was that the glossary also contained 650 fact types representing those whose values are the conclusions in dependent Rule Families. From a business perspective, these fact types are very important because they are the glue that holds a decision model together - they are the means by which the decision model reaches a conclusion. Without a decision model glossary, no one in the organization names, defines, and assigns domain values to these kinds of fact types because they are not persistently stored, they are transient. Yet, the decisions depend on them.

The IT function automated the decision models in a BRMS.

Challenges: Again, the first challenge was that the project team had never created decision models. They began with training and continued under the leadership of a seasoned decision modeler. A second challenge was that many of the policy documents described only the conditions leading to an "eligible" conclusion. The project team constructed the remaining combinations of logic and validated them.

The third challenge was that some condition fact types were overloaded, meaning they held data for more than one kind of information. The team dissected these into atomic fact types.

A fourth challenge was the discovery of logic errors in the policy documents. Business experts made corrections which were recast into third normal form Rule Family tables.

A fifth and interesting discovery was that there were conditions for which the organization had no data. For the related decision models, the team produced two views: one for available data and another which included the missing data.

Time to Delivery: The elapsed time for creation and analysis of the first set of decision models was 3 months and for the second set another 3 months.

Business Impact: The decision models provided the basis for conducting more complex analysis on additional data. While the original change cycle required 3 weeks to make 60 changes in the automated systems, the new change cycle requires only 2 weeks for more than 100 changes.

An unanticipated business impact was the ability for business experts to see visually the difference in decision-making between decision models based only on available data and those with all needed data. This visualization solidified the need to obtain more data to improve the quality of corresponding decisions.

Lessons Learned: Discussions with team members revealed three lessons. First, grouping rules and logic into decisions and Rule Families is intuitive to business people. Second, decision model principles and normalization lead to consistency and repeatability among business analysts. Third, the decomposition from decisions to decision models to Rule Families allows business people to focus on rules and logic most relevant to policy changes.

Project #3: Process Performance Bottleneck
This project is not about eligibility but about simplification of a failing process.

Description: The organization was operating with a failed process, which already produced a backup of transactions worth billions of dollars [3].

Motivations: The organization needed to simplify the process, reduce processing time, and handle increasing transaction volumes in the required timeframe. They also wanted error messages explaining how to fix all input errors.

Deliverables: Re-engineering the process led to a new decision-aware process surrounding five business decisions. The five decision models consisted of 95 Rule Families, along with 2200 test cases. The IT department implemented the decision models in a homegrown Java rules engine. Plans are to move to a commercial business rule management system (BRMS) as a service for execution.

Challenges: One challenge was the uncertainty that decision models would solve the bottleneck problem. A second challenge was that the team was inexperienced in decision models, but they participated in a very quick overview. The third challenge was that the decision models were to address all dimensions of data quality logic.

Time to Delivery: The time to deliver a working solution was unexpectedly minimal. The team produced the process model and decision models with populated Rule Families in five weeks. The IT department programmed the decision models in an additional five weeks. The team completed the test cases in two weeks.

True Business Impact: The time to run 200 transactions through the new process (those with and without errors) decreased from 30-90 hours to 3 minutes 30 seconds. New releases of the logic require only 30 minutes to 2 hours to test. The business logic remains well understood and updated without changing the process and vice versa. Business people change business logic, test it, and have it in production in only 2 days.

Lessons Learned: This experience led to four lessons learned. First, decision models drastically simplified the process. Second, decision models also drastically reduced testing efforts. Third, executives are able very quickly to comprehend decision models and understand the business logic in them. Fifth, most important of all, decision models may be a surprise solution to other problems.

Summary and Wrap Up
Table 2 contains a summary of the above real-world projects.

Table 2: Summary of Decision Complexity, Size, and Development Times

Breaking barriers is good, especially when the barriers are productivity improvements, solutions to difficult business challenges, and measurable business impact.

The productivity gains related to creating decision-aware processes and decision models exceed expectations on every project, making decision modeling the fastest approach we (and others) have ever experienced. Specific productivity gains occur in the following areas:

• Creation of initial process and decision model deliverables

• Analysis of decision logic against decision model principles

• Generation of test cases and testing entire decision models, reducing testing efforts by 50% [4]

• Automation of decision models and straight-through processing

Experience continues to prove that the decision model is appropriate for many situations it was never meant to address. It has been the preferred solution, sometimes the only solution, to the following kinds of business challenges:

• Pure business decision logic

• Data quality logic [5]

• Data transformation logic

• Complicated interpolation and calculation logic

• Process performance bottlenecks

True business impact is the actual measurable difference in business performance because of decision models. This is where each organization distinguishes itself. Sample impacts on business due to decision models includes:

• Agility of policy changes from months to weeks to days with minimal IT intervention

• Discovery of policy errors prior to testing and long before programming,

• Simplification of business processes

• Significant improvement in data quality.

In summary, each decision model delivers business impact, breaking barriers in its own unique measurable way. However, there is a bigger vision.

The Bigger Vision
Decision models deliver business logic in visual tangible form back to the business people, from where it started. They can change it, analyze it, simulate it, and determine when it is ready for production, long before programming begins and with confidence that it is correct and complete. This capability is game changing in terms of organizational governance and agility.

This is the first step in leading an organization out of the age of business rule management into that of business decision management and decision modeling. We believe there are many more barriers waiting to be broken. That's because experience with The Decision Model has only just begun, but is growing fast.

[As always, we invite readers to join the public group on LinkedIN called "The Decision Model" to hear what others are doing with The Decision Model and to ask questions. There is a potential decision model normalization violation in Figure 2. We will discuss it in the LinkedIN group].

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

Larry Goldberg is Managing Partner of Knowledge Partners International, LLC (KPI), has over thirty years of experience in building technology based companies on three continents, and in which the focus was rules-based technologies and applications. Commercial applications in which he played a primary architectural role include such diverse domains as healthcare, supply chain, and property & casualty insurance.

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. 

¹The one Rule Family is also known as the Decision Rule Family because it is the Rule Family leading directly to the conclusion of the decision.

² If there is a required sequence among the decision models, separate task boxes will depict the required execution flow.

³See "Better, Faster, Cheaper Part II-The Decision Model Meets Data Quality Head On" by David Pedersen

⁴See "Revolutionizing the Testing Process for Business Logic" by Barbara von Halle and Larry Goldberg at http://www.compaid.com/caiinternet/ezine/DecisionModel3.pdf

⁵ Again, see Pedersen