The Five Most Important Differences Between The Decision Model and Business Rules Approaches

Registration is free. Login or register to view/download this content.


Managing Partner, Knowledge Partners International LLP
Larry Goldberg has over forty years of experience in building technology based companies, focused on rule-based technologies and applications. Prior to joining KPI as Managing Partner, he was Senior Vice President of Sapiens Americas, Inc., which he joined when he sold his company, PowerFlex Software Systems, Inc to Sapiens. Larry is co-editor of “The Business Rules Revolution” (Happy About, 2006), co-author of “The Decision Model - A Business Logic Framework Linking Business and Technology” (Auerbach, 2009) and co-developer of The Decision Model. Larry also served as the Editorial Director of's “BDM Bulletin” until 2013.

While many organizations have adopted The Decision Model, others are actively exploring how it may improve or totally replace their current business rules approaches.  The latter are asking the critical question:

How is The Decision is Model different from what we are doing and why are these differences important?

This month’s column answers that question. It starts by summarizing business rules approaches.  It then explains the five most important differences and their benefits.  It ends with how these five differences have changed real world projects and culture.

The differences are extremely important.  They are not by accident!

Business Rules Approaches

For the purpose of this column, there are three general types of business rules approaches: (a) from business engine software vendors (e.g., BRMS, BPMS), (b) from consultants or consulting companies independent of business engine software, and (c) within corporate organizations who create customized businesses rule management.

Common practice among all three types is translation of business sources into a communicable form, often a set of business rules or business rules statements. There are various formats: free-form text, fill-the-blank templates, decision tables, decision trees, and rigorous grammar.  Software support for storing business rules for the first type is usually a proprietary front-end interface, aiming to be non-technical, to a commercial engine.  Supporting software for the second type is usually a business rule repository independent of a commercial engine.  Supporting software for the third type may be a combination of vendor-supplied and home-grown software.
Also common is that data referenced in business rule representations is modeled in data-centric models (e.g., data models, object models, fact models).  In some approaches, these models must exist before writing business rules because business rule expressions must reference fact types or data elements from the associated data-centric models.

Common Hurdles

Most people believe that business rules are an important consideration in implementing change and delivering enterprise agility.  However, in today’s world of rapid change and pressure, there are common hurdles that, too often, get in the way of optimum success.  The hurdles we hear most often are:

  • It takes a long time to translate business sources statements into special grammar or templates.
  • The creation of a data-centric model (e.g., data model, object model, fact model) slows down the business rule translation process.
  • It is difficult to estimate the effort to capture all business rules for a given scope or to know when the task is done and they are complete.
  • Despite separating business rules from business process models, business process models are still complex.
  • Business rule management does not get the management attention it deserves.
  • Business rule capture starts before or during requirements, but often continues in design, and completes in development.
  • Even when automated in BRMS, the business rules are lost to the business people.
  • There is still a gap between business and IT in delivering automated business rules.

The Five Most Important Differences in The Decision Model

With a desire for a universal representation and with these hurdles in mind, The Decision Model needed to accomplish two goals.  The first was to introduce a new, simple formalism understandable by everyone.  The second was to eliminate all impediments (i.e., those hurdles) to true business-empowered governance.
Table 1 summarizes the five differences that reach these goals.

Five Decision Model Differences Description
#1: Formal Notion of Decision The Decision Model is a technique for elevating the role of business rule management to that of business decision management.
#2: Formal Model The Decision Model is a rigorous model; its theoretical foundation defined by 15 principles.
#3: Model-Based Functionality As a holistic model, a decision model lends itself to model-oriented functionality that is not possible with lists or group of business rules or single logic tables.
#4: Decision Model-Based Software Innovator The Decision Model has already spurred software innovations, some not possible in the other approaches and more are expected.
#5: Pure Business Audience-Driven The Decision Model is the first approach designed from the perspective of pure business interaction and governance.

Table 1 : Summary of Five Decision Model Differences

Difference #1: Formal Notion of Decision

The Decision Model is a technique for elevating the role of business rule management to that of business decision management.
The shift in focus to business decision from individual business rules is significant.  It changes the business person’s emphasis from writing business rules to the important business task of evaluating and measuring the impact of business decisions on the business.

