How to Introduce The Decision Model Successfully


The Decision Model finds its way into organizations in many different ways: through a Center of Excellence, a pending crisis or opportunity, an inspired individual, or a small investigative group.

Regardless, all paths to organizational decision modeling encounter a common question: How do you introduce The Decision Model into an organization? More specifically, how do you gain management attention for delivering decision models as a standard practice? This month’s column addresses that question.

How to Spread the Word About Decision Models

The answer comes from the collective experience of clients and partners. Based on their success, this column describes a presentation for introducing The Decision Model to a management audience. The column starts with the goals of the presentation. It then provides insight on turning it into a visual story targeted at your organization’s needs. Working through the agenda, the remainder of the column highlights the most important points.

The Goals of the Presentation

In essence, a management presentation on The Decision Model has four goals: (1) confirm the advantages and disadvantages of your organization’s business rule practices (2) introduce The Decision Model as a significant advancement to overcome the disadvantages, (3) explain how easy it is to interpret a simple decision model and, most important of all, (4) present in step by step fashion, a decision model built from real business rules within your organization.

Nothing helps an audience grasp a new concept as much as showing precisely and simply how it applies directly to something they struggle with. Your decision model will solidify the tangible advantages of The Decision Model related directly to your organization’s struggles. If your organization’s reaction is similar to others, your model may be the beginning of a revolutionary shift in business governance.

Your Organization’s Story

It is of utmost importance that you tailor the presentation to your organization. You will need to do some preparation. The first preparation task is to identify current business rule practices in your organization, including advantages and disadvantages. These will be the common ground on which the presentation starts.

The second preparation task is the most important. It is to produce a decision model diagram using as input a current set of business rules. It need not be a complicated decision model diagram. However, it must begin with the decision octagon. The decision octagon raises awareness beyond the idea of individual business rules to the more strategic level of an entire business decision. The decision model diagram must also contain at least one complete logic branch. In other words, at least one logic branch must end with all conditions below the dotted line because the values for these conditions are provided as raw input. This reveals the fundamental connections within a decision model and how a decision model exposes its level of completeness.

You must also create one or more Rule Family tables for your decision model populated from yourbusiness rules. There is no need to create all of the Rule Families, a good sampling will do. These ensure that the audience connects with the decision model structure through its content.

Additionally, create a corresponding business glossary, although it can be a partial glossary. The intention is for the audience to welcome the business glossary as a business-friendly non-technical artifact that also serves the technical audience.

Finally, to put your decision model in proper business context, create a decision-aware business process model in which it would execute. Your process model will illustrate that decision models improve business process representation and execution. You may want to get buy-in during preparation from process modelers because decision models will have a very constructive impact on process models.

The Recommended Presentation Agenda

Figure 1 contains a well-practiced agenda.

  Decision Model: The Recommended Presentation Agenda

Figure 1: Typical Management Presentation Agenda

The remainder of this column presents details behind each part of the agenda. It provides a general description of Parts 1 and 2. It goes into more details for your decision model in Part 3. It suggests important points for Part 4 so that the audience grasps the full vision for adopting decision modeling as a standard practice.

Part 1: Current Business Rule Practices

As indicated above, Part 1 starts by discussing how your organization manages business rules currently.

1a. How Your Organization Does It Now

This creates a common ground of familiar struggles. It is important to assure the audience that your organization is not alone. Its business rule practices are similar to those of other organizations.

For your reference, the table below contains the most common current practices. However, your presentation should focus on those of your organization.

Most Common Practices

  • Analysts start to capture business input from subject matter experts during requirements but often continue into testing.
  • Analysts translate the business input meticulously into more precise textual statements or special grammatical syntax.
  • Developers translate the textual or grammatical representations into executable code for a target environment.
  • Business people test the executable code and discover errors.
  • Business experts, business analysts, and developers participate in rework.

1b. Advantages

In preparing for your presentation, study the common advantages in the table below. Yet, present only those pertaining to your organization’s success stories.

