The Power of Business Rules Management
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.
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 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.
A decision service must conform to the standard characteristics for a well-defined service in the environment to which it is being deployed. It should have several other characteristics:
Have behavior understandable to the business. After all, we are talking about a "business decision" here, so the business better be able to verify exactly what is going on inside the service or agent. In general, this means that traditional coding approaches, such as Java, C# or even new programming languages, cannot be used because most businesspeople cannot read them, let alone write them.
Support rapid iteration without disruption. Business decisions change all the time, so a decision service has to be both flexible and designed for this change. Well-defined service interfaces and service coherence will help with this. The technology used to develop the service must also be suitable for rapid iteration. It must remain stable in the face of constant changes to behavior.
Integrate historical data. Business decisions are increasingly made "by the numbers," with much reference to historical data. Decision services need a similar ability to use historical data and the trends/insights extrapolated from it. This requires the integration of data mining and predictive analytics.
Explain its execution. Many decisions must demonstrate compliance or conformance with policy. Any decision service must be able to log exactly how a decision was made, and that information must be accessible to non-technical users.
Have no side effects. A decision service should not change the state of the business when it is executed. Any actions taken as a result of the decision service’s execution should be handled outside the decision service itself. The decision service simply says what should be done.
Given these criteria, it is clear why business rules and a business rules management system are so useful for building decision services.
Using a BRMS to Build Decision Services
A BRMS offers three key benefits when used as the basis for building decision services: design transparency, execution transparency and collaboration.
- Design transparency is the ability to see exactly how the decision service has been designed and exactly how it will make the next decision. This transparency means that even non-technical experts can review its planned behavior to ensure it is what is needed by the business, required by the regulations, suggested by best practices or determined by analysis of the data. Using traditional coding approaches to build decision services results in opaque services that are accessible only to programmers; this won’t work with decision services. Decision services implement business decisions, and there is simply too much business know-how involved in business decisions to allow only the IT department to review the proposed behavior.
- Execution transparency allows the organization to go back and look at each decision made, each transaction, and see exactly how it was made. Which business rules were applied? How were values calculated? Why was the decision made the way it was? Unlike code, a BRMS can log each rule fired every time a decision is made. These logs describe exactly why a decision was made a certain way and can be analyzed to tell if the decision was being made correctly (i.e., if it was in compliance) and if there are ways to improve the decision.
- Collaboration is at the heart of the reason for using a BRMS. Instead of business and IT arguing about whether a piece of code matches a particular requirement, they can both read and understand the business rules involved and can see if they are the right ones for the business. They can discuss the decision-making required and focus on the business value, not the implementation. Along with their analytics colleagues, they can see and understand how the decision is being made and work together to improve it.
A BRMS delivers these capabilities through business rule independence, business rule syntax and business rule management.
- Managing decisions independent of the rest of the system, as decision services, and separating decision logic and business rules from other aspects of the system provide more flexibility to make changes with minimal to no impact on basic system operations.. Most BRMSs have rule replacement features to deploy changes to decision services without interrupting service to application users.
- The syntax of business rules is more like English and thus more understandable to businesspeople, leading to better business/technical cooperation, reduced implementation times and fewer opportunities for interpretation errors. A typical BRMS allows for a great deal of flexibility and for rules written with English-like phrases such as "If customer's age exceeds 65, then set customer's discount to .05." This type of familiarity lets business policymakers work side by side with the implementation team. Indeed, many business analysts go through rule writing courses and then write rules with no previous programming experience. The use of graphical metaphors, like decision tables and decision trees, further simplifies the presentation of potentially complex logic.
- Management of the rules in a repository allows the business rules to be segmented into groups so different organizations can manage different rules in different ways. The interactive testing, cross-reference tools and reporting features of a typical BRMS make it easier to keep these rules up to date and find them when they must change. Business rules can also have explicit times and dates when they should go into and out of effect. Templates can be created to let users update, view or create rules in a controlled manner without knowing anything about syntax or code. Because ownership of portions of the decision’s business logic can be handed off without risking unintended changes to other code, risk and cost can be greatly reduced.
Business User Rule Management
A BRMS will often promise to deliver business user rule maintenance so that non-technical users can change decision-making when they need to. However, most business users don't want to maintain rules any more than they want to write code; they want to run their business better. They want to:
- Relax their underwriting policies
- Reduce their risk exposure
- Retain more customers, even if it costs more
- Promote slow-moving products
- Catch a new kind of fraud
- Enforce new regulations, and so on.
A BRMS does not automatically give you the kind of environment you need, but it will allow you to develop one. You can use the ability to define templates, vocabularies and user interfaces for business rule editing so that business users feel like they are doing what they want to do: changing the way their business runs. A BRMS allows this editing to be available in their familiar environment, increasingly allowing rule editing to be “mashed up” with other aspects of a business user’s environment. Support for approval workflows in a BRMS allows the process of rule maintenance to be integrated into other tasks performed by the business, linking rule editing to the reports that prompt a change in eligibility rules or to the tasks that create new products requiring pricing rules. A BRMS also provides the impact analysis and simulation tools that will reassure a non-technical user that their changes will have the impact they expect, while also providing an environment that prevents them from making errors in rule editing.
Business users can and should be able to maintain a significant percentage of their business rules. It just takes a certain amount of thought and planning, and the use of a decent BRMS.
Adopting a BRMS and Decision Management
A BRMS is more than just a new programming tool or a new way to write logic. A BRMS enables you to move to decision management, bringing business decisions under the control of your business while delivering high throughput and repeatable, automated decision-making using decision services. The best practices for adoption are simple:
- Begin with decision discovery, identifying and modeling the decisions that matter to your business, to your business processes or to handling your business events.
- Build decision services using a BRMS so that your systems, services and processes can get the decisions they need made through a simple service call.
- Implement a decision analysis process to make sure you are tracking how well your decisions are being made and keeping the rules up to date.
Managing high-volume, operational decisions with business rules is a proven approach. A BRMS is a critical piece of software infrastructure that no modern IT organization should be without.