One of the core concepts of Decision Management is that of Decision Services. Sometimes called Transparent Decision Services or Decision Agents, these components are the key technical deliverable from applying the decision management approach. While a Business Rules Management System or BRMS is the most typical way to build a Decision Service, using one is not actually a requirement.

A Decision Service then 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

Or, more simply

A service or agent that answers a business question for other services

A Decision Service must conform to the standard characteristics for a well defined service or agent in the environment to which it is being deployed plus, in addition it should have several other 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 the service or agent. In general this means that traditional coding approaches such as Java or C# or even new programming languages cannot be used as most business people cannot read, let along write, them.

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. 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.

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. This requires the integration of Data Mining and Predictive Analytics.

Expects multi-channel use
While most service or other component standards handle the technical aspects of multi-channel use, Decision Services need to be able to handle the business aspects also. The service may have more or less context, for instance, as very different kinds of applications will use the component – everything from ATMs and smartphones to Call Center applications and Bill Printing. The way results are used might vary significantly – the number of recommendations being displayed, for instance, and the amount of explanation is quite different when a Decision Service is being used by a call center application versus a smartphone

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 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

No State Change
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. While this is not absolutely essential, this allows the same Decision Service to be invoked when an action must be taken and when it would be useful to know what action might be taken.

Related Briefs:

• Decision Management Defined
• Decision Services and Data