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
In a previous column, we looked at how Decision Models improved an actual project. Below, we explore why the Decision Model is the next logical (and simple) advance in process modeling and business rules. We do so by addressing five questions. How does the Decision Model improve a business process model? Where did the business rules go? Why did the business process model become simpler? How does the Decision Model transform a business? Finally, why should business analysts upgrade from a traditional business rules approach to Decision Modeling?
How Does the Decision Model Improve a Business Process Model?
Most projects today do not separate business decisions from business tasks and this is at great cost. Even projects that follow a traditional business rules approach do not truly separate entire business decisions (driven by business rules and logic) from traditional business tasks. This means that we represent some business rules in process models as annotations pointing to a rule catalog and some as business tasks in the same process model.
When we do not truly separate, from process models, entire sets of business rules comprising one business decision, the result is an inefficient and rigid process. Such business processes are not decision-aware. A typical example of this was the real-world project reviewed quickly below.
Figure 1: A Difference in Process Models
From last time, in Figure 1, the process model on the left contains annotations in red for individual business rules. The business rules themselves are stored in a rule catalogue along with relevant metadata. So far so good. However, parts of some business rules, evaluating criteria, appear as task boxes. Visually, it is difficult to understand the nature, complexity, and holistic characteristics of the business rules behind this process model. In fact, we pointed out last time that it is impossible to extract all business rules from these kinds of process models.
The process model on the right reflects the introduction of Decision Models. It is simplified and collapsed because no business rules (even their identification numbers) are present anywhere in it.
Where did the business rules go?
Also from last time, Figure 2 represents the business rules, not by spreading or diluting them across process tasks and not even by annotations on the tasks. Instead, Figure 2 separates them into their own kind of model. In this way, we can manage them as a holistic deliverable, a complete web of business logic, which is totally independent of the processes using it. Both process and rules are agile independently.
Figure 2: Process Model, Decision Model and Rule Families
Figure 2 shows the Decision Model in the middle. Each blue octagon in a task box represents a task guided by a Decision Model as an entire well-formed structural model of related business rules. This process model shows five such tasks. This means there are five Decision Models (fewer if some are reused).
On the right is a set of Rule Families, which look like decision tables. These are actually normalized "tables" containing the detailed rules. It turns out, as you will see, that business logic (as a well-formed set of business rules) has its own inherent structure. As a result, it has its own unique model based on this structure with its own integrity.
Using the Decision Model, we no longer dilute the business rules across tasks or attach them as annotations to tasks. We simply separate them into Decision Models anchored to decision tasks. Now, we can manage business rules independently from the processes that use them. Indeed, we can even begin to share entire Decision Models across processes. Therefore, a decision-aware process is "one that is designed to distinguish between tasks that perform work (i.e., process tasks) and tasks that come to conclusions based on business logic (i.e., decision tasks). Because a decision aware business process makes this distinction, we are able to separate the details behind a decision from the details behind the process task. This separation enables us to represent the details behind a decision task (i.e., business logic) in a different kind of model, specific to business logic. "
The Decision Model represents the idea that there is, within business logic and business rules, an inherent structure based only on the nature of the logic and rules. This structure is similar to the inherent structure that Dr. Codd detected in data almost 40 years ago, but modified for organizing logic instead of data.
Figure 3: Decision Model Notation and Content
Figure 3 contains a Decision Model Diagram in the top left corner. It also shows the expansion of the left two Rule Families. Each Rule Family expands into its own Rule Family table, as shown.
Look at the left most Rule Family and its Rule Family table. The two condition fact types in the Rule Family icon appear as column headings in the table under the word "conditions." In addition, the conclusion fact type in the Rule Family icon appears as a column heading under the word "conclusion." Each Rule Family table contains a set of rows, each row testing for different values of the condition fact types and arriving at a specific value for the conclusion fact type.
It is as simple as that. It not only makes a big difference in process models and business rule management, it elevates business rule management to the practice of decision management.
Notice that these tables look a bit like decision tables. However, there are at least three important differences. First, each Rule Family has only one conclusion fact type. Second, each Rule Family relates to other Rule Families if a condition fact type appears as a conclusion fact type in another Rule Family. Therefore, an entire web of business rules forms quite naturally by itself. Third, the entire model of related Rule Families adheres to Decision Model Principles, guaranteeing predictability and integrity. By applying Decision Model normalization principles, only one way emerges for representing a set of business rules in a Decision Model format. This is good!
Why Did the Process Model become simpler?
Let's look at a very simple example. Figure 4 contains three different ways to create a process model for the same process. Options 1 and 2 do not include Decision Models. However, Option 3 includes the Decision Model hidden in the other options. Let's review the differences.
Option 1 prescribes that first the process determines a person's employment history. Then, if it is good, the process next determines the person's debt. If this is low, the process sets the person's credit rating to "A." However, if the results are not these values, the process branches to the task labeled Set Person Credit Rating to ?. In this business process flow, the sequence of evaluating the business criteria is to be done in a specific order. That is, the process flow is rigidly specified, not allowing for alternative sequencing.
Now look at Option 2. It prescribes a different sequence that also works where the process evaluates person's debt first and their employment history second. This process flow requires the sequence of evaluating the business criteria to be done in this specific order and it does not allow for alternative sequencing. What if we want the process to evaluate third business criterion? In each of these options, we would need to decide in which sequence we do so.
Now look at Option 3. It combines the previous task boxes into just one task box labeled Determine Person Credit Rating. Obviously, this process flow is simpler than option 1 and 2. We designate this one task as a business decision task by placing in it the decision octagon. Where did the evaluations of the business criteria go? The answer is simple. They are (all of them!) in a separated Decision Model shown on the right hand side of Option 3. This Decision Model diagram puts the Decision Rule Family (the one at the top of the Decision Model) in context with its related Rule Families. In the middle of Option 3, we show a Rule Family table for the Decision Rule Family, which contains the details of the logic. However, note that neither the Rule Family table nor the Decision Model diagram is embedded in the process flow. They are, by definition, separate deliverables, anchored to the process flow by the decision shape.
A Rule Family, according to a Decision Model principle, implies no particular sequence among the conditions to be tested or of the rows. This Rule Family also contains a "?" for the other possible combinations of conditions to consider. For Option 3, what if we want the process to evaluate third criterion? We do not need to worry at all about sequence; we simply add a column for the additional condition.
Figure 4: Three ways to Model the Same Business Process
Of utmost importance is the following. "To separate business processes and business decisions, they must somehow be different from each other in a recognizable way. It turns out that they are truly different in a very significant way. In fact, the inherent nature of a business process is very different from that of a business decision. To date, however, we have not understood this difference, but the Decision Model brings it to the forefront.
Essentially, a business process is procedural in nature while a business decision is declarative in nature. However, without a clear understanding of a declarative versus procedural nature, common practice involves creating business process models in which we represent business decisions as just another part of the business process. In other words, it is common practice to model business processes and business decisions in a procedural manner rather than modeling the latter in a declarative manner. This common practice not only constrains the business decision unnecessarily, it seriously hinders agility for both the business process and the business decision.
Separating business decisions from business process tasks simplifies the business process model, offers more creativity in organizing the business logic, and delivers the business logic in a form that transcends technology options."
How Do Decision Models Transform a Business?
"Organizations adopt BPM to achieve operational excellence, the epitome of which is the lowest possible cost of providing a given level (presumably high) of service. This is commendable, but is often insufficient for the truly competitive organization. After all, squeezing inefficiency out of a business process is a tactic available to all competitors in the marketplace. All other things being equal, a competitor who achieves or exceeds the same level of efficiency will over time, inevitably challenge the most efficient operator. The key differentiation then becomes the organizational intelligence that operates behind critical business processes. This means that competition is not only about how efficient a business process is but also how smart its business decisions are.
"Implementing business process correctly is as much (and perhaps more) about managing business decisions as it is about business process. By ensuring that a business pays attention to both sides of this symbiotic relationship, the business is more likely to achieve the greatest gains from business process improvement. "
Why Should Business Analysts Upgrade from Business Rules to Decision Modeling?
There are at least three reasons for upgrading a business rules approach to Decision Modeling. The first reason is that the simplification of business process models is significant. The second is that agility is significantly enhanced and independent in both the business process and business rules. The third is that the delivery of Decision Models brings business leaders together. It offers a disciplined technique to stimulate creative thinking about how important decisions ought to be made. It offers a living artifact for changing them over time. As a bonus, the business logic, organized within normalized Decision Models delivers it in a form that transcends technology options for today and the future.
What is Next?
This column continues next time exploring the practicality and business implications of the Decision Models in real business environments. Readers are invited to obtain the Decision model primer at www.TheDecisionModel.com and order The Decision Model book that is now available for shipping.
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