The Decision Model June 2010

(This article assumes knowledge of the Decision Model. If you are not already familiar with the theory of the Decision Model, you can download a brief primer from www.TheDecisionModel.com.)

Portions of this column are drawn from the book, The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis, LLC. This article consists, in part, of abstracts from the book; directly quoted passages, diagrams, and tables are cited, and are copyright © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.

No one doubts that delivering high quality data to an enterprise is valuable, but in this article, we look beyond that. Michael Fuller, Decision Modeling Practice Manager with Starpoint Controls states, “The business runs mostly on non-persistent data.” If this is true, what is the nature of it? How is it running the business? How do we capture it? In addition, what is the role of the data professional in managing it?

The nature of this data is that is created on the fly dynamically, whenever the business comes to a conclusion. It is running the business because the conclusions guide transactions and business processes and determine the outcome, success or failure. We capture dynamic data with a slight change in approach. That is, we instigate innovation in business thinking by discovering and managing this previously ignored data. This approach can make a huge difference in organizational maturity, performance, and perhaps survival. The role of the data professional is to bring good data practices to this dynamic data. If this sounds interesting, consider the approach below.

Re-Thinking Our ApproachThe three prominent characteristics of this approach are a requirements framework, new model of persistent and dynamic data, and visualization. Why these three?

The framework ensures completeness of all requirements including the need for a new model. The new model is the Decision Model that transforms important business thinking (i.e., judgments) into a tangible, rigorous and manageable business (and data-related) asset. In practice, the Decision Model has already advanced the practice of Data Management in business-changing ways explained below. The visualization simulates user scenarios, alleviating the need for abstract specifications and revealing persistent and dynamic data.

Based on experience, this approach not only accelerates productivity and success. It also puts business leadership at the helm of important business judgments behind decision-making.

The approach begins with a framework familiar to most readers.

The FrameworkThe approach adopts the Zachman Framework for Enterprise Architecture1 (ZFW), the foundation for all modern Enterprise Architecture theory. Thus, it likely fits into most – if not all – architectures. It Framework proposes a decomposition of complex systems, processes, or organizations. If you are not familiar with it, this paragraph is a quick review. The ZFW consists of six columns representing the dimensions which are the interrogatories (What, How, Where, Who, When, Why). It consists of six rows representing the views of target audiences (Planner, Owner, Designer, Builder, Sub-contractor, and Functioning Enterprise). Therefore, there are 36 cells. Each contains content unique to the cell, which ought not to appear in any other cell. Therefore, it is a normalized schema of decomposition artifacts because it disallows unnecessary duplication of content among cells. Zachman calls the cell content primitives. Primitives connect to all primitives in the same row.

Using this framework for requirements ensures completeness. Each cell corresponds to a particular audience view and connects to other cells, with appropriate metadata.

To keep it simple, the approach consists of six simple steps.

Step 1: Validate Project ScopeTo get started in Figure 1, begin in row 1, the Planner perspective. Create lists within scope:

• List of information things
• List of business processes 
• List of locations 
• List of organizations 
• List of events/cycles 
• List of business goals, strategies, and business decisions.

If you are unclear about any of these lists, request sponsors to fill in the gaps before proceeding.

Step 2: Confirm Framework DeliverablesUsing the framework, identify the kinds of requirements deliverables for the project by moving into Row 2, the owner audience. For each cell, describe the corresponding deliverable. Suffice it to say, that today most deliverables should be models, each one aimed at a different dimension of the Framework.  Figure 1 contains a list of useful deliverables for business requirements.

Step 3: Identify Models.When possible, favor models over other representations for three reasons.

“First, each model reduces complexity. Second, each model enables independent change of its dimension from other dimensions. Third, it turns out that a model specifically tailored to the characteristics of the modeled dimension best represents each dimension. For example, data is best modeled in diagrams that show the relationship of each data entity to another, where icons represent the data entities and lines represent data relationships. On the other hand, process flow is best modeled in diagrams that represent flow of process tasks, where icons represent the process tasks and lines represent process sequence.” (von Halle and Goldberg, 2010)