Why This Difference is Important

  • The formal notion of decision a higher level business asset than that of a business rule.
  • Decision models attract management attention because they represent business decisions that matter most to the business.
  • By identifying business decisions up front, business leaders determine their value to business performance, survival, and how to measure and tune their impact.
  • Identification of business decisions enables accurate scoping to determine the level of effort (LOE) to deliver or change each one.
  • The scope of a business decision is smaller than that of an entire project or process model, providing a clearly defined way of dividing up the task of collecting business rules or logic.
  • Business decisions become anchors in business process models, thereby significantly simplifying the process models. Figure 1 illustrates how business decision anchors simplify business process models.

Figure 1.1 and 1.2: Simplification of Business Process Model with Decision Anchors

In a real-world project, simplification became obvious when the quantity of business process models for the entire project reduced from 25 to 10.  Some of those process models became reusable elsewhere and most of the decision models became candidates for reuse.

Difference #2: Formal Model

The Decision Model is a rigorous model; its theoretical foundation defined by 15 principles.

The Decision Model, as a new model, is the result of rethinking the problem and learning from history.  It brings to the world of business rules a well-defined structure based on the inherent nature of logic, extended with integrity and normalization principles.  This is similar in concept to what the Relational Model brings to the world of data.

The Decision Model, despite its rigor, is a step towards simplicity.  Simplicity implies that a decision model represents business rules and logic using only a few, familiar concepts.  While based on theory, anyone can understand a decision model even if unfamiliar with its theory.  The combination of simplicity and solid theory makes it valuable and long lasting.

Why This Difference is Important

  • Decision models quickly become interesting, manageable, and valuable business assets.
  • As a repeatable visual representation, people detect errors by studying decision models or by executing software that instantaneously finds all logic errors in an entire decision model.
  • Each has a definite starting and end point
  • Each delivers a conclusion to one decision
  • Each is similar to all others due to universal notation
  • Yet each has its own distinct shape and characteristics.
  • Each has a smaller scope than most other business analysis and even automatable deliverable.
  • Many fit on one to two pages.

Figure 2 contains three decision models of different sizes and shapes.

Figure 2.1, 2.2, and 2.3: Three Different Decision Models

The real-world project above originally delivered 250 random groups of business rules which reduced to 20 decisions totally comprised of 51 normalized Rule Families in third normal form.  It also took much less time to create the simplified business process models, normalized decision models compared to the original combined deliverables that were ultimately abandoned as unmanageable.  In addition, it was easier to implement the decision models in the target technology than the original groups of business rules.

Difference #3: Model-Based Functionality

As a holistic model, a decision model lends itself to model-oriented functionality that is not possible with lists or group of business rules or single logic tables.

As history has shown us, a rigorous model provides extremely useful functionality, such cut, copy, paste, compare, version, and customize.

Why This Difference is Important

Major areas of decision model-driven functionality are the following:

  • Decision Model Views: different views of a decision model for representing different business needs across geography, political boundaries, and special customer needs.
  • Decision Model Reuse: opportunities for reuse of decision model views across an enterprise and even external.
  • Decision Model Management: comparison of one decision model to another, one version to another, highlighted differences, versioning, and simultaneous updates to an entire decision model.
  • Decision Model Testing: development of minimal model-driven test cases to ensure correctness of the logic in an entire decision model.
  • Decision Model Message Management: development of messaging architecture across an entire decision model.
  • Decision Model Quality Management: automated validation of whole decision models against all 15 principles.

Difference #4: Decision Model-Based Software Innovator

The Decision Model has already spurred software innovations, some not possible in the other approaches and more are expected.
In 2009, we proposed that The Decision Model’s greatest significance may be its potential to inspire new technology and business directions.  Shortly after the book publication, the ability to create decision models began to appear in modeling and requirements-oriented tools.
Most recently, a new kind of software called a BDMS is available.  BDMS stands for Business Decision Management System .

Why this Difference is Important

