The Decision Model and Process Models with BPMN

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

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.

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.

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]

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.

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.

Table 1: Sample Business Motivations for a Project

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.

Example: Table 2 contains our best guess at size and complexity of the decision model for “Determine a Policy’s 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 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.

Table 3: One Rule Family

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.

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.

Author: Barbara von Halle and Larry Goldberg of Knowledge Partners International, LLC (KPI)

Larry Goldberg is Managing Partner of Knowledge Partners International, LLC (KPI), 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 Managing Partner of Knowledge Partners International, LLC (KPI). She 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 and Barb can be found at www.TheDecisionModel.com. 

[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