(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 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.
As a business analyst, consider this important question.
Can We Deliver Less, Get More, and Do It Faster?
Last time, we proposed that, with business rules, we surely can. The traditional way we manage business rules is time-consuming. It focuses on details rather than the bigger picture. The details are the business rules themselves - expressed, analyzed, approved, and stored in a safe place. But, viewed as details, they lose momentum, postponed until design or implementation. Perhaps we deliver too much too early. But, we can do it differently by delivering less up front and evolving it into something more important.
Last time, we proposed a way of doing so. Using a simple example and aiming for quick deliverables, we started with a skeletal Decision Model, devoid of business rules. We evolved it in increments, still without all (or any) business rules. This approach spurred interest from readers and so, we use a different example, focusing on the process so you can do it, too.
Background for Our Example
A business need arises from a fictitious insurance company. ”Of immediate concern is that only a small percentage of new and renewed policies are completely handled by the automated systems. In fact, merely 30% of new policies and 50% of renewed policies are handled completely through the automated systems. The systems route the remainder of the policies to the appropriate region where local regional experts determine whether each policy should be written or renewed …..There are inconsistencies in how renewals have been handled by human experts… Even more alarming is a disappointing decline in revenue despite projections by analysts that commercial auto insurance is a growth market.
The executive management team issues a mandate requiring 75% of both new and renewable policies to be handled completely through the current automated systems…..and for the risk associated with automatically approving these policies to remain as low as it is today. … The company wishes to aggressively grow this revenue by 15%. As usual, the executive management team imposes a strict timeframe and fixed budget on finding and implementing the solution. No new software or technology can be purchased.” (von Halle and Goldberg, 2009).
We need business experts, Decision Modeling skills, and a whiteboard.
Business Experts
Some of our business experts are from regions, such as managers, sales leaders or agents. Some are from centralized functions, such as underwriting, legal, finance, and I/T.
Decision Modeling Skills
For Decision Modeling skills, we use the steps below.
White Board
The white board content appears in Figures 1-5.
The remainder of this article includes steps, related business conversations, and corresponding white board development.
STEP 1: Start with a Business Decision
We need to select a business decision behind the business need. Ideally, we estimate its anticipated value, perhaps in revenue, profit, risk-avoidance, or customer satisfaction.
Business Conversation
One business decision behind our business need is the one that reaches a conclusion as to whether a policy’s renewal method should be the automatic system or human underwriter.
To understand it better, we identify its conclusion fact type, which is the piece of information for which the business decision returns a value. With input from the business experts, we name it Policy Renewal Method; the two values the decision will return are Automatic Renewal Method, and Manual Renewal Method.
Next, we name the business decision itself. The name starts with a decision-oriented word (i.e., Determine, Calculate, Assess) and ends with its conclusion fact type. The business experts name it “Determine Policy Renewal Method".
White Board Content
On our white board, we create a decision icon (i.e., blue octagon) and place the decision name within it. The conclusion fact type is a candidate fact type because we don’t have approval beyond our experts for its name and definition. So, we represent it in green letters.
Next, we connect it to one Rule Family (i.e., green ticket-shape). This Rule Family directly determines the conclusion value. We call it a Decision Rule Family. For now, we know only its conclusion fact type, but this is good. The conclusion fact type always serves as the Rule Family name. We put the conclusion fact type in the top of the Rule Family, again in green letters as Figure 1 shows.
Figure 1: Decision Model Knowing Only the Business Decision
STEP 2: Brainstorm Ideas about Decision Rule Family Conditions
Business creativity begins now. We seek ideas for the conditions that should lead to conclusion values for Policy Renewal Method. Ideally, tangible business objectives provide a starting point.
Business Conversation
A finance expert has concerns about a policy’s performance. A plausible condition fact type is Policy Tier because it already plays a role in determining the risk of renewable policies. Perhaps a comparison to the Policy Discount would suffice, or something like that. This expert also suggests there be a maximum premium over which the company never renews a policy via automation.
An underwriter suggests a placeholder for a whole set of conditions that evaluate underwriting risk.
A regional manager has a different concern – the increased turnover of agents. The company may not be managing related policies as closely as needed. The regional manager wants to think about whether a change in agents over the past year should influence the Policy Renewal Method in some way.
White Board Content
These are only ideas, not business rules or solid fact types. So, we add them in red and place them in the Rule Family icon below the solid line and above the dotted line. This is the place for conditions that are likely to have their own Rule Family.
We now add the idea about Policy Performance, currently as a comparison of Policy Discount to Policy Tier. We also add the ideas of Maximum Policy Premium and Agent Changes. We include a placeholder for a set of underwriting risk conditions, expected to expand into many conditions after further underwriter discussions. Figure 2 contains the Decision Model with these ideas. Business experts now explore these further independently.
Figure 2: Decision Model with Business Ideas about Conditions
STEP 3: Solidify a Condition, Normalize into Dependent Rule Families
Eventually, we need to develop the ideas into condition fact types.
Business Conversation
Starting with the top idea, what is it? How to name it? No one is sure. But, they know it is the result of a comparison, so it belongs in its own Rule Family. For now, its Rule Family contains condition fact types for Policy Discount and Policy Tier.We return to naming the conclusion fact type behind the idea of “Policy Discount vs. Policy Tier.” They agree to call it Policy Tier Within Bounds.
White Board Content
An I/T expert points out that Policy Tier is a known piece of persistent data, already used in systems. So, we place it below the dotted line (where we put persistent data) in black letters (how we indicate it is an approved fact type).
Another I/T expert states that Policy Discount does not exist as persistent data, so we place it above the dotted line (where we put inferred knowledge). Policy Discount and Policy Tier Within Bounds are in green letters as they are candidate fact types.
This dependent Rule Family is taking shape in Figure 3.
Figure 3: Decision Model with the Start of a Logic Branch
STEP 4: Solidify Conditions in the Dependent Rule Family
We now resolve fact types in the dependent Rule Family.
Business Conversation
Policy Discount, because it does not exist as persistent data, needs its own Rule Family. The underwriters agree on five condition fact types to determine Policy Discount.
White Board Content
An I/T expert confirms that these five condition fact types represent persistent data. We add these below the dotted line (for persistent) and in black letters (for approved fact types).Because all condition fact types for this Rule Family represent persistent data, this logic branch ends as Figure 4 shows.
Figure 4: Decision Model with a Complete Logic Branch
STEP 5: Repeat Steps 2-4
We iterate by returning to the Decision Rule Family and resolving all condition fact types. This process leads to additional logic branches.
Business Conversation
Naturally, Underwriting Risk in the Decision Rule Family needs its own Rule Family. Pursuing its set of conditions, underwriters suggest ideas about Property and the Insured. They decide that this is where Agent Changes and Maximum Policy Premium belong, not in the Decision Rule Family.
But, what fact type is Underwriting Risk? They name it Policy Renewal Override, giving underwriters a means to prevail over Policy Renewal Method. They want to add a condition for Policy Manual Renewal Flag, a persistent piece of information existing today.
What about the Insured? They want to consider fact types for changes in an Insured’s ownership and location. But these require their own Rule Families because there will be logic to determine which ownership and location changes are important.
In particular, the experts decide that changes in minority and majority stockholders, board members, and CEO are important. These are persistent data.
Experts believe changes in location can be assessed using zip codes, size in square footage, and construction considerations, all of which exist as persistent data.
Finally, the I/T expert finds a persistent piece of data called Policy Discontinued Agent that can inform the logic about an agent change and another persistent piece of data called Policy Annual Premium to test for a maximum.
White Board
Figure 5 reveals a possible solution with all fact type names and definitions approved.
Figure 5: A Final and Approved Decision Model
Important Observations
Ditching your business rules doesn’t mean ignoring them. It means creating a skeletal Decision Model before addressing business rules. Business experts perceive a Decision Model of business rules as something greater than the sum of its parts. It is a tangible business deliverable, worthy of management attention.
Summary
We hope that this article illustrates that it is easy to get started. More importantly, business rules won’t lose momentum; rather they gain momentum with iterations. In this way, an evolving Decision Model becomes a magnet for creative business thinking. Moreover, as the business analyst, you can get it started.
Author: Barbara von Halle and Larry Goldberg 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