The Decision Model – December 2012

This month’s column summarizes current business rules approaches. It then explains the five decision model differences and why each difference is important. It ends with how these five differences have changed the success of real world projects and transformed business and IT culture.

The differences are extremely important. And they are not by accident!

Current Business Rules Approaches

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

Three Characteristics of Business Rules Approaches

At the core of all three types of business rules approaches are three common characteristics.

  1. Translation from source to target expression: All three types of business rules approaches include a translation of business intentions or sources into a communicable form, often a set of business rules or business rule statements. These take on various formats: free-form text, fill-the-blank templates, decision tables, decision trees, and rigorous grammar.
  2. Software support: Software for capturing business rules for the first type is usually a proprietary non-technical interface 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 is often a combination of vendor-supplied and home-grown software.
  3. Data references: Another commonality across these three approaches is that data referenced in business rule expressions exists in data-centric models (e.g., data models, object models, fact models). In some approaches, if not all, a data-centric model must exist prior to, or in parallel with, writing business rules statements because the business rule statements must reference fact types or data elements from the data-centric model. In other words, translation from the original source to a business rule statement cannot start until the corresponding data-centric model is produced.

Common Hurdles

In today’s world of rapid change and pressure, the common business rules approaches face hurdles that, too often, get in the way of optimum success. The ones we hear most often are:

  • It takes a long time to translate business intentions or business policies into special (sometimes unintuitive) 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 and business people lose patience.
  • It is difficult to estimate how long it will take to capture all business rules for a given scope or even to know when the capture is finished and the business rules are complete.
  • Despite separating business rules from business process models, business process models are still complex.
  • The idea of managing business rules does not attract the attention it deserves from upper management.
  • While everyone agrees that business rule capture should start and end before or during requirements, it always continues in design, if not into development or, worse, into testing.
  • Even when automated in BRMS, the business rules are all too quickly lost to the business people. So, separation happens but the connection from business to technology is broken.
  • There is still a gap between business and IT into delivering automated business rules.

The Five Most Important Differences in The Decision Model

If you have experienced any of these hurdles, you will appreciate that The Decision Model set out to minimize, if not eliminate, these hurdles. The Decision Model does this in two ways. First it delivers only one simple rigorous formalism understandable by everyone. Second, it eliminates the impediments standing in the way of the highest productivity, maximum agility, and true business-empowered governance. Table 1 summarizes the five differences that differentiate it from business rules approaches.

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 rule statements to the more important task of evaluating and measuring the impact of business decisions on the business.

Why This Difference is Important

  1. The formal notion of decision is a higher level business asset than that of a business rule.
  2. Decision models attract management attention because they represent business decisions that matter most to the business.
  3. By identifying business decisions up front, business leaders determine their value to business performance, survival, and how to measure and tune their impact.
  4. Identification of business decisions enables accurate scoping to determine the level of effort (LOE) to deliver or change each one.
  5. 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.
  6. 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: Simplification of Business Process Model with Decision Anchors

Real-World Testimony

As an example in a real-world project, 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 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

  1. Decision models quickly become interesting, manageable, and valuable business assets.
  2. 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.
  3. Each decision model has a definite starting and end point
  4. Each decision model delivers a conclusion to one decision
  5. Each decision model is similar to all others due to the universal notation
  6. Yet each decision model has its own distinct shape and characteristics reflecting its unique purpose.
  7. Each decision model has a smaller scope than most other business analysis deliverables and automation deliverables.
  8. Most decision models fit on one to two printed pages.

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

Figure 2: Three Different Decision Models

(mouse over image to enlarge)

Real-World Testimony

The real-world project mentioned above began as a traditional business rules approach. As such, it delivered over 250 random groups of business rules. These were highly unmanageable. By applying The Decision Model, the 250 random groups of business rules reduced to only 20 very manageable decisions comprised of 51 Rule Families in third normal form. Not only did it take less time to create (and change) the resulting simplified business process models and normalized decision models, but also they were more understandable to a wider range of audiences. As an added benefit, it was easier and quicker to implement the decision models in the target technology than were 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 proves, a rigorous model lends itself to familiar model-based functionality, such as cut, copy, paste, compare, version, and customize.