Common Advantages
  • Encourages the separation of business rules from other aspects of requirements, systems, business processes.
  • Involves important participation by business experts.
  • Provides for different kinds of expressions for different kinds of business rules.
  • Makes possible the use of using existing software tools to store them, such as requirements tools.
  • Enables the automation of business rules in specialized technology (e.g., BRMS products).


1c. Disadvantages

Common disadvantages are listed below, but, again; present those most familiar to your audience.

Common Disadvantages

  • It takes a long time to do the translation from business input to another form.
  • The translated representation often is unintuitive to business people, so not well understood.
  • If data-centric models are required for expressing business rules, business rule capture slows down or is delayed significantly.
  • It is difficult, if not impossible, to estimate the effort of business rule capture or to know when it is finished.
  • Despite separating business rules from process models, the process models are still complex.
  • Business rule capture and management does not attract the management attention it deserves.
  • Business rule capture continues into design, development, and testing.
  • There is little successful planning for how to continue to manage change to the business rules and usually ends up being IT.
  • Even when automated in BRMS technology, the business rules are disconnected from the original translation and lost to the business.
  • There is still a gap between business and IT in the capture, automation, and testing of business rules.
  • Rework is often extensive and costly.
  • Some business rules are never captured properly because they are buried in process models, use cases as process tasks or use case steps.

Part 2: The Decision Model

Part 2 introduces The Decision Model by stating that it arose precisely because of the universal disadvantages across organizations. There had to be a better way.

2a. Motivation

This part of the presentation should confirm there has been little success in the universal separation of the “business rules” dimension from all other dimensions of a system or business process. It should point out that this is not for lack of trying. These frustrations have existed for decades.

The Decision Model as the solution, is not simply just another change in business rules approaches. It is a completely new (and simpler) way of thinking about them.

2b. Business Rules Turned Into Business Logic

Part 2 instructs that The Decision Model turns “business rules” into “business logic” based on rigorous but simple principles. Business logic is nothing more than correlating conditions to conclusions in a specific manner. So it is very easy for all audiences to understand.

There are no special classifications of business rules and no special grammatical syntax. Further, The Decision Model materializes natural connections among tables of well-formed business logic. These connections create a precisely-defined, predictable model-based configuration that is easy to understand. It is no accident that each decision modeler, given the same input, will produce the same or similar representation!

The result is that The Decision Model delivers a significantly more successful, higher quality, strategic, and business-empowered solution.

2c. Impact on Business Process Models

Part 2 also makes a comparison between two kinds of process models. One is a common business-rule-oriented process model pointing to lists of business rules. The other is the new world of a decision-model-oriented process model pointing to entire decision models. By comparing these process models, the audience observes first hand, a tangible and radical difference. The complexity of the first compared to the simplicity of the second is startling in good way. The audience will realize that decision models have an uncanny way of streamlining business processes. There emerges a clean separation of process models and decision models resulting in greater business agility.

2d. Decision Model Organization and Principles

Part 2 describes the decision model diagram and simple examples of business rules turned into business logic in Rule Family tables.

One way to create content for Part 2 of your presentation is to refer in the book[1] to Chapter 1 (Why The Decision Model) and Chapter 2 (An Overview of The Decision Model). Another way is to download the primer from under the tab labeled “The Decision Model.”

2d. Decision Models in Other Organizations

Part 2 ends by specifying the many ways other organizations are already using decision models in large production systems. Examples are below. The important point is that The Decision Model is no longer a new idea and its adoption is spreading across all industries with unprecedented success stories.

What Organizations are Using Decision Models For

  • Compliance decisions
  • Eligibility decisions
  • General business logic (claim payments, membership in healthcare plans, policy renewal)
  • Underwriting logic
  • Risk logic for defaulting assets
  • Data quality logic

Once the audience has an understanding of The Decision Model and its adoption, they will be curious about its usage for your organization.

Part 3: Your Example

This is the most important part of the presentation. We use a fictitious example below, but you should use your example. The idea is to leadingthe audience through the following: current business process model, current business rule capture, your decision model diagram, Rule Families, business glossary, and decision-aware business process.

