(Why Consider The Decision Model and a BDMS)
“There are capabilities necessary to implement Smart Systems, where business people manage business logic in a business-like and agile fashion, with highest integrity, and deployable to any and many targets. These are the requirements satisfied by a BDMS, not by a BRMS.”
Business Rule and Business Process technologies have become ubiquitous in recent years. By separating business rules from business process, these technologies enable the rapid development of application systems to meet the changing demands of the evolving business environment.
Many large organizations, particularly those in complex and highly regulated industries, have invested in at least one Business Rule Engine (BRE), sometimes called a Business Rule Management System (BRMS). Often, such organizations also have multiple Business Process Management Systems (BPMS) and even multiple BRMS.
Despite the BRMS presence in major corporations, Business Rule technology, in general, has not changed in significant ways for decades. Indeed, in many cases it falls short of its promises - the most important being the ability for business people to be active stewards of their business rules, with traceability from inception to automation. In many, if not most, cases the business’s business rules become lost in the technology and maintenance becomes difficult.
The good news is that organizations are achieving this promise today. It requires a refreshing approach to the problem that changes the game in a positive way for legacy BRMS customers well as those without a BRMS.
This month’s column, based on real-world experience, is aimed at readers who wish to learn what is missing within organizations with (and without) a BRMS and more importantly, how to achieve the original promise of business rule technology and business rules approaches. The column has six parts: How did we get to the current BRMS adoption, what is the current state of our business rules in those environments, how do we rethink the original premise of business governance of business rules, what is the role of technology in this new world, what is a BDMS, and where can we go now.
Part 1: How Did We Get Here?
BRMS Adoption
BRMS adoption varies among organizations, but most fall into one of two categories.
In the first category of BRMS adoption, the adoption begins with the acquisition of a BRMS for a specific application system. This is not a bad decision by itself. Often, however, over time such enterprises end up with several different vendors of BRMS, in addition to homegrown rules engines. Adding to the complexity is that each BRMS comes with a competing, if not proprietary, methodology to business rules automation and management.
The proliferation of BRMS also continues in a subtle way. Specifically, some commercial off the shelf (COTS) applications contain their own, internal business rules engines for which an organization must gather and maintain its business rules.
Figure 1 illustrates the proliferation of BRMS for individual projects.
Figure 1 - Typical Application-Specific BRMS Proliferation in an Enterprise
In the second category of BRMS adoption, the adoption begins with an enterprise vision of centralizing rule services. Even in these cases, projects from different business lines and organizational units use different instances of the same engine, not sharing common business rules, object models, or code. Frequently, despite using the same technology, different projects often use different methodologies and coding approaches.
Only those enterprises with very mature rules management are able to overcome the challenges of governance and methodology across organizational boundaries that are implied by the enterprise business rule vision. Managing and governing at the level of business rules is a very challenging and costly undertaking.
The Rest of the Business Rules
Today, despite the widespread adoption of BRMS technology, by far the largest quantity of business rules in the enterprise still remains embedded in legacy code in which the expression of the business rules is purely technical – and often BRMS adoption does not improve this situation.
BPMS Adoption
Contrary to the BRMS adoption, BPMS adoption most often results in a single technology and methodology across the enterprise – or across large groups of business units within the enterprise. This is quite natural because the business process approach aims to achieve cross organizational boundary cooperation. Still, there is a splintering of the functionality of BPMS across various sub-categories of process modeling and management. So there may be separate document management, workflow and process tools, each of which overlaps in functionality with the other. Figure 2 illustrates the most common adoption pattern of BPMS technology.
A common feature of each of these systems is that they have a built-in business rules technology, ranging from the simplest if-then statement constructs, to full blown BRMS sub-systems. While theoretically possible to integrate these systems with existing BRMS systems, the default adoption pattern is to use the integrated rules capabilities, rather than a BRMS, because of the difficulties implied in integrating different technologies.
Figure 2 - Typical implementation of a BPMS in an Enterprise
Part 2: What is the State of Our Business Rules?
Another difficulty in the classic BRMS/BPMS technology is that it is extremely difficult for the business to understand the logic as expressed in the technology.
The Obscurity of Business Rules in BRMS
Typically the language is highly technical making it difficult for business people to match it to their requirements. The common solution is to “expose” the rules to the business people, using vendor-specific interfaces for the user (but also proprietary to the BRMS product), which allows the user to review and make targeted changes to the rules. The success of this approach seems limited. That’s because BRMS technology, initially intended for the technical user, has subsequently been enhanced for business access, but carries with it reliance on technical artifacts (e.g., requirement of an object model prior to writing any rules).
The Proprietary Nature of the Business Rules Approach
Each BRMS vendor has its own language and its own approach to the form of business rules expression. This means that business rules implemented in one vendor’s BRMS (or BPMS) must be recoded for entry into another vendor system. Frequently the grouping, flow, or even the format of the rules is sufficiently different from one technology to the other to make a migration difficult and potentially risky. That’s simply because the business rules approach does not recognize one representation across BRMS products by which to migrate from one to another.
While some effort has been made in recent years for a standard form of expression of the individual business rule, none has been adopted by the industry. The industry has developed a model of business semantics that can be used for the expression of business logic, “Semantics of Business Vocabulary and Rules” (SBVR). This did not give rise to transformative solutions to the problem. [1]
Part 3: How Do We Rethink the Original Premise of Business Governance over Business Rues?
It comes as no surprise that the evolution described above of business rule and process management adoption leads to a Tower of Babel in business rules management across enterprises. This compounds, rather than resolves, the complexity, regulation and agility in business that the technology aims to manage. There are two forces at play: the proprietary nature of the business rules technology and the undeniable fact that managing business rules is very difficult.
The Business Rule is the Problem, not the Solution
The solution lies in managing something of greater importance than individual business rules, the Business Decision, and doing so through a more mature model, called The Decision Model.
Managing Business Decisions
The impediment to successful business rule management lies in the granularity with which the logic is managed. Given the quantity complexity of business rules it is difficult, perhaps impossible, to manage single rule by single rule across the enterprise. The problem is not solved by grouping business rules by subject or type, or any form of categorization, as these soon prove to be artificial.
Instead, the solution lies in rethinking how to structure rules into a granular form that is natural for the business managers, and, happily, is also natural to the nature of logic itself. The higher granular notion is called a Business Decision and its structural representation is called The Decision Model.
Part 4: What is the Role of Technology in This New World?
The Decision Model is a widely accepted, normalized model of logic of a Business Decision, that is technology independent and also language-independent (its structure, not a procedural language, is sufficient for business understanding). The first benefit is for IT because The Decision model applies to any and all technologies, current and future. The second benefit is for the business audience because it represents the logic of business rules at a level of granularity that corresponds to how business people think in terms of units of logic, and in a format that is easy to understand. It also, by design, is devoid of any technical artifacts since these are not needed for understanding, merely for automation. (Technical artifacts connect to decision models but are not the starting point for them, so they are hidden from the view of the business user). The article, “The Five Most Important Differences between The Decision Model and Business Rules Approaches” [2] describes the benefits of managing the logic of business rules at the granularity of a business decision.
Business Decisions in Process
The Decision Model defines a set of inputs for its execution and one specific output. As such, it is the ideal specification for a service interface for use by process tools. By clearly identifying the separation between the declarative logic of business rules and the procedural aspects of process, decision modeling delivers simpler process models and implementations.
The Holy Grail: Transparent and Multiple Deployments
The value of The Decision Model to an enterprise proves to be significant. Managed properly, it resolves the disparate nature of the logic across the enterprise. Because The Decision Model enables direct translation to most (and multiple) BRMS (present and future), BPMS and procedurally coded forms of business rules, the model can be used to manage the logic to be deployed in a wide range of technologies.
The Decision Model delivers on two promises never achieved before. The first is the potential for full (or partial) business governance over creation and change of business logic. The second is the universal deployment of the same decision model to any target technology. Together these promises deliver to the business people the ability to manage business logic in one place and to the technology professionals the ability to deploy anywhere and everywhere from one solid business source. The result is the first ever single representation of the logic, regardless of the deployment of that logic. Referring to Figure 2 the conceptual result is shown in Figure 3. Here, the same decision model, managed in one place, deploys to two BRMSs, part to a BPMS, and part to a COTs.
Figure 3 - Demonstrating how a Single Decision Model may be used by Different Applications
Part 5: What is aBDMS: Its Challenge and Promises?
The idea behind the use of The Decision Model (and supporting technology) to manage and govern logic across the enterprise depends on many key capabilities. These capabilities are:
-
Manage an enterprise level federated glossary that can map to multiple disparate data models
-
Rapidly create and model Decision Models, both graphically and in Rule Family Tabular form
-
Create different customized views of the same decision model
-
Compare entire decision models to each other in visual format
-
Validate the Decision Models and Rule Families against the 15 decision model principles that ensure integrity of the logic
-
Test the Rule Families and entire Decision Models in static and dynamic tests
-
Integrate the logic assets into the development ecosystem of disparate technologies and workflow platforms
-
Deploy the Decision Models to multiple different technologies i.e. convert the Decision Models and their glossaries (and mappings) to code that is directly deployable into business systems
-
Provide a workflow around the modeling processes such that enterprise level governance can be enforced over the logic assets
-
Integrate the logic into a business process management environment so that the process models can be simplified using The Decision Modeling methods.
-
Represent complex business environments so that the business can rapidly and economically describe the logic at any level of customization
-
Manage separate and reusable decision models for enforcing and changing Data Quality logic
These are the capabilities necessary to deliver Smart Systems, where business people manage business logic in a business-like and agile fashion not possible before. These are the requirements satisfied by a BDMS, not a BRMS.
Productivity Improvement
A key component of value of The Decision Model is the productivity which it fosters in the mining from code and/or the discovering and authoring of business rules. Significant productivity is possible with The Decision Model even without a BRMS.
However, a BDMS significantly improves this productivity, and has been shown to be able to handle very large collections of business logic. The magnitude of productivity improvements, measured by a client, of The Decision Model with and without a BDMS are illustrated in Figure 4.
Figure 4 - Productivity Benefits of The Decision Model and a BDMS
Design Once, Deploy Many
With a BDMS, the illustrative concept shown in Figure 3 becomes reality. The BDMS is the new design and test tool, which then generates and deploys code to the BRMS and BPMS rule engines. This enables the business to manage a single source of truth, using enterprise level governance and all the productivity gains of the BDMS plus The Decision Model.
The Architecture for Success
While implementing a BDMS brings immediate benefit, ultimately the greatest benefit occurs by adopting an appropriate Services Oriented Architecture (SOA) that is “Decision – and BDMS – enabled”. Figure 5 is a high level depiction of this architecture, showing both the design time and the execution time technology stack.
Figure 5 - Design and Execute Time Stacks for Decision Management Enabled Architecture
In short, a BDMS does not replace a Business Rule Management System(s) (BRMS), nor a Business Process Management System (BPMS), instead it empowers these technologies to achieve and exceed their promise by providing:
-
Stronger Business Governance
-
Greater clarity in process and rules
-
Greater quality in rules and logic
-
Greater productivity from specification/change to production.
Part 6: Where Can We Go Now?
Most important, a BDMS frees an enterprise from the constraints of one or more BRMS products. Ironically, the BRMS emerges in a new role, no longer a stumbling block that misses the mark. It actually becomes part of the promises it never quite delivered. It becomes part of the delivery of a more valuable and business- managed asset, enterprise business logic.
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 www.TheDecisionModel.com.
[1] Object Management Group (OMG), an industry standards group, now recognize the difficulties associated with the Business Rules approach, and have initiated a process to define standards around decision models called Decision Model and Notation (DMN). This work is expected to result in a specification by the end of 2013. Barbara von Halle and Larry Goldberg, inventors of The Decision Model, are members of the consortium preparing this specification.
[2] The Five Most Important Differences Between The Decision Model and Business Rules Approaches (They are not by accident!)