Portions of this article 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.
The management of business decisions is gaining mainstream momentum. Tom Davenport (“Make Better Decisions,” Harvard Business Review, November 2009) states, “In recent years decision makers in both the public and private sectors have made an astounding number of poor calls.” He references Tenneco, General Motors, Time Warner, and Yahoo. “Decisions have been viewed as the prerogative of … senior executives…..The decision process, information, and logic are like a black box.”
He goes on to day that today decision making is becoming the focus of systematic analysis. Businesses are recognizing the importance of decision making and taking steps to make it tangible. He explains success stories related to Chevron, Educational Testing Service, and The Stanley Works.
Why Should Data Professionals Care?As data professionals, we have a history worth noting. Decades ago, we recognized the importance of data management and took steps to make it tangible. We moved data out of the black box and into a valuable business asset.
And so, we already have the skills and vision to do the same for the management of Davenport’s decision making. The best way to do this is to adopt a top down approach for Decision Models. This is similar to a top down approach for data models.
To make this clear, we pose three questions: (1) How are these top down approaches similar? (2) More importantly, how are they different? (3) What are the specific steps in creating Decision Models? We end with a statement about Turning Poor Calls into Good Business.
Question #1: How Are These Top Down Approaches Similar?Top Down Data Models and Why They are Better
Most of us deliver data models using a top down approach, but let’s review it for comparison sake.
Our first deliverable is simply a list of conceptual entities within scope. We evolve the list into related data structures. We place attributes in the proper places based on data normalization principles. Even with incomplete models, we estimate data volumes and identify data sources.
Producing iterative data models is markedly faster (or seems faster) than the bottom up approach of early data modeling days. Following the bottom up approach, we listed, named, defined, and gained approval for all data attributes prior to grouping them into normalized data structures. This is time-consuming, running the risk of slowing down a project. It makes sense that we rarely do it this way today.
Top Down Decision Models and Why They are Better
However, today most people do exactly this for capturing business rules! They list, name, express, and gain approval for all business rules prior to grouping them in an organized way. Naturally, this is time-consuming – often perceived as slowing down a project. It suggests we are operating in the early days of business rule management. As data professionals, we understand that a top down approach would be a better way!
The good news is that a top down approach is much faster and sounds a bit familiar. Why not deliver iterative Decision Models even before we know all (or any) business rules? There is an added bonus. By delivering models instead of lists, business people perceive value early.
“Business people easily recognize that business value is not found in the individual business rule or business logic statement, but in entire business decisions. Therefore, entire Decision Models (even without details) emerge as the asset that drives toward business objectives.” (von Halle and Goldberg, 2009)
So, our first deliverable is simply a list of ideas or condition fact types for the target business decision. We evolve the list into related Decision Model structures. We place conditions and conclusions in the proper places based on Decision Model normalization principles. Even with incomplete models, we understand the complexity and value of the business decision and its data sources.
Producing iterative Decision Models is faster (or seems faster) than the bottom-up approach. But more importantly, through this process, decision making becomes the focus of the systematic analysis of which Davenport speaks! This can make all the difference in the world to the business.
Question #2: How Are These Top Down Approaches Different?The most obvious difference is that data and business logic (i.e., business rules) are not the same. While both are intellectual assets, they differ in nature and purpose. Data are pieces of (usually persistently stored) information that have both meaning and value to the business. “Business logic is a prescription for the way business experts want to evaluate facts in order to arrive at a conclusion where the conclusion has both meaning and value to the business.” (von Halle and Goldberg, 2009)
This difference means that each has a different model, different structures, and different guiding principles. A data model is about entities, attributes, and relationships behind a target business scope. A Decision Model is about Rule Families, conditions and conclusions, and relationships behind a business decision. This is a shift from a focus on information to a focus on the business decision.
The Business Decision – A New AssetSo, what is a business decision? A business decision is a conclusion that a business arrives at through business logic and which the business is interested in managing. Examples include:
- Determine an Insurance Policy’s Renewal Method
- Determine the Customer’s Likelihood of Defaulting on a Loan
- Calculate a Vendor’s Performance Index
Each important business decision deserves management attention. For example, a particular business cares very much about the logic behind the above business decisions: how to renew an insurance policy, a customer’s likelihood of defaulting on a loan, and a vendor’s performance index.
It turns out that the business decision is the asset that the business really needs and wants to manage. Business rules and logic are simply the details by which the business does so. The idea that we can model an entire business decision for business understanding elevates the business rule management process to that of business decision management (BDM or Enterprise Decision Management, EDM). From an organizational maturity perspective, this shift upward has a profound effect.
Why so? We can identify business metrics that ensure that each business decision – (automated or not) yields results that are consistent with the organization’s plans and objectives. Objectives may include profitability, for example.
Question #3: What Are The Specific Steps in Creating Decision Models?Let’s use the example from our last column.
Step 1: Identify a Business Decision for the Decision Model
From a decision-aware business process model or use case, we identify a business decision needing a Decision Model. In our example, it is “Determine Person’s Likelihood of Defaulting on a Loan.” We create an octagon to represent this business decision. For starters, we know only that we will have the Decision Rule Family, which is the Rule Family directly responsible for the conclusion values.
Step 2: Guess at Preliminary Ideas or Condition Fact Types for the Business Decision
The business gets involved right away. Most often, we work with business experts and contemplate fuzzy ideas about the criteria that should play a role in the business decision. We may do this through facilitated sessions, legacy code inspections, interviews, or document review. In our example, business experts propose two ideas for “Determine a Person’s Likelihood of Defaulting on a Loan.” These are employment history and a combination of mortgage and other debt. See Figure 1.
A Decision Model of ideas is the first step by which business experts conduct research and seek other opinions. After all, the goal is to sharpen the business’s decision making.
At some point, we reconvene to modify the fuzzy ideas, refining them into a list of condition fact types. Of importance is that we don’t limit these to data elements in data models, databases or other electronic form. Instead, the list must include all condition fact types the business decision needs, regardless of whether they are physically stored or whether they are data-in-flight. More on that later.
For now, our business experts want separate conditions for mortgage versus other debt. They want to keep employment history as a condition, but add conditions for the quantity of jobs in the past five years and the years at current employer.
We add these to the Decision Rule Family. But we don’t yet know if their values are available in persistent data storage. So, we place them between the dotted and solid line. This is where we put condition fact types that may require their own Rule Families. We need more investigation, but for now, we have Figure 2.
Step 3: Evolve the Conditions into Decision Model Structures
We examine each condition fact type with business experts and data professionals, to discover how its values are determined. If stored as persistent data, we move it below the dotted line in the Decision Rule Family. If determined by business logic or business rules, we leave it between the solid and dotted line and create a supporting Rule Family for it. We connect the Decision Rule Family to its supporting Rule Families with an inferential relationship. An inferential relationship is analogous to a referential relationship in a (relational) data model.
For our example, a data professional points out that Person’s Mortgage Situation and Person’s Miscellaneous Loan Assessment represent persistent data elements used in existing systems. Therefore, we move these below the dotted line. After some discussion, the business experts decide that the Person’s Years at Current Employer and Number of Jobs in Past Five Years are condition fact types for arriving at a conclusion about the Person’s Employment History. So, these become condition fact types in a supporting Rule Family. The data professional points out that these exist as persistent fact types, so we move them below the dotted line in that Rule Family. Refer to Figure 3.
As you can see, condition fact types above the dotted line and below the solid line, represent data-in-flight, which we call “interim knowledge.” This means their values are not available in persistent electronic form, but instead are the result of executing the supporting Rule Family. They serve as condition fact types in the same way persistent data does.
Usually data professionals are concerned only with fact types below the dotted lines in a Decision Model. But to a Decision Modeler and business experts, the interim knowledge is the glue that holds the Decision Model together. The interim knowledge weaves a well-formed web of business logic and each serves as an inferential key (much like a foreign key in a data model).
With a Decision Model like the one in Figure 3, a data professional can build a data model of the persistent fact types or a cross-reference to database fields. Object modelers can build a business object model consisting of all fact types in the Decision Model. In other words, data and object models are possible even before we start serious discovery of business rules. So, Figure 3 serves as an early deliverable prior to the time-consuming gathering of business rules. But, eventually, we need those rules!
Step 4: Populate, Normalize, and Validate with Details
So, we gather business rule statements. We reduce them to atomic form (as discussed in our last column) and populate the Rule Families with them as shown in Table 1. We apply Decision Model normal forms in the same way and for the same purpose that we apply data normal forms. That is, we minimize opportunity for anomalies, such as inconsistencies and unnecessary redundancies, but this time for logic not data.
In both kinds of models, first normal form aims for standard structure. Second normal form removes irrelevant pieces. In a Decision Model, second normal form removes condition fact types that turn out to be irrelevant to the conclusion. Third normal form removes transitive dependencies. In the Decision Model, third normal form removes transitive dependencies among conditions precisely because they represent Rule Families hidden within other Rule Families. Other Decision Model principles require that populated Rule Families cover all condition and conclusion fact type domains. Otherwise, our Decision Model is incomplete and execution will break.
Table 1: Populated Rule Families
SummaryLogical data models and Decision Models are similar at a glance. The fundamental structure of each (i.e., a relation in a data model and a Rule Family in a Decision Model) is comprised of rows and columns, with relationships among them, and normalization principles for populating them. But, the differences are dramatic.
A logical data model is the foundation for the design of persistent data elements in databases. It usually does not include interim fact types.
A Decision Model is the foundation for the design of business logic behind a business decision. A Decision Model contains both persistent fact types and fact types for interim knowledge because both are important for reaching business conclusions.
Turning Poor Calls into Good BusinessThe true value of a Decision Model is not how elegant it looks or how fast we create it, but how well it guides the business toward desired objectives. In other words, how does it minimize Davenport’s poor calls in favor of good business?
For that reason, we measure every Decision Model against actual business performance to be sure it lives up to its intent. To optimize business operations, we change Decision Models to fine-tune business performance. When necessary, we change them to navigate safely through changing or chaotic times.
So, how important are Decision Models? Who should lead the business in building them? Business and requirements analysts are appropriate candidates for decision modeling. So are data analysts. Data analysts understand well the value of a rigorous model, normalization principles, and the importance of connecting fact types to enterprise data sources. It is as familiar as that.
More information on The Decision Model book, training, experiences, and white papers are at www.TheDecisionModel.com.
