insights for success - sapiens decision · the decision model principles lead to only one rigorous...

- 1 -

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.

- 2 -


PART 1: Business Rules and Process ModelsA 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.

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.

Figure 1: A Typical Process Model with Links to Business Rules

- 3 -


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 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]

Figure 2: Decision-Aware Process Model

- 4 -


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.

- 5 -


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 ScopeTask 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.

Business Performance Metrics: Evaluated every 90 daysExecutive Management Measurable Objectives

Executive Management Goal

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

Renewed policies automation to increase from 50% to 75%

Increase the percentage of automated renewed commercial auto insurance policies

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

Free up regional experts’ time by 20%

Increase time spent by regional experts on other kinds of tasks

Total quantity and percentage of renewed policies per regionRetention of renewable policies to increase from 60% to 90%

Increase the level of customer satisfaction regarding renewed commercial auto insurance policies

Average profitability of manually renewed policies per region Average profitability of automated renewed policies per region

Average profitability on new policies to be at least 20%

Maintain (do not increase) current risk level of renewed commercial auto insurance policies

Total revenue from renewed auto policies per regionRevenue from renewed commercial auto policies to increase by 15%

Increase the revenue from renewed commercial auto insurance policies

Table 1: Sample Business Motivations for a Project

- 6 -


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.

Task 2c. Take an educated guess about the characteristics of each decision model.

Figure 4: High Level Process Model

- 7 -


Example: Table 2 contains our best guess at size and complexity of the decision model for “Determine a Policy’s Renewal

Method.”

Assessment of Business Logic Complexity

Assessment of Quality of Sources

Assessment of Accessibility of Sources

Estimated Quantity of Reference Sources (people, documents, code)

Estimated Quantity of Rows per Rule Family

Estimated Quantity of Fact Types

Estimated Quantity of Rule Families

Target Decision

Simple but fact types are unknown and regional versus global issues are important

MediumMedium5020-100205-10Determine Policy Renewal Method

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 ModelsDevelop 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.

- 8 -


Figure 5: Completed Decision Model Diagram.

Policy Underwriting Risk

Policy Manual Flag

Policy Discontinued Agent

Policy Annual Premium

Insured Major Ownership Change

Insured Major Location Change

YesIsYesIs

YesIsYesIs

YesIs$32,000 Is greaterthan

YesIsYes

YesIsYesIsIs

YesIsNoIsNoIs$32,000Is Less than or equal to

NoIsNoIs

Table 3: One Rule Family

- 9 -


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 UpThe 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.

- 10 -


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

http://modernanalyst.com/Resources/Articles/tabid/115/ArticleType/ArticleView/ArticleID/1629/Default.aspx


http://www.omg.org

http://www.brsilver.com/bruce-silver-associates/



- 11 -

Published in: www.modernanalyst.com, January 02, 2010

© 2014 Copyright Sapiens International. All Rights Reserved. Dec. 2014


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.

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.

Contact usFor more information please visit us:

www.sapiensdecision.com

[email protected]

+ 1-800-858-9473 (US)

+ 44 1895 464 000 (UK)

http://www.sapiensdecision.com

insights for success - sapiens decision · the decision model principles lead to only one rigorous...

Documents