[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 pages shrunk to 1-3 pages. One business analyst 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 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 who are experienced or familiar with business rules and The Decision Model may want to skip to part 3.
PART 1: Business Rules and Process Models
There are 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 the one in Figure 1.
Figure 1: A Typical Process Model with Links to Rules
(mouseover image to enlarge)
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. 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 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 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.
Figure 3: Relationship from Process Model to Decision Model
(mouseover figure to enlarge)
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. As such, BPMN consists of shapes and connections with specific definitions and rules. BPMN includes standard task types. While, unfortunately, 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.
Bruce Silver , an expert on BPMN, states “The appropriate way to represent business decisions is through the use of an appropriately designated task, currently 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 that justify 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
Task 2a. Create a high-level process model (e.g., BPMN) for each business process in scope. Typically, it will decompose 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 at 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
(mouseover figure to enlarge)
Task 2c. Make an educated guess about the characteristics of each decision model so you can estimate the effort of building it.
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. Both views of this decision model, by definition, come to a conclusion about a Policy’s Renewal Method, but they will differ in their details. ur first priority is the World View.
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. Be sure data quality is checked prior to the decision tasks using the corresponding data. If, however, the process itself is to include data quality logic, be sure the logic executes in a task before related decision tasks. Especially, if the process uses decision models for data quality logic, place decision tasks for data quality logic in front of decision tasks for the corresponding business decisions.
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.
Figure 5: Completed Decison Model Diagram
(mouseover figure to enlarge)
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 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 mixed 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 a while now, 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 , BPMS , and BDMS
- Give more control to business people to govern and change the logic behind business decisions.
