Business Process Models, Business Rules and The Decision Model: How They Should Work Together

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.

Question #1: Why Separate Business Rules?

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:

• Trace them to business motivations and measure their success against benchmarks to determine if we need to modify them.
• Make changes in them independent of changes in business process models. (Business rules change more frequently than do processes).
• Share them across many business processes.
• Define, analyze, and test them prior to, or in parallel with, development of business process model.
• Create decision-aware, more intelligent, agile business processes.
• Leverage them to improve business performance and minimize business risk.

Question #2: How to Separate Business Rules?

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.

Question #3: How to Promote Business Rules to a Higher Dimension?

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.

Approach 1: Buried (not separated) Business Rules

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:

• Produces unnecessarily complex business process models because it forces irrelevant decomposition and sequence in evaluation of business rules.
• Forces us to make business rule changes in the business process model. To add, remove, or change conditions or conclusions, we must add, remove, or change process tasks and flow.
• Fails to deliver a holistic view of business rules because it is virtually impossible to resurrect all business rules into one deliverable and analyze it for integrity.

Approach 2: Anchored Business Rules

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):

• BR1: A person’s likelihood of defaulting on a loan is high if all of the following are true:
  • Person’s credit score < 650
  • Person’s employment history is unstable
  • Person’s miscellaneous loans amount is high
• BR2: A person’s likelihood of defaulting on a loan is low if the following is true:
  • Person’s credit score > 720
• BR3: A person’s likelihood of defaulting on a loan is medium if all of the following is true:
  • Person’s credit score < 650
  • Person’s employment history is unstable
  • Person’s miscellaneous loans amount is low.

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:

• Establishes business rules as a deliverable outside the process model, encouraging business rule sharing.
• Includes a business rule repository, which holds metadata, such as effective and expiration dates, versions, and stewards.
• Allows us to make changes in individual business rules (i.e., BR2) without changing the business process model.

However, Approach 2 has four disadvantages:

• Forces us to make changes in the business process model when we need to change membership of groups of business rules.
• Fails to elevate business rules to business level because individual statements in a business rule repository are often perceived as another type of requirement, or worse, a design artifact.
• Renders analysis difficult, depending on the nature of business rule expressions in the business rule repository(7).
• Fails to deliver a holistic view of business rules because lists of them within tasks cannot convey the relationships among them and across groups of them.

Approach 3: Grouped Business Rules

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.

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.

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:

• Establishes a group of business rules (e.g., decision table) as a separate deliverable outside the business process model. This elevates business rules to a deliverable more visible for business audiences because groups of business rules are more interesting.
• Removes changes in individual and collections of business rules from the business process model. We make these changes only in the grouping (e.g., decision table) with no corresponding changes in business process models.
• Is easily understood, analyzed and validated by business audiences.

However, Approach 3 has four disadvantages:

• Results in complex logic if it includes Ors among conditions, ELSEs or OTHERWISEs among conclusions(10). Such a decision table resembles program code, difficult for business people to analyze and validate.
• Imposes unnecessary procedural representations if several groupings (e.g., decision tables) relate to one business process task. Should the task contain a list of them? Should we separate them into more than one task even if sequence is irrelevant? Should we include a pointer in the task to a “process flow” among the groups? How much of this is design and not appropriate for a business process model?
• Fails to deliver a holistic view of business rules because connections among groupings of business rules (e.g., decision tables) are not recognized.
• Adds unnecessary complexity if it allows for multiple actions from a set of conditions. This interferes with both the atomicity and reusability of the logic. By combining actions that result from a given set of conditions, a change affecting only one of the actions requires a change in the structure of the table. In brief, multi-conclusion decision tables, particularly in complex environments, lack the stability of The Decision Model, with its trademark single conclusion fact type.

Approach 4: Hybrid Approach

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.

Approach #5: Modeled Business Rules

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:

• Elevates business rules to the highest possible business deliverable - a business decision, connected to ROI, and supported by an entire Decision Model.
• Simplifies business process models significantly by removing irrelevant procedural work-arounds and delivers decision-aware processes.
• Enables sharing of Decision Models.
• Removes business rule changes of any kind from business process models (and other models) because all changes in an entire Decision Model happen in one place without corresponding changes elsewhere.
• Enables visual impact analysis of structure and content across entire Decision Models.
• Proves to be faster to develop and implement than any of the other options(12).
• Significantly reduces testing time and costs.
• Brings to light eloquent solutions to common business rule problems, including the use of views which are not possible without a model.

Summary

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)

1. Or we catalogue it in a business rule repository, database or spreadsheet. We might create a new kind of requirement for it in a requirements tool.
2. A past column discussed approaches for dealing with business rules and use cases. There are similarities regarding business processes and some differences.
3. In the context of business processes, we work with business rules as expressions of logic (i.e., conditions leading to conclusions). That’s because a business process must distinguish between tasks to execute when business rules are met versus when they are violated. This is easy when we state them explicitly in terms of conditions leading to conclusions.
4. We ignore the alternate paths, for simplicity.
5. Approach 1 showed a process model for only one of these business rules.
6. You can alleviate this if you share a process task across business process models.
7. The usefulness of business rules in a business rule repository to business audiences depends on how we express them. If their expressions are not in a syntax or grammar intuitive to business audiences, business validation, support, and perceived value diminishes.
8. Research continues on the evolution of the decision table. This is good as it provides guidance for creating high quality decision tables representing business rules.
9. It is not so easy to detect incompleteness when dealing with individual business rules in Approach 2, especially if they are textual.
10. These key words are well known for causing many problems with our systems today.
11. In most cases, designers will need to create process flows among Rule Families if implementing in a technology that cannot detect them. However, technology is already available that recognizes inferential relationships in Decision Models. See http://openrules.com/docs/DecisionModelPrimer.htm.
12. Practitioners have reduced the time to develop and implement business rules by 50% from the approaches above, including codeless import into a BRMS.

About the authors:

Barbara von Halle

Larry Goldberg

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.