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.
Be the first to comment on this post using the section below.