Below is an explanation of how to step through the topics using our example, so you can plan how to do so for yours.

3a. Business Process Model (Current)

Start by sharing a business process model for your example and explaining how it relates to corresponding business rules[2] . Figure 2 is our example of a business process model relating to business rules. In our process model, most business rules appear as pointers leading to a business rule repository. The business rule repository could be a requirements tool, or MS/Office document. Other business rules appear as activities in the process model. In fact, parts of some business rules appear as process activities. Misrepresenting business rules or parts of them as process activities is commonplace when process models relate to business rules and not to decision models.

Your business process model may relate to its business rules in some of these ways or in other ways. Regardless, remind your audience that business process models unaware of decision models are unnecessarily complex. They render the business rules invisible and disorganized. Now they see it in their own environment.

   Decision Model: Sample Business Process Model Pointing to Business Rules

Figure 2: Sample Business Process Model Pointing to Business Rules

3b. Business Rule Capture (Current)

Next share your selected business rules in whatever format they currently exist. Because the most common format is a business rule spreadsheet, our example includes one in Figure 3. It resembles many we have seen in that it contains textual business rules, organized in a project-specific fashion. This business rule spreadsheet purposely contains common suboptimal business rule practices for illustration purposes. Use business rules in your example and point out similar suboptimal practices. Let’s walk through some from our example.


Rule Number Rule Text Rule Group Result Value
434 Policies in Tier 1 or below are never considered to have a policy price within bounds Policy price Out of bounds
537 If a policies in in Tier 1.5 with a policy discount greater than 10% then it is  considered to have a policy price within bounds Policy price In bounds
543 When a  policy is up for renewal but there is an override by an underwriter then its renewal must go through an underwriter Policy renewal type Manual
4326 Policies in tier higher than 2.6 are always considered to have a policy pricing within bounds Policy Price In bounds
63 Policies that require manual renewal should be routed to the appropriate underwriter based on the customer and underwriter workload Routing Underwriter renewal
491 A policy in a tier <=1 never has a Policy Pricing Within Bounds and those in a Policy Tier > 2.6 always do. Policy Price

In bounds

Not in bounds
1024 If a Policy Underwriting Risk is standard and the Policy Pricing is within Bounds and no underwriter has flagged it, the Policy can be renewed by the automatic system, otherwise not.    

Figure 3: Sample Business Rule Spreadsheet with Suboptimal Practices

In Figure 3,the Rule Texts take on various forms. There is an if/then statement for Rule Numbers 537 and 1024, a when/then statement for Rule Number 543, and process instructions for Rule Number 63. The Rule Group column sometimes indicates a conclusion reached by the Rule Text (e.g., a conclusion for Policy Price). Sometimes it indicates a type of rule (e.g., a routing rule). Rule Number 491 is actually more than one (atomic) rule indicated by the “and” connecting different conditions to a different conclusion. Rule Number 1024 is also more than one atomic rule. Its use of “otherwise” is a way to avoid specifying the “otherwise” conditions. Unfortunately, this leaves them up to interpretation. Rule Number 1024 overlaps with 543.

In many cases, a business rule spreadsheet also contains a column for the corresponding snippet of program code for the Rule Text. Imagine the surprise when sometimes the code doesn’t accurately reflect the Rule Text. Perhaps this mismatch existed from the beginning. Or maybe subsequent updates made it so. Also common is a business rule spreadsheet containing a column for the related error message. Believe it or not, sometimes the message does not match the Rule Text. In some cases, it may not even match the code snippet.

To be fair, business rule capture in some organizations have more rigor than those in Figure 3and therefore have fewer of these issues. However, regardless of format, business rule capture and maintenance is error prone and tedious. If this is true for your example, point these out, especially those that led to extensive rework.

3c. Decision Model Diagram and Rule Families (Future)

For the next step, make the transition to your decision model diagram. Figure 4is a partial decision model for our example showing two Rule Family tables based on business rules in Figure 3. Use your business rules as the basis for a similar diagram.

