The Five Most Important Differences Between The Decision Model and Business Rules Approaches (They are not by accident!)

While many organizations have already 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 Model different from what we are doing and why are these differences important?

This month’s column answers that question. First, it summarizes business rules approaches in practice today. It then explains the five most important decision model 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: from business engine software vendors (e.g., BRMS, BPMS), from consultants or consulting companies independent of business engine software, and from within corporate organizations who create customized businesses rule management.

The Core of Common Practice
Common among all three types is translation of business intentions into a communicable form, often a set of business rules or business rules statements. These may take on various formats: free-form text, fill-the-blank templates, decision tables, decision trees, and rigorous grammar.

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 may be a combination of vendor-supplied and home-grown software.

Data Reference
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 prior to or in parallel with writing business rules statements because business rule expressions must reference fact types or data elements from the associated data-centric models.

Common Hurdles
No one would argue 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 ones we hear most often are:

• It takes a long time to translate business intentions 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 actual business rule translation process.

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

• Business rule management does not get the management attention it deserves.

• While business rule capture starts before or during requirements, it often continues in design, and may not be complete until development or, worse, until testing.

• Even when automated in BRMS, the business rules are lost to the business people. So, separation happens but connection from business to technology is broken.

• There is still a gap between business and IT in delivering automated business rules.

The Five Most Important Differences in The Decision Model
If you have experienced any of these hurdles, you will appreciate the decision model differences. With a desire for a universal representation for business rules (logic) and for overcoming exactly these hurdles, The Decision Model aimed for 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.

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

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 (click for larger version)

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

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 has a definite starting and end point

4. Each delivers a conclusion to one decision

5. Each is similar to all others due to universal notation

6. Yet each has its own distinct shape and characteristics.

7. Each has a smaller scope than most other business analysis and even automatable deliverable.

8. Many fit on one to two pages.

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

Figure 2: Three Different Decision Models (click for larger version)

The real-world project above originally delivered over 250 random groups of business rules. This was highly unmanageable. By applying The Decision Model, these 250 random groups of business rules reduced to only 20 very manageable decisions totally comprised of only 51 Rule Families in third normal form. The greatly simplified business process models and normalized decision models took much less time to create (and change) and were more understandable to all audiences. A significant savings was that 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 has shown us, a rigorous model provides extremely useful 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, highlighted 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 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[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.

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 life cycle that if finally complete and fast.

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 another platform, and leveraging future technology as it emerges.

10. An organization is no longer tied to a particular platform or vendor.

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

1. The Decision Model does not require conditions and conclusions to exist in data-centric models because business people don’t need these to specify and validate their 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 for these. 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. 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.

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.

5. Decision models allow flexibility in what businesses need in their 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 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.

• 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, a new generation of enterprise is emerging, truly driven by the business and powered by The Decision Model.

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] Sapiens DECISION is a BDMS that automates all principles of The Decision Model.