Business Process Models and Business Rules: How They Should Work Together

Business Process Models and Business Rules: How They Should Work Together
(This article assumes knowledge ofthe Decision Model. If you are not already familiar with the theory ofthe Decision Model, you can download a brief primer fromwww.TheDecisionModel.com. You can order the book including a kindle versionhere.
Portions of this article are drawnfrom the book, The Decision Model: A Business Logic Framework LinkingBusiness and Technology, von Halle & Goldberg, © 2009 AuerbachPublications/Taylor & Francis, LLC. This article consists, in part,of abstracts from the book; directly quoted passages, diagrams, andtables are cited, and are copyright © 2009 Auerbach Publications/Taylor& Francis LLC. Reprinted with the permission of the Publisher.
Asbusiness analysts, we know that a business process model is a crucialtechnique for transforming a business and redesigning automated businesssystems. Yet, we struggle with the best way to represent the businessrules that guide it. This is not a surprise, but disappointing.Ironically, business rules may be the most important dimension of anenterprise. They are the core of business decisions and actions, whetherautomated or not. How do we treat them today?
“We discover a single business ruleand add it to a list of other ones. Alternatively, we diagram a businessrule on top of a data model or add it as a miscellaneous note to abusiness process model or use case1. Sometimes, we automateit diligently in special technology but it has been known to disappeareven there. ” (von Halle and Goldberg, 2009)
In a changing world, this is no longer acceptable.
We must separate business rules frombusiness processes properly or the enterprise will experience them aserrors, compliance violations or unsound judgments.
This month we discuss five approaches in practice for dealing with business rules and business processes2. But, we start with three questions.
Question #1: Why Separate Business Rules?
The most important motivation for separating them is to enable businessleaders 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 models
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 bedifferent in an obvious way. Otherwise, separation is merely a matter ofstyle, not science. Luckily, they are quite different if you understandtheir inherent characteristics.
Business process models are primarily about flow of work tasks, often among different actors. Business rules3 are about reasoning and logic, not about flow of work tasks. Business rules carry out intellectual judgments while process tasks perform action-orientedwork. Recognizing this subtle difference leads to a clear separationbetween the two. This becomes more apparent in the five approaches.
Approach 1 does notseparate business rules. It buries them, rendering them invisible andresistant to change. We describe it to expose problems that arise fromnot separating them.
Approaches 2 and 3 separate them bypulling them out of the business process model. Approach 2 points toindividual rules in a business rule repository while Approach 3 pointsto 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 boldstep. It transcends the simple separation provided by Approaches 2 and3, 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 isnot enough. They must have their own existence, just as data does,independent of how and where executed, and whether automated or not. Ifthese are true, we can cast them in their own model, recognizablydifferent (in structure and behavior) from all other kinds of models, aswe do with data. If not, we can only separate them, not promote them tosomething bigger. It is also critical that the structure and behaviorof that model actually reflect the inherent nature of the business rulesand not that of any other consideration. Otherwise, it will dilute themand add unnecessary complexity leading to further, if differentproblems.
Approach 1: Buried (not separated) Business Rules
For decades, business process models displayed no evidence of businessrules. The models contained notations for aspects of process, such astasks, gateways, and flow. There was nothing for business rules.Therefore, we thought of business rules (or parts of them) as pieces ofprocess and disguised them as process tasks, for lack of anything else.Invisible, they blended into the look-and-feel of the business processmodel itself.
Figure 1 is a simple example.

The process model in Figure 1contains five tasks connected with flow. The first evaluates a person’scredit score. If less than 650, it evaluates employment history. Ifunstable, it evaluates miscellaneous loans amount. If high, it assigns avalue of “high” to the person’s likelihood of defaulting on a loan4. At first glance, this looks reasonable, all too familiar.
As an alternative, the process inFigure 2 first evaluates a person’s employment history. If unstable, itevaluates credit score. If less than 650, it evaluates miscellaneousloans amount. If high, it sets the person’s likelihood of defaulting on aloan to “high.”
What is the difference? After all,each arrives at the same conclusion, but in a different sequence. Infact, we can create other models in yet other sequences arriving at thesame conclusion. Apparently, sequence makes no difference. Here is theclarity: when sequence does not matter, you are dealing with logic, notwork tasks.

Both figures have tasks that evaluateone condition at a time rather than a task that evaluates all requiredconditions. With these figures, how do we delete a condition? Add twoconditions? What if there were six conditions leading to the conclusion?What if the conclusion could be many values – say five values – rangingfrom “Very Low” to “Very High”? We would end up with a process modelcontaining over360nodes. How supportable, sustainable is such aprocess? Even worse, we would need to obsess about sequence, even thoughsequence is irrelevant. How maintainable is this?
How many of you have done this or seen it in practice?
If so, you know that Approach 1results in unnecessarily large and complex business process models thatcover entire walls in conference rooms. Regrettably, it offers noadvantages 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 abusiness rule identifier. The identifier points to the business rulestatement in a business rule repository. In this way, the identifiersanchor business rules to process tasks, but the business rulesthemselves are elsewhere. There can be many business rules anchored toone process task.
Assume the following business rules determine a person’s likelihood of defaulting on a loan5:
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:
o Person’s credit score < 650
Person’s employment history is unstable
Person’s miscellaneous loans amount is low.

The third task box in Figure 3determines a person’s likelihood of defaulting on a loan and so itcontains identifiers for the three business rules. The first task boxpoints to BR 4 and others, while the second points to BR5 and others.
If another business process modelcontains a task for Determine Person’s Likelihood of Defaulting on aLoan, Approach 2 requires pointers in that task also for these threebusiness rules. If we need to change one business rule, we change itonly in the business rule repository, not in the process model. But, ifwe need to change the set of business rules in this task, this may bemore difficult.
What if we need to delete BR2 and addBR 7-10 to this task? Approach 2 requires corresponding pointer changesin every such task in every business process model6.
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 repository7
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 collectionof them, grouped in a useful way. While there are many ways to groupbusiness rules, the most popular way, when appropriate, is in a decisiontable8.
Table 1 is a simple decision table ofthree business rules, numbered 1 to 3 (the same ones from Approach 2).These evaluate all or some of the decision table’s three conditions toarrive at a value for its one action. The empty cells are conditionsirrelevant to that business rule’s conclusion.
Conditions
1
2
3
1. Person’s Credit Score
< 650
> 720
< 650
2. Person’s Employment History
Is unstable
Is unstable
3. Person’s Misc Loans Amount
Is high
Is low
Actions
1. Person’s Likelihood of Defaulting on a Loan
Is high
Is low
Is medium
Table 1: Simple Decision Table
Using Table 1, we see that its logicis incomplete. For starters, it does not cover person’s credit scores>= 650 and <=7209.
Table 2 is another format showing the same business rules.
Conditions
1. Person’s Credit Score
< 650
720
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 anentire group of business rules (e.g., a decision table) to an identifierand process tasks point to it as seen in Figure 4. This figure shows adecision table behind each task.

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 conclusions10. 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 anunfortunate combination. It mingles Approach 1 (buries some businessrules) with Approaches 2 and 3 (separates some). Sadly, it is the mostcommon approach.
The resulting business process models are as complex as those in Approach 1 are as indicated by Figure 5.

The prevalence of this approachconfirms that most people do not understand the distinction betweenprocedural process and declarative logic. Approach 4 has alldisadvantages of Approaches 1, 2, and 3 yet none of the advantages ofApproaches 2 and 3. This makes it time-consuming, costly, of littlebenefit, 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 sawthe need to separate data from process to manage data better, andsimplify process. This is eerily similar to the need to separatebusiness rules.
The separation of data from processparalleled the approaches above. First, we identified data elementsoutside of process, grouped them, stored them in data dictionaries, andconnected them to processes. But, we fell short. Separation alone did not deliver on the promise of effective data management!
Effective data management becamepossible only with the adoption of the relational data model. Therelational model revealed that data has its own existence, independentof how and where executed, and whether automated or not. We cast it inits own model, recognizably different (in structure and behavior) fromall other kinds of models, based only on the inherent nature of dataitself, nothing more. We not only separated data, we purified it, andthereby promoted it to a higher holistic dimension because data wasimportant to the health of a business.
Approach 5 does the same for businessrules. “It is a model that addresses an important unsolved problem: howto effectively manage business logic and rules, not as lists orannotations attached to or buried in other models, but in a model oftheir own.”
Simply stated, The Decision Modelcombines groups of business rules into a model where connections amongthose rules are visible. The groups, called Rule Families, resemblespreadsheets, but rigorous enough to be precise and free of irrelevantcomplexities. The connections are inferential relationships because theyrepresent conclusions of one Rule Family11 serving as acondition in another. In this way, the entire model is declarative;there is no need for process tasks and flows among the Rule Families .It not only separates business rules, it purifies them, and therebypromotes them to something higher.
Figure 6 contains a partial DecisionModel for the logic behind a person’s likelihood of defaulting on aloan, containing the three business rules noted above. It also shows adrill-down into two Rule Families where we see additional relatedbusiness rules.

Figure 7 shows the entire structural Decision Model.

Approach 5 associates process taskswith a business decision, which is an identifier for an entire DecisionModel. These are greater in importance than individual business orgroupings.
Approach 5 reduces the businessprocess model to Figure 8. There are no pointers to individual or singlegroups and no procedural flows among decision tables or groups as theseare superfluous. Only the flow of pure process remains because thestructure and content of pure business rules are elsewhere in a holisticdeclarative unique 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 options12
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 notwe separate them. There are various approaches in practice to separatethem.
However, perhaps we need to askourselves the most important question. Are business rules their owndimension, hidden until now, like data was decades ago? If The DecisionModel proves this to be true, this is exciting.
If so, consider abandoning lists andgroupings and casting business rules in a model of their own. Only inthis way, can we promote them to a higher, tangible, valuable and agilebusiness asset, as was done with data.
Today, this is exactly what ishappening in all industries by business people, business analysts, andenterprise architects. Some, if not all, are saying it is game changingwhich is what some people said about data decades ago.
But business rules are different fromdata. If managed properly, they are the means by which a businessdefines itself, changes its thinking, improves its performance, and insome cases, re-invents or saves itself. We need to promote them to ahigher holistic dimension because they are, like data, important to thehealth and survival of a business.