Point out how your decision model diagram “matches” the content of Rule Families. Also point out how the decision model diagram indicates the presence of logic branches through the role of supporting Rule Families. In our example, Figure 4indicates the need for two branches of logic: one for Policy Pricing Within Bounds and another for Policy Underwriting Risk.

 Decision Model: Partial Logic Branch for Business Rules from the Spreadsheet

Figure 4: Partial Logic Branch for Business Rules from the Spreadsheet.

Figure 4shows only part of the left logic branch and that there is one more Rule Family (i.e. Policy Discount) for it. Therefore, Figure 5 shows the completion of the left logic branch because the bottom level Rule Family shows all conditions below the dotted line.


   Decision Model: Complete Left Logic Branch

Figure 5: Complete Left Logic Branch

At this point, walk the audience through the activity of adding a logic branch until your decision model diagram is complete. Let’s do so for our example so you can see how to do so with yours.

Figure 5 contains one logic branch but needs another for Policy Underwriting Risk. Searching our business rule spreadsheet (or better yet, working with underwriters), this risk considers whether the Policy Holder has had any changes sufficient to increase risk. What kinds of changes are these? These are changes in location and ownership. So, Figure 6 contains a branch for all of these supporting Rule Family structures. Annotate your decision model diagram with callouts or other graphical notation to highlight the orderly arrangement of connected Rule Families. Remind the audience that this arrangement results from decision model principles.

In Figure 6, the bottom level of both branches ends with Rule Family structures where all conditions are below the dotted lines. So, the values for these conditions are raw input data; there is no more logic (i.e., no more rules) for this decision model. The decision model is complete. Using your decision model, point to the Rule Families where all conditions are below the dotted line.

Remind the audience how easy it is to determine, from a decision model diagram, when a decision model is complete, or how incomplete it is.


   Decision Model Diagram with Another Logic Branch

Figure 6: Decision Model Diagram with Another Logic Branch

Figure 7 shows a more complex example, based on a real-world scenario. This one represents a decision to determine eligibility for disabled student allowances. The callouts illustrate how nicely the logic organizes into branches for undergraduate, postgraduate, physical disabilities, mental health disabilities, and learning difficulty disabilities. Maintaining the logic for all of these is straight-forward with the decision model representation.

  Real-World Decision Model Diagram for Disabled Student Allowances Eligibility

Figure 7: Real-World Decision Model Diagram for Disabled Student Allowances Eligibility.

3d. Business Glossary (Future)

It is important to introduce a business glossary for your decision model because it reinforces the glossary as a tool for business audiences. Review the business-friendly names, definitions, and a full set of values for some column headings. Figure 8 contains a partial business glossary for our example, but yours will be for your example.

  Decision Model: Sample Partial Business Glossary

Figure 8: Sample Partial Business Glossary

This is the point to announce that there is absolutely no need for object models, data models, or fact models to define, populate, validate, generate test cases for and execute test cases for decision models. The business glossary items have business names, without concern for how these items exist in software or databases. Instead, decision modeling focuses entirely on business people specifying their business logic in the way they intend it to be, correct, complete, and minimally redundant.

Also important, though, is that the business glossary is the glue connecting the business audience to the technical audience. The business audience governs the business logic while the technical audience automates it. When a decision model is targeted for automation, a technical professional cross-references to data models and object models. But this connection happens after the business specifies and tests the logic in vocabulary that they understand.

3e. Decision-Aware Business Process (Future)

At this point, revisit the project-specific business process model, this time explaining that it is simpler because it is aware of decision models. Figure 9is our example indicating how a process task connects to an entire decision model. Again, include your decision-aware process model. Note that the clean separation between process and decision models enables one to change without changing the other. Emphasize that this clear separation is possible only when the process modeling and decision modeling happen together and not independent of each other.

   Revised Simplified Business Process Model with Decision Model Anchors

Figure 9: Revised Simplified Business Process Model with Decision Model Anchors

Part 4: Wrap Up

