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
Last month’s column introduced a missing model for business analysts. The Decision Model is a normalized rigorous model for business logic like the Relational Model is for data. "Business logic is simply a set of business rules represented as atomic elements of conditions leading to conclusions. As such, business logic represents business thinking about the way important business decisions are made." (von Halle and Goldberg, 2009).
We now look at how Decision Models improved an actual project in which analysts created process models, following a traditional business rules approach. Problems arose because the process models were not decision-aware and business rules got lost.
What is a Process Model that is not Decision-Aware?
An initial process model from this project is on the left in Figure 1. Perhaps it looks like ones you have seen or created. The red annotations are business rule numbers. Business rules are stored in a separate business rule catalog. So far, so good.
Figure 1: Process Models (click image for larger version)
However, looking closer, some tasks evaluate conditions. For example, one task may evaluate a Person’s Annual Income; the next may evaluate a Person’s Employment History. This seems reasonable. These evaluations seem like valid process tasks.
But, if business logic is a set of conditions leading to a conclusion, these evaluations are more like business logic, not process tasks. Without this distinction, process models often represent business logic in at least two different ways – sometimes as annotations, sometimes process tasks. Without rigor for when to use each representation, different analysts will do it differently.
This is undesirable for two reasons. First, the selection of one way over another becomes one of personal preference, not science. The second reason is more subtle. It becomes impossible to extract all business logic from a process model that uses various representations for it. Not to mention, some may be missing. The process model becomes overly complex; the business logic becomes hopelessly unmanageable.
We need more discipline to differentiate process tasks from business logic. We need decision-aware process models, supported by Decision Models.
What is a Decision-Aware Process Model?
The process model on the right in Figure 1 is a decision-aware version of the one on the left. Because we removed from it all business logic, it becomes collapsed and simpler. An octagon within a task denotes a decision task - one guided by business logic. This process model contains five decision tasks, but it no longer contains any buried business logic.
Where Did the Business Logic Go?
The business logic is no longer diluted across tasks or attached as annotations to tasks. It is simply separated into Decision Models anchored to decision tasks. Now, we can manage business logic independently from the processes that use it. Indeed, we can even begin to share entire Decision Models across processes.
Figure 2: The Decision Model in the Middle (click image for larger version)
On the right of Figure 2 are Rule Families. These are normalized "decision tables" containing the detailed business logic (or business rules as atomic conditions leading to conclusions).
So, we now have three deliverables: a decision-aware process model, several structural Decision Models, and normalized "decision tables." Based on rigorous principles, the Decision Model emerges as a new discipline. The Decision Model gives form and function to the inherent structure of business logic, similar to that detected in data by Dr. Codd almost 40 years ago!
What Does the Inherent Structure of Business Logic Look Like?
Figure 3 contains a sample Decision Model diagram which, by definition, depicts only the inherent structure not its details.
Figure 3: Decision Model Diagram (click image for larger version)
A Decision Model diagram contains only two kinds of shapes. One is the octagon representing a business decision. The other represents a Rule Family. There are six of them in Figure 3. The name of a Rule Family is always the name of its conclusion fact type and always appears above the solid line within the Rule Family shape.
A Decision Model always begins with the business decision octagon. The octagon always connects to one Rule Family, called a Decision Rule Family. The Decision Rule Family always has a conclusion fact type matching the business decision.
In Figure 3, the business decision is "Determine the Policy Renewal Method", so the Decision Rule Family is called "Policy Renewal Method" which is its conclusion fact type.
A Rule Family always contains only one conclusion fact type, which is why a Rule Family has only one name. However, a Rule Family may contain zero to many condition fact types leading to the conclusion. These always appear below the solid line. So, the Rule Family for Policy Tier Within Bounds contains two condition fact types: Policy Tier and Policy Discount. This means that the business logic in this Rule Family uses these two fact types to determine a value for its conclusion fact type, Policy Tier Within Bounds.
Note that Policy Discount appears between the solid and dotted line, but Policy Tier appears below the dotted line. This is important. The values for Policy Tier are available as raw data, from a database or web page. So this fact type appears below the dotted line. Yet, the values for Policy Discount are determined by other business logic. So, this fact type appears between the solid and dotted line. Moreover, this fact type also appears as a conclusion in its own Rule Family. So, Figure 3 contains one Rule Family with Policy Discount as a condition fact type, another Rule Family where it is the conclusion fact type, and a line that connects these Rule Families. The connection is an "inferential relationship." It means the Rule Family called Policy Tier Within Bounds is dependent on the Rule Family called Policy Discount.
To see the details behind the Decision Model structure, we need another diagram.
Where are the Details?
The details are in the Rule Family table, consisting of rows conforming to its columns.
Figure 4 shows two inferentially related Rule Families and their Rule Family tables. The Rule Family for Policy Tier Within Bounds has two condition fact types, each of which has its own column in the Rule Family table under "conditions." The conclusion fact type has its own column under "conclusion." We populate the Rule Family table with combinations and permutations for reaching conclusion values. We can add, delete, or update rows without making changes to the Decision Model structure. We can also a guess at the Decision Model structure before knowing all business logic. This is extremely valuable for agile projects.
Figure 4: Decision Model Details (click image for larger version)
Summary
"Capturing business logic or business rules, from conditions to conclusions, and refining it until it is atomic, precise, unambiguous, and aligned with business objectives is what the Decision Model and its principles are all about." With this discipline and the notion of decision-aware process, there is little room for error.
What is Next?
Next month, we look closer at process modeling and Decision Models. Readers are invited to obtain the Decision model primer at www.TheDecisionModel.com and also order The Decision Model book.
Authors: 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