INSIGHTS FOR SUCCESS
The Decision Model and Process
Models with BPMN
By Barbara von Halle and Larry Goldberg
[Portions of this article draw 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]
The Decision Model in practice has delivered many unanticipated, but positive surprises. The most obvious and powerful surprise
is how it drastically simplifies process models. In fact, we regularly receive unsolicited messages from people who experience this
effect.
For example, one practitioner condensed a 45-page process model to one with eight task boxes. Another reduced an 80-page
process description to a process model consisting of a handful of tasks and five decision models. Several people have declared
that their process models of 20 shrunk to 1-3 pages. Most interesting is one business analyst who was not confident enough
to create a decision model. Nevertheless, he eliminated many tasks in existing process models merely by recognizing where
decision models belong. In his case, he simplified the process models and someone else developed the corresponding decision
models.
Because this (very welcomed) side effect of decision models is so intriguing, this month’s column provides a detailed explanation
for it and, more importantly, how you, too, can achieve it in your projects. There are three parts to this column. Part 1 is a
review of how most people connect business rules to process models. Part 2 is a review of how decision models and process
models connect in a much better way. Part 3 contains five useful steps for delivering both kinds of models in a project. Readers
experienced or familiar with business rules and The Decision Model may want to skip to Part 3.
-1-
The Decision Model and Process Models with BPMN
PART 1: Business Rules and Process Models
A past column[1] explained several approaches by which people connect business rules to process models in the absence of
The Decision Model. However, most people do so by developing process models similar to one shown in past columns and
repeated in Figure 1.
Figure 1: A Typical Process Model with Links to Business Rules
This process model contains task boxes and gateways and, in theory, does not contain business rules. Instead, identifiers within
task boxes point to business rule expressions in a separate business rule repository, catalog, requirements tool, or database[2].
The business rule expressions may take on various formats: a specific grammar (e.g., SBVR), standard fill-in-the-blank templates,
decision tables, or simple free-form text.
The process model in Figure 1, like many process models, unintentionally includes another way of representing business rules.
That is, some of the task boxes are actually business rules in disguise. An example is a task box labeled “Evaluate person’s credit
score” where there is a subsequent task box labeled “Evaluate person’s employment history.” More often than not, these kinds of
task boxes are business rules (or parts of them) expressed using process model notation.
When a process model includes various ways of representing business rules, it is virtually impossible to pull all business rules out
of it.
Therefore, while separating business rules is a good idea, this way of doing so falls short. The business rules, despite good
intentions, become lost and unmanageable.
-2-
The Decision Model and Process Models with BPMN
PART 2: Decision Models and (Decision-Aware) Process Models Figure 2, repeated from a previous column, illustrates how much simpler the process model in Figure 1 becomes when business
rules are separated into decision models. Most obvious is that there are fewer task boxes and the thorny display of pointers is
gone.
Figure 2: Decision-Aware Process Model
Figure 3 illustrates how a process model connects to decision models. Two of the orange task boxes contain pale blue octagons,
which are anchors indicating that an entire decision model guides these tasks.
The arrow from the pale blue octagon in the top task box points to a model that has the same octagon at its top and a set of
green shapes connected to each other. At a casual glance, the green model in the middle may look like a data model, object
model, or process decomposition diagram, but it is none of these. It is a decision model. Its five green icons are called Rule
Families and they relate to each other illustrated by relationship lines between them.
The four arrows at the bottom of one of the Decision Model Diagrams in Figure 3 lead to a structure containing the Rule Family
content. This structure resembles a common decision table, but is more rigorous because it conforms to 15 decision model
principles, including three forms of normalization. The logic of the business rules becomes rows of logic in a Rule Family table.
The Decision Model principles lead to only one rigorous predictable repeatable decision model representation.[3]
-3-
The Decision Model and Process Models with BPMN
Figure 3: Relationship from Process Model to Decision Model
The resulting structures, unbiased by process, technology, and personal preference are reusable by many processes and
systems precisely because they are pure and unbiased.
What about BPMN?
BPMN stands for business process modeling notation and is a vendor-independent notation from the Object Management
Group, also known as OMG.[4] As such, BPMN consists of shapes and connections with specific definitions and rules. BPMN
includes standard task types. While none of them is a decision task, BPMN 2.0 includes a business rule task, which for now is
the way to represent a decision task. A BPMN business rule task provides the means by which a process provides input to a
business rule engine and receives output from it.
An expert on BPMN, Bruce Silver[5] , states ‘The appropriate way to represent business decisions is through the use of an
appropriately designated task, current defined in BPMN 2.0 as a business rule task….By representing the Decision Model with a
specific task type and managing the logic separately, the business logic can be managed independently of the business process
and reused across the enterprise.”
Silver explains that it is important that all decision models be associated with a BPMN business rule task and not with a BPMN
decision gateway. The latter is simply a routing mechanism and does not represent business logic leading to a conclusion.
In BPMN models, it is common for a BPMN decision gateway (i.e., a diamond) to follow a business rule task. In this way, the
BPMN decision gateway simply indicates the path to follow based on the conclusion reached by the decision model behind the
prior business rule task. You will see this in Part 3 when we explain the process model in Figure 4.
-4-
The Decision Model and Process Models with BPMN
Part 3: Five Steps for Delivering Both Kinds of Models
Below are five steps for delivering process models and decision models in a typical project.
Step 1: High-level Scope
Task 1a. Start by understanding the business motivations for the project, such as goals and measurable business objectives.
Keep in mind that each decision model exists to achieve specific objectives. Some aim to lower expenses, others to increase
revenue or profit, open new opportunities, or reduce fines or risk. If possible, also identify business performance metrics by
which to measure success.
Example:
Table 1 contains a list of goals, objectives, and performance metrics justifying a decision model project for a mythical insurance
company.
Executive Management
Goal
Executive Management
Measurable Objectives
Business Performance Metrics: Evaluated every 90 days
Increase the percentage
of automated renewed
commercial auto
insurance policies
Renewed policies
automation to increase from
50% to 75%
Total quantity of policies targeted for renewal by region Total
quantity and percentage of policies completed through automated
renewal by region Total quantity and percentage of policies
completed through human
Quantity of non-renewal task hours from employee timesheets by
region Evaluate subjective survey from regional experts themselves
on how they perceive their time is used
Increase time spent by
regional experts on other
kinds of tasks
Free up regional experts’
time by 20%
Quantity of non-renewal task hours from employee timesheets by
region Evaluate subjective survey from regional experts themselves
on how they perceive their time is used
Increase the level of
customer satisfaction
regarding renewed
commercial auto
insurance policies
Retention of renewable
policies to increase from
60% to 90%
Total quantity and percentage of renewed policies per region
Maintain (do not increase) Average profitability on new
current risk level of
policies to be at least 20%
renewed commercial auto
insurance policies
Average profitability of manually renewed policies per region
Average profitability of automated renewed policies per region
Increase the revenue from Revenue from renewed
renewed commercial auto commercial auto policies to
insurance policies
increase by 15%
Total revenue from renewed auto policies per region
Table 1: Sample Business Motivations for a Project
-5-
The Decision Model and Process Models with BPMN
Task 1b. Create a list of business processes within scope, keeping in mind that a project may include more than one business
process.
Example: Assume that our project involves one business process, the Policy Administration Process.
Task 1c. Create a list of expected business decisions within the business processes to the best of your knowledge.
Example: We speculate that the Policy Administration Process involves only two business decisions of interest to our project’s
objectives: “Identify Policies for Renewal” and “Determine a Policy’s Renewal Method (automated or manual)”.
Step 2: Plan and Estimate[6]
Task 2a. Create a high-level process model (e.g., BPMN) for each business process in scope. Typically, it will decompose down
to two or three levels before you find tasks guided by business decisions.
Example: Figure 4 shows a process model for the Policy Administration Process to three levels.
Task 2b. Anchor business decisions to process tasks by using the decision icon. You may discover additional business decisions
or eliminate some.
Example: Figure 4 anchors the two business decisions to appropriate tasks in the third level of the process model.
Figure 4: High Level Process Model
Task 2c. Take an educated guess about the characteristics of each decision model.
-6-
The Decision Model and Process Models with BPMN
Example: Table 2 contains our best guess at size and complexity of the decision model for “Determine a Policy’s Renewal
Method.”
Target
Decision
Estimated
Quantity
of Rule
Families
Estimated
Quantity of
Fact Types
Estimated
Quantity of
Rows per
Rule Family
Estimated
Quantity of
Reference
Sources
(people,
documents,
code)
Assessment Assessment Assessment of
of
of Quality of Business Logic
Accessibility Sources
Complexity
of Sources
Determine
Policy
Renewal
Method
5-10
20
20-100
50
Medium
Medium
Simple but
fact types are
unknown and
regional versus
global issues are
important
Table 2: Estimated Characteristics for a Decision Model
Task 2d. Prioritize the decision models for development. Decide whether to develop them one at a time or whether to do so with
parallel teams.
Example: Based on the business motivations and objectives in our example, the decision to “Determine a Policy’s Renewal
Method” is where we need to focus. We learn there will be two views for it: one for most of the world and another with specific
logic for a particular region[7] . Both views of this decision model, by definition, will come to a conclusion about a Policy’s
Renewal Method, but they will differ in their details. Our first priority is the World View [8].
Step 3: Evolve Process models and Decision Models
Develop details of the process model, decision models, and glossary of fact types. Design the process model so that each
decision task has the data it needs (and of proper quality) before it executes. If the process is to evaluate data quality, be sure
it happens in a task before related decision tasks. If using decision models for data quality logic, place decision tasks for data
quality logic in front of decision tasks for the corresponding business decision [9].
Usually, the models evolve together, iteratively: process model, decision model diagrams, Rule Families, glossary. Changes in any
of these cause changes in others.
Example: Figure 5 contains a complete decision model for the World View and Table 3 contains one of its Rule Families.
-7-
The Decision Model and Process Models with BPMN
Figure 5: Completed Decision Model Diagram.
Insured Major
Location Change
Is
Insured Major
Ownership
Change
Policy Annual
Premium
Policy
Discontinued
Agent
Policy Manual
Flag
Yes
Is
Yes
Is greater
than
$32,000
Yes
Is
Is
No
Is
No
Is Less
than or
equal to
$32,000 Is
Table 3: One Rule Family
-8-
No
Policy
Underwriting
Risk
Is
Yes
Is
Yes
Is
Yes
Is
Yes
Is
Yes
Is
Yes
Is
No
Is
Yes
The Decision Model and Process Models with BPMN
Step 4: Deliver to IT or Deploy In some organizations, the process model and/or decision models serve as requirements against which IT develops or
generates software. Other organizations are delivering special environments[10] through which business people or business
analysts create and validate decision models against the 15 principles and test them against input data. This happens prior to
production deployment and, sometimes, with minimal IT intervention.
Step 5: Monitor decision model performance over time and make changes Monitor the business performance metrics gathered in task 1a to assess if the decision models are meeting expectations. If
not, investigate ways to fine-tune under-performing decision models. A decision model that does not deliver value is not worth
creating.
Wrap Up
The Decision Model not only adds clarity to business logic, it sharpens and simplifies business processes. A process model
should represent the procedural flow of tasks. A decision model should represent the declarative conditions leading to the
conclusions of business decisions.
In the past, we mix them up in process model notation because we lacked an alternative. The mixed up convoluted process
models consume conference room walls and become complex. In some places, they impose unnecessary and arbitrary
sequence. Worse, they create a maintenance headache despite good intentions.
While some people have been delivering decision models for awhile now, admittedly decision models are new to most
organizations. No one reading this column should feel behind the times.
Once you start delivering both process models and decision models, you will be able to:
Update one without interfering with the other
Reduce process models to simplest form
Pull all business logic (of business rules) together in one place (rather than scatter it across wrong places)
Reuse business decisions in multiple processes
Create customized views of the same decision logic whereby a process model calls a different view of a decision model as
appropriate
Deploy advanced and sophisticated technology in an optimum manner: BRMS[11] , BPMS[12] , and BDMS
Give more control to business people to govern and change the logic behind business decisions.
-9-
The Decision Model and Process Models with BPMN
Before the introduction of the Decision Model, the distinction between the procedural nature of process and the declarative
nature of logic was unclear. However, once you grasp it, it is hard to let it go. When this happens, you will feel very comfortable
with two models - one for only process and one for only business logic.
[1]. “Business Process Models and Business Rules: How They Should Work Together”
[2]. Sometimes, identifiers point to groups of business rule expressions or to a decision table instead of individual business rules.
[3]. For details on this particular decision model, see “Three Reasons to Upgrade from Business Rules to Decision Models”
[4]. http://www.omg.org/
[5.] BPMN Method & Style, Bruce Silver 2009. The levels of business process models, proposed originally by Silver have been
adopted by OMG and are emerging as an industry standard. For more information from Bruce Silver on Business Process
Management, see http://www.brsilver.com/bruce-silver-associates/
[6]. We always conduct a small pilot for a given scope, selecting one to three decision models and getting started with them. By
doing so, we capture productivity metrics of the team. These include quantity hours for process model iteration, Decision
Model Diagram, Rule Family, Fact Type, analysis, validation and testing. We use these as input to the full project plan.
[7]. At this point, we would update Table 2 with characteristics for both views.
[8.] When creating multiple views for a decision model, it is always best to start with the one most common. This allows for faster
development of other views since they may contain only minor differences from the most common one.
[9]. For more information on the use of decision models for data quality, see “Better, Faster Cheaper Part II – The Decision
Model Meets Data Quality Head On”
[10]. The special environments are possible through use of a Business Decision Management System (a new class of software
aimed at supporting safely the entire management cycle from business change to decision models, impact analysis, testing,
and deployment by non-technical people)
[11]. Business Rule Management System (also known as Business Rule Engine)
[12]. Business Process Management System
- 10 -
The Decision Model and Process Models with BPMN
Larry Goldberg 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 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.
Contact us
For more information please visit us:
www.sapiensdecision.com
[email protected]
+ 1-800-858-9473 (US)
+ 44 1895 464 000 (UK)
Published in: www.modernanalyst.com, January 02, 2010
© 2014 Copyright Sapiens International. All Rights Reserved. Dec. 2014
- 11 -