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
Three Characteristics of Business Rules Approaches
At the core of all three types of business rules approaches are three common characteristics.
- 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.
- 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.
- 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
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.
Why This Difference is Important
- The formal notion of decision is 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.
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
- 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 decision model has a definite starting and end point
- Each decision model delivers a conclusion to one decision
- Each decision model is similar to all others due to the universal notation
- Yet each decision model has its own distinct shape and characteristics reflecting its unique purpose.
- Each decision model has a smaller scope than most other business analysis deliverables and automation deliverables.
- Most decision models fit on one to two printed pages.
Figure 2 contains three decision models of different sizes and shapes.
(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:
- 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, visually highlighting of 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
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.
- 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 without the need for data models, object models, or fact models.
- It progresses to automatic validation of entire decision models against the 15 principles, detecting all logic errors.
- It includes automated full decision model testing.
- Items 1-5 happen before turning decision models over to IT.
- Adaptors for deploying on target technology platforms deliver a complete life cycle through to automation.
- 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 technology products, migrating to other platforms, and leveraging future technology as it emerges.
- An organization is no longer tied to a particular automation platform or vendor.
- Experience shows that decision models actually improve BRMS performance.
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.
- 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.
- 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.
- 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.
- 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 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
End Note:
- Sapiens DECISION is a BDMS that automates all principles of The Decision Model.
