This article assumes knowledge of the Decision Model. You can order the book including a kindle version at amazon.com here.
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.
Members of the BPMInsititute.org know that a business process model is a crucial technique for transforming a business and redesigning automated business systems. Yet, the industry continues to struggle with the best way to represent the business rules that guide it. This is not a surprise, but disappointing. Ironically, business rules may be the most important dimension of an enterprise. They are the core of business decisions and actions, whether automated or not. How do we treat them today?
“We discover a single business rule and add it to a list of other ones. Alternatively, we diagram a business rule on top of a data model or add it as a miscellaneous note to a business process model or use case(1). Sometimes, we automate it diligently in special technology but it has been known to disappear even there. ” (von Halle and Goldberg, 2009)
In a changing world, this is no longer acceptable.
We must separate business rules from business processes properly or the enterprise will experience them as errors, compliance violations or unsound judgments.
This month we discuss five approaches in practice for dealing with business rules and business processes(2). But, we start with three questions.
The most important motivation for separating them is to enable business leaders to manage them for the good of the business. In separating them, we can:
For separation to make sense, business processes and rules must be different in an obvious way. Otherwise, separation is merely a matter of style, not science. Luckily, they are quite different if you understand their inherent characteristics.
Business process models are primarily about flow of work tasks, often among different actors. Business rules are about reasoning and logic, not about flow of work tasks. Business rules(3) carry out intellectual judgments while process tasks perform action-oriented work. Recognizing this subtle difference leads to a clear separation between the two. This becomes more apparent in the five approaches.
Approach 1 does not separate business rules. It buries them, rendering them invisible and resistant to change. We describe it to expose problems that arise from not separating them.
Approaches 2 and 3 separate them by pulling them out of the business process model. Approach 2 points to individual rules in a business rule repository while Approach 3 points to groups of them.
Approach 4 is an unfortunate hybrid of Approaches 1,2 and 3. We cover it because it is quite popular despite being undesirable.
Finally, Approach 5 takes a bold step. It transcends the simple separation provided by Approaches 2 and 3, promoting business rules to a new dimension in their own right.
For business rules to qualify as a new dimension, separation alone is not enough. They must have their own existence, just as data does, independent of how and where executed, and whether automated or not. If these are true, we can cast them in their own model, recognizably different (in structure and behavior) from all other kinds of models, as we do with data. If not, we can only separate them, not promote them to something bigger. It is also critical that the structure and behavior of that model actually reflect the inherent nature of the business rules and not that of any other consideration. Otherwise, it will dilute them and add unnecessary complexity leading to further, if different problems.
For decades, business process models displayed no evidence of business rules. The models contained notations for aspects of process, such as tasks, gateways, and flow. There was nothing for business rules. Therefore, we thought of business rules (or parts of them) as pieces of process and disguised them as process tasks, for lack of anything else. Invisible, they blended into the look-and-feel of the business process model itself.
Figure 1 is a simple example.
![]() |
Figure 1: Business Rules Modeled as a Process Flow
The process model in Figure 1 contains five tasks connected with flow. The first evaluates a person’s credit score. If less than 650, it evaluates employment history. If unstable, it evaluates miscellaneous loans amount. If high, it assigns a value of “high” to the person’s likelihood of defaulting on a loan(4). At first glance, this looks reasonable, all too familiar.
As an alternative, the process in Figure 2 first evaluates a person’s employment history. If unstable, it evaluates credit score. If less than 650, it evaluates miscellaneous loans amount. If high, it sets the person’s likelihood of defaulting on a loan to “high.”
What is the difference? After all, each arrives at the same conclusion, but in a different sequence. In fact, we can create other models in yet other sequences arriving at the same conclusion. Apparently, sequence makes no difference. Here is the clarity: when sequence does not matter, you are dealing with logic, not work tasks.
![]() |
Figure 2: Same Business Rules in a Process Flow but Different Sequence
Both figures have tasks that evaluate one condition at a time rather than a task that evaluates all required conditions. With these figures, how do we delete a condition? Add two conditions? What if there were six conditions leading to the conclusion? What if the conclusion could be many values – say five values – ranging from “Very Low” to “Very High”? We would end up with a process model containing over 360 nodes. How supportable, sustainable is such a process? Even worse, we would need to obsess about sequence, even though sequence is irrelevant. How maintainable is this?
How many of you have done this or seen it in practice?
If so, you know that Approach 1 results in unnecessarily large and complex business process models that cover entire walls in conference rooms. Regrettably, it offers no advantages regarding management of business rules.
Approach 1 has at least three disadvantages:
Approach 2 separates business rules by associating a process task with a business rule identifier. The identifier points to the business rule statement in a business rule repository. In this way, the identifiers anchor business rules to process tasks, but the business rules themselves are elsewhere. There can be many business rules anchored to one process task.
Assume the following business rules determine a person’s likelihood of defaulting on a loan(5):
![]() |
Figure 3: Business Process Model with Business Rules Anchored as Pointers
The third task box in Figure 3 determines a person’s likelihood of defaulting on a loan and so it contains identifiers for the three business rules. The first task box points to BR 4 and others, while the second points to BR5 and others.
If another business process model contains a task for Determine Person’s Likelihood of Defaulting on a Loan, Approach 2 requires pointers in that task also for these three business rules. If we need to change one business rule, we change it only in the business rule repository, not in the process model. But, if we need to change the set of business rules in this task, this may be more difficult.
What if we need to delete BR2 and add BR 7-10 to this task? Approach 2 requires corresponding pointer changes in every such task in every business process model(6).
Approach 2 has at least three advantages:
However, Approach 2 has four disadvantages:
Approach 3 separates business rules by associating a process task with a collection of them, grouped in a useful way. While there are many ways to group business rules, the most popular way, when appropriate, is in a decision table(8). Table 1 is a simple decision table of three business rules, numbered 1 to 3 (the same ones from Approach 2). These evaluate all or some of the decision table’s three conditions to arrive at a value for its one action. The empty cells are conditions irrelevant to that business rule’s conclusion.
Conditions | 1 | 2 | 3 |
1. Person’s Credit Score |
2. Person’s Employment History
3. Person’s Misc Loans Amount
1. Person’s Likelihood of Defaulting on a Loan
Table 1: Simple Decision Table
Using Table 1, we see that its logic is incomplete. For starters, it does not cover person’s credit scores >= 650 and <=720(9).
Table 2 is another format showing the same business rules.
Conditions | ||||||||||||
1. Person’s Credit Score | < 650 | 720 | ||||||||||
Conditions | ||||||||||||
2. Person’s Employment History | stable | unstable | stable | unstable | ||||||||
3. Person’s Misc Loans Amount | High | Medium | low | High | Medium | low | High | Medium | low | High | Medium | low |
1. Person’s Likelihood of Defaulting on a Loan is High | x | |||||||||||
2. Person’s Likelihood of Defaulting on a Loan is Medium | x | |||||||||||
3. Person’s Likelihood of Defaulting on a Loan is Medium | x | x | x | x | x | x | ||||||
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
Table 2: Different Format for a Decision Table
Some practitioners prefer to represent conditions and actions across columns and rules down the rows.
Regardless, Approach 3 assigns an entire group of business rules (e.g., a decision table) to an identifier and process tasks point to it as seen in Figure 4. This figure shows a decision table behind each task.
![]() |
Figure 4: Business Process Model with Pointer to Decision Tables, Not individual Rules
Approach 3 has three advantages:
However, Approach 3 has four disadvantages:
The hybrid approach is not different from the previous ones, but an unfortunate combination. It mingles Approach 1 (buries some business rules) with Approaches 2 and 3 (separates some). Sadly, it is the most common approach.
The resulting business process models are as complex as those in Approach 1 are as indicated by Figure 5.
![]() |
Figure 5: Business Rules using a Hybrid Approach - Some in Task Boxes, Some are Pointers
The prevalence of this approach confirms that most people do not understand the distinction between procedural process and declarative logic. Approach 4 has all disadvantages of Approaches 1, 2, and 3 yet none of the advantages of Approaches 2 and 3. This makes it time-consuming, costly, of little benefit, likely to fail in business rule management.
Let’s revisit a lesson from the past.
Almost 50 years ago, some people saw the need to separate data from process to manage data better, and simplify process. This is eerily similar to the need to separate business rules.
The separation of data from process paralleled the approaches above. First, we identified data elements outside of process, grouped them, stored them in data dictionaries, and connected them to processes. But, we fell short. Separation alone did not deliver on the promise of effective data management!
Effective data management became possible only with the adoption of the relational data model. The relational model revealed that data has its own existence, independent of how and where executed, and whether automated or not. We cast it in its own model, recognizably different (in structure and behavior) from all other kinds of models, based only on the inherent nature of data itself, nothing more. We not only separated data, we purified it, and thereby promoted it to a higher holistic dimension because data was important to the health of a business.
Approach 5 does the same for business rules. “It is a model that addresses an important unsolved problem: how to effectively manage business logic and rules, not as lists or annotations attached to or buried in other models, but in a model of their own.”
Simply stated, The Decision Model combines groups of business rules into a model where connections among those rules are visible. The groups, called Rule Families, resemble spreadsheets, but rigorous enough to be precise and free of irrelevant complexities. The connections are inferential relationships because they represent conclusions of one Rule Family serving as a condition in another. In this way, the entire model is declarative; there is no need for process tasks and flows among the Rule Families(11). It not only separates business rules, it purifies them, and thereby promotes them to something higher.
Figure 6 contains a partial Decision Model for the logic behind a person’s likelihood of defaulting on a loan, containing the three business rules noted above. It also shows a drill-down into two Rule Families where we see additional related business rules.
![]() |
Figure 6: Partial Decision Model for Person's Likelihood of Defaulting on a Loan
Figure 7 shows the entire structural Decision Model.
![]() |
Figure 7: Complete Decision Model for Person's Likelihood of Defaulting on a Loan
Approach 5 associates process tasks with a business decision, which is an identifier for an entire Decision Model. These are greater in importance than individual business or groupings.
Approach 5 reduces the business process model to Figure 8. There are no pointers to individual or single groups and no procedural flows among decision tables or groups as these are superfluous. Only the flow of pure process remains because the structure and content of pure business rules are elsewhere in a holistic declarative unique model.
![]() |
Figure 8: Business Process Model with Pointer to an Entire Decision Model
The advantages of Approach 5 are significant because it embraces a new dimension, a new business paradigm:
Business process models and business rules work together, whether or not we separate them. There are various approaches in practice to separate them.
However, perhaps we need to ask ourselves the most important question. Are business rules their own dimension, hidden until now, like data was decades ago? If The Decision Model proves this to be true, this is exciting.
If so, consider abandoning lists and groupings and casting business rules in a model of their own. Only in this way, can we promote them to a higher, tangible, valuable and agile business asset, as was done with data.
Today, this is exactly what is happening in all industries by business people, business analysts, and enterprise architects. Some, if not all, are saying it is game changing which is what some people said about data decades ago.
But business rules are different from data. If managed properly, they are the means by which a business defines itself, changes its thinking, improves its performance, and in some cases, re-invents or saves itself. We need to promote them to a higher holistic dimension because they are, like data, important to the health and survival of a business.
“Once we can see what was previously invisible, we are positioned to harness it to our advantage. Moreover, it will advance our knowledge of other dimensions, like process models, so we can simplify them.” (Von Halle and Goldberg, 2009)
is the founder of Knowledge Partners, Inc., a company specializing in business rule services. Barbara received the 1996 Outstanding Individual Achievement Award from the International Data Management Association. For over five years, von Halle was the leading contributing editor for Database Programming and Design Magazine. She co-authored The Handbook of Relational Database, a standard text in universities and business environments. Her most recent book, Business Rules Applied is the first book to contain a step-by-step approach for delivering business rule systems. It was a finalist in the 2002 Jolt Awards from Software Development Magazine.
Barbara von Halle
has over thirty years of experience in building technology based companies, in which the focus was rules-based technologies and applications. Prior to joining KPI as Managing Partner, he was Senior Vice President of Sapiens Americas, Inc., which he joined when he sold his company, PowerFlex Software Systems, Inc to Sapiens.
There are no products in your shopping cart.
0 Items |
BPMInstitute.org provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page.
BPM 101OpEx Tools of the TradeMethodologies and Approaches for BPMAdvanced Facilitation SkillsAgile BPM Roles and ResponsibilitiesView the Learning Path for more courses »