Your list of business decisions is a separate dimension – neither data nor process, for example. Therefore, they deserve their own kind of model, tailored to inherent characteristics, and defined with rigor. Business decisions are best modeled in diagrams that show the relationship of each business logic entity to another, where icons represent business logic entities and lines represent inferential relationships.

Further, the Decision Model drives the Data Model, vice versa, and dynamic data emerges.

Step 4: Include Decision Models With Data Models.There are at least five compelling reasons to include the Decision Model with data models.

Reason #1: The business rules of business decisions are the forgotten dimension.

Ken Orr states in our book’s preface, “Indeed, business rules are perhaps the most important, unresolved problem facing business and IT. A great many organizations are not so much the masters of their business rules but prisoners of them.” Business rules represent the one dimension that has not had its own model.

The Decision Model fills this gap as a stand-alone model simply for organizing business rules similar to what the Relational Model does for data. The logic of business rules in a Decision Model (like the data in a data model) is in atomic form, governed by rigorous principles, and compliant with three forms of normalization.
As data professionals, this is very exciting! Further, the Decision Model shares metadata with, and has connection points to, the other models commonly used today. In addition, the Decision Model references data beyond that in our databases and data models.

Reason #2: The Decision Model improves business decision-making.

When business leaders can see their business logic in the natural tangible rigorous structure of a Decision Model, it becomes a magnet for better business decision-making. This has a profound effect not only on requirements and systems, but also on organizational maturity and business performance.

Reason #3: The Decision Model transcends available data.

Practice proves that a Decision Model for important business decisions based on data that already exists in data models and databases can be a costly mistake! Business agility, business-distinction, and risk avoidance often requires Decision Models that rely on data that is unavailable or not yet well understood.

Examples are the decisions needed to process a claim. How many decisions happen during that process today? How well are those decisions being made? How many claims need to be processed by humans? What information is missing for more complete automation? What information would be helpful for making better more consistent decisions?

Other examples are those decisions behind a mortgage application. How many decisions? Which ones are most important? Which ones need improvement today? What information is missing that would sharpen some decisions, reducing risk?

So, the quality of a business decision is only as good as two characteristics: (1) the quality of the business logic within the Decision Model itself and (2) the quality of the data referenced by and created by the Decision Model. The data created by a Decision Model is dynamic data.

Reason #4: The Decision Model is its iterative, agile nature.

We can release pieces of Decision Models, starting with one decision at a time. We can construct a preliminary list of possible conditions needed for a conclusion. We can then investigate related data availability and deliver data definitions. Next, we can fill in the Decision Model details, normalize the Decision Model itself, investigate data availability and quality, and build or extend a data model.

Reason #5: The Decision Model always reveals important pieces of information we have ignored.

A Decision Model comes to many mini-conclusions before it comes to the final one. These mini-conclusions are judgments-in-flight whose data values need not be stored in a database, but are dynamically created. Dynamic data is the glue that ties together the way the business thinks and the quality of how it makes decisions. In this way, dynamic data emerges as an asset of utmost importance to business leaders, perhaps equal or more important than some persistent data.

Let’s look at how this works. Figure 2 is a sample Decision Model. The final conclusion reached by this model is a value for Policy Renewal Method – either automation or underwriter. This conclusion value is dynamic in that it is not stored, simply passed to all processes and systems needing it.

The mini-conclusions are visible in the Decision Model. These are values for the fact types (data elements) named at the top of each icon. These fact types are Policy Tier Within Bounds, Policy Discount, Policy Renewal Override, Insured Major Ownership Change, and Insured Major Location Change. As mini-conclusions, their values result from executing the business logic in the related icon and their values serve as input to connected icons.