BDMS is not simply a decision modeling tool or a front-end to a particular BRMS.  A BDMS supports customizable full life cycle business-to-IT governance of business decisions and decision model deployment. Figure 3 shows a sample governance workflow.

  • The full life cycle starts with a business directive or change.
  • A business person defines a customized governance workflow for approvals from specification to testing to production.
  • The life cycle continues with decision model creation or change.
  • It progresses to automatic validation of entire decision models against the 15 principles, detecting all logic errors .
  • It includes full decision model testing.
  • Items 1-5 happen before turning decision models over to IT.
  • Adaptors for deploying on target technology platforms deliver a life cycle that if finally complete and fast.
  • Decision Models emerge as a technology-independent business-friendly asset manageable by business people.
  • A decision model is deployable to multiple technology platforms, useful for evaluating different product, migrating to another platform, and leveraging future technology as it emerges.
  • An organization is no longer tied to a particular platform or vendor.
  • Experience shows that decision models improve BRMS performance.

Figure 3 : Simple Governance Workflow for Decision Models within a Business Initiative or Change

Difference #5: Pure Business Audience-Driven

The Decision Model is the first approach designed from the perspective of pure business interaction and governance.
By design, The Decision Model is a tool for business audiences.  This means business people or analysts create, validate, and change decision models without any other skills.  For instance, a data-centric model is not a pre-requisite. The only requirement is to understand basic decision model notation and create a simple glossary of terms.  Nothing more.

Why This Difference is Important

The emphasis on pure business interaction renders decision models that are easily understood by anyone, devoid of technical artifacts.

  • The Decision Model doesn’t require conditions and conclusions to exist in data-centric models because business people don’t need these to specify and validate logic.  While automation to a production environment may require these models, a correlation from decision models to data stores can happen later.  There is no reason to delay decision model creation. The focus is first on specifying the logic and validating its integrity and later on its connections to data stores.
  • There is no need to translate business sources into grammar or language-based statements.  Translation to rows in Rule Families is quick and easy and suffices.
  • The Decision Model approach supports (actually, encourages) dynamic creation, meaning minimum rigidity during creation time.  This means names, definitions, and domains of conditions and conclusions need not be complete or approved while creating a decision model.  In fact, they will change many times until a decision model is ready for approval.
  • Decision models require minimal glossary information for conditions and conclusions, such as a business-friendly name (no forcing unnatural names), definition, and full set of values.
  • Decision models allow flexibility for true business logic.  This includes multi-hit Rule Families and conclusions and conditions that are sets of values because the business needs these things

How These Differences Have Changed Real Projects and Culture

The result of these five differences is that creation of, and changes to, decision models is faster and delivers higher quality than other approaches.  It is common for decision model organizations to create, validate, test, and deploy decision models in 50% of the time it takes with other approaches.  Use of BDMS software is even more impressive.
Adding up the benefits of the five differences, it is easy to see why such success becomes possible:
The Decision Model advantages:

  • There is only one representation to learn.
  • There is no need to translate source statements into special grammar or templates.
  • There is no need to create data-centric models before creating decision models.
  • Creating a decision model happens top down, bottom up, and in between.
  • Top down from business decisions enables prioritization and parallel development.
  • Starting and end points are well-defined so everyone knows when a decision model is complete or what percentage is finished.
  • The scope of a decision model is small compared to the scope of a list of business rules.
  • It is easy to find in a decision model exactly where changes need to occur because there is only one place defined by normalization.
  • Decision models are easily automated into today’s BRMS technology.
  • Different views of the same decision model maximize reuse and minimize rework.

BDMS advantages:

  • Statistics assist in estimating LOE of a specific decision model creation or change.
  • Adaptors to BRMS technology make deployment almost seamless.
  • Customized governance workflows enforce business and IT roles for the full life cycle.
  • Automated detection of decision model principles finds all logic errors in an entire decision model almost instantaneously.
  • Generation and execution of full model test cases happens without IT intervention.

Not just Another Business Rules Approach

The Decision Model is not just another Business Rules Approach.  Rather, it is designed from the beginning to break the boundaries and frustrations of existing business rules approaches without losing benefits of separation.  The Decision Model has already signaled a whole new generation of methodology, governance technology, and future automation technology.

If the past two years since publication of the book are an indication, a new generation of enterprise is emerging, truly driven by the business and powered by The Decision Model.


Sapiens DECISION is a BDMS that automates all principles of The Decision Model.

Similar Resources