A BRMS is not a BDMS: Ten Ways in Which Dealing Business Rules Vendors can be Frustrating for Business Analysts

There is a great deal of confusion about the role of the Business Rule Management System (BRMS). Given the prominent role of the words “business” and “management”, one would be forgiven for believing that a tool thus named would manage the business aspects of the rules of the business. But to the contrary, across the entire class of these tools there is little business management of business rules possible. For the most part, and almost without exception, these tools are provided by the vendor to ensure the most efficient execution of “business rules”, rather than the efficient management by the business of them.

The appellation BRMS, after all, is merely a rebranding of the lesser named Business Rule Engine (BRE); in most cases the vendor simply made the change to reflect the fashion of the times rather than provide a specific set of tools that reflect the grander moniker. Now, it is quite true that the modern BRMS sports some niftier capabilities than the BRE of yore; but these are mainly extensions to the capabilities of the BRE in the field of rule execution.

Without doubt some of the BRMS tools on offer provide some rule authoring capabilities. In a recent review of several BRMSs we saw some neat functionality: one vendor permits the business user to use MS Excel Decision Tables as a user interface, while another provides an excellent graphical rule modeling interface. Still another permits the developer to provide templates for the business user to enter and maintain their own rules.

While these are improvements, they miss the whole point of the bigger business picture and requirements. A tool that will appropriately support the business in defining and managing the logic of the business throughout its lifecycle would have to do a great deal more than provide a neat authoring UI (regardless of whether it is accompanied with a rich and powerful execution environment or not.) We have, on several occasions, both for clients and for our own purposes, defined what such a tool would need to provide. Business Analysts (BAs) would soon recognize the facilities that we prescribe because business analysts have long struggled in the shadow of their “rich” technology cousins who enjoy the unlimited horsepower of powerful tools. The BA is accustomed to making do with configuring up MS Excel or MS Word; or managing endless text statements in requirements tools.

We call our proposed tool a Business Decision Management System (BDMS), not just to distinguish it from a BRMS, but to stress that a business rule must be managed in the context of all the other business logic that together reaches a conclusion that the business is interested in managing: this is the granularity of logic that we refer to as a “Business Decision.” (The Decision Model: A Framework for Linking Business and Technology, van Halle & Goldberg, Auerbach NY 2010.) Many of the features that we define for the BDMS are discussed in the book.

The good news is that some vendors are already offering some of the functions below, so here are ten important functions that we believe a BDMS should sport:

1. Technology Independence : The BDMS should be capable of managing the business logic in a universal manner independently of the technology with which it may be implemented.

2. Modeling Capability : The BDMS should enable the user to model the business logic at a high, structural level without having to detail the logic in order to gain a shared understanding of the logic across all stakeholders;

3. Detailed Logic Analysis :The BDMS should enable the user to build detailed logical statements of the modeled logic, present it in its structural representation and enable the user to validate that logic;

4. Automated Analysis : The BDMS should be able to detect obvious normalization or logic errors, providing feedback to the business audience

5. Testing Facilities : The BDMS should be capable of running “what-if” analysis against test cases to determine outcomes for business modeling purposes

6. Glossary Management : The BDMS must maintain a comprehensive business glossary of fact types, and if necessary provide the user with the ability to model the fact types in a fact model. The purpose of the glossary is to permit the user to maintain the logic using terms actually employed and recognized by the business (or industry standards bodies) in day-to-day use. The glossary should not be an Object Model, or expressed in the typical technical manner.

7. Traceability of the Logic : The BDMS must be able to trace the logic to its source and its business motivations, such that a change in business circumstances or objectives may allow an impact analysis to determine the changes necessary across all the business logic in the BDMS.

8. Effective Dating and Versioning : The BDMS must be able to manage the business effective dating of the logic, as well as maintain versions of the business logic (independently of the versioning of the deployed technology)

9. Governance Enforcement : The BDMS must be able to manage the business effective dating of the logic, as well as maintain versions of the business logic (independently of the versioning of the deployed technology)

10. Enterprise Functionality : The BDMS must, in order to support the higher levels of the Business Decision Maturity Model (BDMM), be able to provide enterprise functions for the components such as the glossary and versioning, such that both local and enterprise versions of glossaries and Business Decisions may be maintained.

There are additional functions that we have identified for a “full service” BDMS, but the ten above get the juices flowing and deliver paradigm and business-changing advantages. Figure 1 is a context diagram that shows graphically the contrasting roles of the BRMS and BDMS in the architecture.
In a future article we will review some emerging technology that promises to fill the void that currently exists in the critical space in enterprise architecture and which are stepping up to support business audiences and business decision (versus business rule) management. Until then, we are interested to hear how various organizations are managing their business logic.

Figure 1: The BRMS vs BDMS in the Architecture

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

NOTE: top image © Alexey Afanasyev - Fotolia.com