Your audience has now seen the potential for significant productivity and quality improvements with decision models. It is a good place to share real-world statistics.

4a. Accelerated Productivity

As a result of The Decision Model and its independence of technology considerations, organizations achieve productivity and quality in business rule management never seen before.

Figure 10contains statistics for a real-world project in a major organization with several years of decision modeling experience. The top bar in Figure 10 represents productivity numbers resulting from their original business rules approach. The second bar represents productivity numbers when they replaced business rules with decision models, but without supporting software. The third bar presents even greater productivity numbers when using software for creating decision models, finding logic errors, generating and executing test cases (all without object models or data models).

4b. True Technology and Vendor Independence

Often business rule capture and management leads to dependency on a vendor or technology. Even so, change management can be very time, resource, and cost intensive. With decision models, this is different.

Not only are decision models devoid of technical considerations, the principles result in logic structures that can execute in any current or future technology. This means one decision model can deploy to multiple technologies. Newly available software products allow an organization to repurpose decision model content to any execution system with little effort, offering technology and vendor independence and future migration paths.


Figure 10: Real-World Decision Model Productivity Improvements

4c. Active Business Governance

From Figure 10, the audience may begin to imagine a new world. In this new world, non-technical people create, validate for logic errors, and test decision models without needing object or data models and prior to turning them over to IT for automation. This is a ground-breaking reality, closing the gap between business and IT.

With The Decision Model the business becomes self-sufficient regardless of technology. The business creates decision models in exactly the same way whether those models deploy to a policy manual for human execution, to home-grown software, to a commercial engine or to multiple automation environments.

Once your audience understands this shift in business governance, pause for a moment. Then, revisit from the beginning of the presentation, the disadvantages of your organization’s current practices. Ask the audience which of these disadvantages disappears with decision models. Elaborate on how The Decision Model differs from their current approach as seen in its advantages below.

Decision Model Advantages

  • There is only one representation.
  • There is no translation into special grammar, templates, or spreadsheets.
  • The column headings have business-given names and definitions.
  • There are no required models (data models, fact models, object models).
  • Decision model software validates models against all principles for logic errors without deploying them to technology, long before testing.
  • Decision model software generates test cases, executes them, and notifies of incorrect results without the overhead of deploying them to target technology.
  • Decision models are technology-agnostic deployable anywhere and in multiple places.


4d. Present and Future in a Nutshell

Finally, present a graphical representation of current practices as in Figure 11. It shows a process model that is not decision-aware and a set of business rule spreadsheets, partly or mostly maintained by technical people.

  Business Rule Practices Without the Decision Model

Figure 11: Business Rule Practices Without The Decision Model

Present the changes in Figure 12. It contains the simpler decision-aware process model, decision models, Rule Families, and error-free tested business logic, governed by the business.

  Business Rule Practices with The Decision Model

Figure 12: Business Rule Practices with The Decision Model

4c. Nothing to Lose

At the end of the presentation, leave the audience with the following four thoughts.

  • The Decision Model delivers business logic as a living business asset governed by business people.
  • There are no risks in delivering decision models.
  • At a minimum, an organization creates decision models in MS/Visio and MS/Excel using free templates from Technology-driven organizations evaluate supporting software up front.
  • Either way, decision models fill the gap that has never been filled before.

What is there to lose?

Authors: 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

[1]von Halle, Barbara and Larry Goldberg, The Decision Model: A Business Logic Framework Linking Business and Technology, © 2009 Auerbach Publications/Taylor & Francis, LLC.
[2]If the target project does not have a business process model, start with how the project captures business rules, described in the next paragraph.




Like this article:
  6 members liked this article


jonex posted on Wednesday, March 13, 2013 8:50 AM
We're practicing process modeling and rules modeling as two different concerns connected with each other using service modeling. This works great as a driver for change and for a better understanding on how to implement that change, whether it has impacting on our organization or IT. The big question though is ownership and lifecycle management of those models. Governance is very tough for us to accomplish in our decentralized organization. Should we try to centralize ownership and practice that from within a CoE instead?
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC