There is a growing interest in business rules and business rules management systems or business rules engines. Major software vendors, from IBM, Oracle and SAP to RedHat and SAS, have or are developing business rules management systems.

The use of these systems to support the practice of decision management to automate and manage high-volume, transactional decisions is growing rapidly. A new standard, called the Decision Model and Notation standard, is under development that will bring consistency of representation to the industry. Yet there is still a sense that this is a niche technology, and it is somewhat poorly understood outside of its traditional areas of strength. So what is a BRMS and how does it support decision management?

What is Decision Management?

First we need to discuss decision management. Decision management is a business approach that explicitly focuses on the management and automation of business decisions, especially the day-to-day operations that must be made to complete an operational process or handle a specific transaction. This approach brings together business rules and various analytic techniques and is widely used to effectively apply BRMSs. While there are many other things that you can do with business rules (e.g., improve data quality, manage user interfaces, etc.), the use of business rules to manage decisions is what makes a BRMS compelling.

If you want to know more about decision management, you can check out my columns, entitled “Building Agile, Analytic and Adaptive Systems” and “Four Principles of Decision Management Systems.”

Business Rules Management Systems

A BRMS is a complete set of software components for the creation, testing, management, deployment and ongoing maintenance of business rules or decision logic in a production operational environment. These systems used to be, and sometimes still are, called business rule engines. However not all BRMSs use a BRE at all (some generate code) and even when a BRMS includes a BRE, it is just one part of a complete system — an important part, but one that deals only with execution. A BRE determines which rules need to be executed in what order. A BRMS is concerned with a lot more, including:

  • The development and testing of the rules
  • Linking business rules to data sources
  • Deploying business rules to decision services in different computing environments
  • Identifying rule conflicts and quality issues
  • Enabling business user rule maintenance
  • Measuring and reporting rule effectiveness

To deliver on all this, a BRMS needs a robust set of capabilities for managing decision logic, such as those documented in my Decision Management Systems Platform Technologies Report and shown in Figure 1 (click here or see left for image), The Elements of Decision Logic Management Supported by a Typical BRMS. Specifically, you need:

  • An enterprise-class rule repository with audit trails and versioning.
  • Technical rule management tools that allow technical users (e.g., developers and architects) to integrate business rules with the rest of the environment and edit/manage technical rules.
  • Non-technical rule management tools that allow business analysts and even business users to routinely change and manage business rules (see below).
  • Verification and validation tools, usable by both technical and business users, that take advantage of the nature of business rules to make sure they are correct and complete.
  • Testing and debugging tools to confirm that you get the decisions you were expecting.
  • Deployment tools supporting multiple platforms that allow the logic you have specified to be deployed into a decision service (see below).
  • Data management capabilities to bring real enterprise data into the environment so rules can be written against it.
  • Impact analysis tools so that a user can see what the impact of a change will be before he or she makes it.
  • Either a high-performance BRE to which the rules can be deployed or an ability to generate code that can be deployed.
  • An ability to support the logging of rule execution, so you can tell exactly how a particular decision was made and which rules were executed.

It should be noted that a modern BRMS is likely to support the management of rules derived from optimization and analytic tools as well as rules specified explicitly by a user.

Decision Services

Decision services are the link from our BRMS, to a focus on managing decisions, to decision management. These are sometimes called transparent decision services, agile decision services or even decision agents. Decision services are the key technical deliverable from the combination of a BRMS and the decision management approach. A decision service is a self-contained, callable service or agent with a view of all the information, conditions and actions that need to be considered to make an operational business decision. Deployed on a service-oriented infrastructure and available to other services, to service-enabled applications and to business processes managed using a business process management system, decision services package up all the rules (and any analytics) that go into making a decision.

Decisions can often be thought in terms of a question for which there is a known allowed set of answers. For instance, a decision about routing an insurance claim might be thought of as the question, “How should we handle this claim?” Allowed answers include auto pay, fast track, refer to claims adjuster or refer to fraud investigation group. A decision service handling claims routing would take the information about the claim and then return one of the allowed answers to a calling process or service. In other words, a decision service answers a business question for other services.

One of they main focus these days.