Why This Difference is Important

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

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

Difference #4: Decision Model-Based Software

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

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.

  1. The full life cycle starts with a business directive or change.
  2. A business person defines a customized governance workflow for approvals from specification to testing to production.
  3. The life cycle continues with decision model creation or change without the need for data models, object models, or fact models.
  4. It progresses to automatic validation of entire decision models against the 15 principles, detecting all logic errors.
  5. It includes automated full decision model testing.
  6. Items 1-5 happen before turning decision models over to IT.
  7. Adaptors for deploying on target technology platforms deliver a complete life cycle through to automation.
  8. Decision Models emerge as a technology-independent business-friendly asset manageable by business people.
  9. A decision model is deployable to multiple technology platforms, useful for evaluating different technology products, migrating to other platforms, and leveraging future technology as it emerges.
  10. An organization is no longer tied to a particular automation platform or vendor.
  11. Experience shows that decision models actually improve BRMS performance.
Figure 3: Simple Governance Workflow for Decision Models within a Business Initiative or Change

Difference #5: Business Audience Focus

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. As such, business people or analysts create, validate, and change decision models without any other skills. Recall that a data-centric model is not a pre-requisite to creating decision models. The only requirement is to understand basic decision model notation. Nothing more.

Why This Difference is Important

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

  1. The Decision Model does not require conditions and conclusions to exist in data-centric models because business people don’t need such models to specify and validate business logic. While automation to a production environment may require these models, a correlation from decision models to data stores happens later. There is no reason for decision model creation to depend on the existence of technical artifacts that are of no interest to business-oriented authors. The only focus is specifying the logic and validating its integrity, later come connections to data stores.
  2. There is no need to translate business sources into grammar or language-based statements. Translation to rows in Rule Families is quick, easy and proven sufficient.
  3. The Decision Model approach supports (actually, encourages) dynamic creation, meaning minimum rigidity during creation time. Believe it or not, names, definitions, and domains of conditions and conclusions need not be complete or approved while creating a decision model. Experience proves that they will change many times until a decision model is ready for approval.
  4. 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.

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 organizations to create, validate, test, and deploy decision models in 50% of the time it takes with other approaches. Use of BDMS software results in even more impressive productivity and quality.
Adding up the benefits of the five differences, it is easy to see why such success becomes possible.

The Decision Model advantages are:

  • There is only one representation.
  • There is no need to translate business intentions 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, so it is quite manageable.
  • 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.
  • Internal functions enable testing without the overhead of deployment.
  • Adaptors to BRMS technology make production 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 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.
Since publication of the book two years ago, adoption of The Decision Model is bringing about a new generation of enterprise.

End Note:

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

Share this post

Barbara von Halle

Barbara von Halle

Barb von Halle is Managing Partner of Knowledge Partners, Inc. (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 Taylor and Francis 2009. She is the fifth recipient of the Outstanding Individual Achievement Award from International DAMA, inducted into the Hall of Fame in 1995. Known as a business rules pioneer, she has consulted in this area for more than 10 years. She is an invited keynote speaker at conferences in the U.S. and Europe.

Her first book, Handbook of Relational Database Design has sold more than 21,000 copies. She was the most popular in Database Programming and Design magazine for manyÊ years.

Other book publications include Business Rules Applied and The Business Rule Revolution. Her recent article in Intelligent Enterprise magazine features case studies from Oregon State, Freddie Mac, Dell Financial Systems, and Pershing LLC.Ê

Barb can be found at where new announcements and materials on the Decision Model appear as well as a link to purchase The Decision Model: A Business Logic Framework Linking Business and Technology.

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept