Here’s how decisions and rules relate (and how to manage them)

One of the questions I get often is around how decisions and business rules relate. People want to know so they can design their system and so they can manage change. I recently got a request for a link to a post describing the difference and I realize that, though I have lots of posts that dance around the edges I don’t have one specific to the topic so I thought I would write one.

Let’s start by recapping decisions services. Decision services are services, generally stateless ones, that answer business questions for other services. Decision Services typically have no side effects so they can be called whenever they are needed without the caller worrying that something will change in the system. This means that database updates, event generation or other actions taken as a result of the decision are taken by the caller not by the Decision Service. This is not 100% true but works as a general rule. To work, Decision Services need to contain all the logic and algorithms necessary to make the decision correctly.

Decision Services:

• Support business processes by mak…

One of the questions I get often is around how decisions and business rules relate. People want to know so they can design their system and so they can manage change. I recently got a request for a link to a post describing the difference and I realize that, though I have lots of posts that dance around the edges I don’t have one specific to the topic so I thought I would write one.

Let’s start by recapping decisions services. Decision services are services, generally stateless ones, that answer business questions for other services. Decision Services typically have no side effects so they can be called whenever they are needed without the caller worrying that something will change in the system. This means that database updates, event generation or other actions taken as a result of the decision are taken by the caller not by the Decision Service. This is not 100% true but works as a general rule. To work, Decision Services need to contain all the logic and algorithms necessary to make the decision correctly.

Decision Services:

• Support business processes by making the business decisions that allow a process to continue (replacing the diamonds in a process with real services)
• Support event processing systems by adding business decisions to event correlation decisions (they are often called Decision Agents in this context)
• Allow crucial and high-maintenance parts of legacy enterprise applications to be externalized for reuse and agility
• Can be plugged into a variety of systems using Enterprise Service Bus approaches

All of these are shown in the graphic on the right (click for a larger version). A decision service has some critical characteristics:

• Behavior understandable to the business
  After all we are talking about a “business decision” here so the business had better be able to verify exactly what is going on inside
• Supports rapid iteration without disruption
  Business decisions change all the time so a decision service has to be both flexible and designed for this change
• Integrates 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 trends/insight extrapolated from it.
• Expects multi-channel use
  While this is largely covered by the standard items it is worth noting as it means that VERY different kinds of applications will use the service – everything from ATMs and SmartPhones to Call Center applications and Bill Printing.
• Manages exceptions well
  Not only should it respond sensibly when it cannot decide, it should ensure that enough context is returned as to why it could not decide to assist a manual process
• Must explain its execution
  Many decisions must demonstrate compliance or conformance with policy. Any decision service must be able to log exactly how it decided and that information must be accessible to non-technical users

So how then does a Decision Service relate to business rules? Take a look at the second graphic (also clickable for a larger view). Each Decision Service, and thus each decision requires a number of sets of rules – rule sets. These are coherent groupings of rules that can and should be used together. By and large individual rules are not that helpful for anything in business and a rule set or a collection of rules is required. Some decisions require a single rule set and some require many.

A single rule set decision might be something like deciding on the price of a product using a decision table or deciding what segment to put a customer in using a decision tree (decision tables and decision trees are graphical metaphors for a rule set). Rule sets can also be represented as rule sheets or simple lists – the best representation depends somewhat on the particular rules). What is important is that the rules in a rule set execute as a set and get reused as a set.

A multi-rule set decision typically has a decision flow (often called a rule flow by vendors) that lay out the steps involved in a decision, the branches and the loops and map the steps to specific rule sets. This is shown on the graphic as some decisions use more than one set of rules. This allows multiple decisions, for instance, to use customer segmentation rules as part of the decision without forcing a call to a decision service for customer segmentation. Because rule sets are coherent sets of rules on a single topic, they typically have an obvious business owner – an individual or a group. This allows a clear separation of rule management (by rule set) from rule execution (by decision) – there is not one rule maintenance environment for each decision but one for each set of rules. This allows decisions to use rules owned by multiple parts of the business, something that is important as legal, customer service, marketing and product could all easily have rules that contribute to a decision. Models too can be injected into these decisions in a similar fashion as shown.

To summarize then:

• We separate decisions from processes, systems and events so they can be identified and managed explicitly
• We manage the rules for those decisions as coherent rule sets, each with a singular focus and common purpose
• The management of these rule sets is handled by those who are responsible for the source of those rules – legal documents, company policy, marketing strategy, call center expertise and so on

One of the consequences of this is that rule set changes are probably the crucial management item. Rule changes are going to be made within a rule set and often multiple rules in a rule set will have to change in response to new regulations, new policies or competitive changes. These rule set changes should be managed, tested, simulated and deployed. When they deploy they might alter the behavior of several decisions because they are reused in several and this is both to be expected and fine.

There can also be changes to decisions but these are more structural in nature – changing the flow of a decision or adding/removing rule sets to the approach taken. These may be triggered by changes to the rule sets but are more likely to be independent of them. In this case the decision changes but the rules and rule sets probably do not. Each decision is changed separately in this case but m experience is that these kind of changes are much less common than those involving rule sets.

Comments? Follow-up questions? Let me know.

Link to original post