Therefore, these dynamic data values, previously ignored, need proper names, business definitions, and domains. If not managed properly, the Decision Model falls apart which means that its conclusions may be risky and the business may suffer.

Risky conclusions result if a Decision Model does not fully cover a domain or if conclusion values are overloaded. Risky conclusions result if a dynamic data value is null which causes inferential relationships to break. We need to manage dynamic data values with discipline equal to that we apply to persistent data.

The Decision Model in Figure 2 also references data from persistent storage: such as Policy Tier, Policy Grade, and Policy Annual Premium. This is how the Decision Model integrates with the Data Model and why it needs assistance from data professionals.

Take this one-step further. Suppose, the Decision Model in Figure 2 references only data that is currently available in databases. However, suppose the business leaders want to create another Decision Model that references some data that is not currently available, but which business leaders believe should be persisted and which will result in better conclusions. The ability to visually compare these two Decision Models can be business changing! That is because the differences become obvious immediately.

Which Decision Model leads to safer conclusions? What is the risk in delivering the Decision Model that lacks important data? In addition, what is the role of data professionals in ensuring that the business builds Decision Models for all of the data needed to navigate safely? Because this is a very important issue, the new approach begins with Decision Models early and iteratively with data models.

Deliver Decision Models Iteratively with Data Models

Start looking for business decisions in Step 1 above, creating a list of them. In Step 4, use the list of business decisions to drive both the Decision Models and Data Models iteratively. Figure 1 depicts the connections of Decision Models to other deliverables with emphasis on the data models.

Step 5: Complete a Visualization.Next comes visualization. Visualization is the simulation of important user scenarios. It enables exhaustive examination of business requirements. It is best to complete the visualization before finishing models because it uncovers new requirements. Visualization takes place in three distinct phases, as illustrated in Figure 3. A product for this is Irise2.

The first phase is Scenario Ideation. Divide the requirements into a set of scenarios generally grouped around a set of logical functions. Explore each set of scenarios through steps all scenarios are complete. In some cases, users may decide that there is no value to creating a high-fidelity simulation, and that an analysis level simulation is sufficient.

During the Scenario Ideation and the Analysis-Level Simulation, participants identify a large number of requirements. A wider group of participants discovers more. Additional business decisions may emerge along with important discussions about the ROI of these decisions and the need for additional persisted data as well as dynamic data. This leads to a more exhaustive discovery of requirements (data, logic) that we may miss using conventional methods. It also leads to higher levels of adoption of the finally delivered system.

Step 6: Present a Holistic Deliverable.Upon completion of the visualization and models, organize the requirements according to the framework, including models, packaged with the high-fidelity visualization. Deliver a presentation, highlighting the key features of the system.

SummaryThe requirements approach in this article emphasizes the synergy that emerges when you combine today’s data practices with visualization and the Decision Model. The most important parts of this approach are:

• Select a requirements framework that distinguishes among discrete dimensions.
• Use the framework to identify the requirements deliverables for your business audience. 
• Deliver models for each dimension of your project, especially for data, business decisions, and process and do so iteratively.
• Understand the value of the Decision Model:
  
  • Represents the forgotten dimension in a rigorous, normalized manner.
  • Improves business decision-making and organizational maturity. 
  • Transcends available data
  • Is iterative and agile in nature.
  • Always reveals important information, which we have ignored.
• Include the Decision Model for important decisions for today and for potential futures.
• Adopt a visualization methodology to elicit data, logic, and process requirements before completing models. 
• Organize a deliverable according to the framework, packaged with the High-Fidelity Visualization.

Remember what Michael Fuller said, “The business runs mostly on non-persistent data.” What are we doing about that?

End Notes:

1. Also referred to as the Zachman Framework, which is a Copyright work of John A. Zachman of Zachman International. Details can be found in Chapter 13 of The Decision Model (Goldberg & von Halle, Auerbach 2010)
2. Irise is the registered Copyright of Irise Corporation.