Decision service

From SmartEnoughWiki

[edit] Definition

A self-contained, callable service with a view of all the conditions and actions that need to be considered to make an operational business decision

Or, more simply

A service that answers a business question for other services

A decision service must conform to the standard characteristics for a well defined service plus, in addition:

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

[edit] Accessing Data

One of the interesting questions about decision services is the extent to which they should be able to gather their own data. Opinions on this range from a limitation of decision services being that they must be passed all the data they require to one in which even long running requests for data, say those involving a human, can be accommodated. Even if we take the position, as I do, that decision services are fundamentally synchronous, we still have a number of options:

Pass all the data available into a decision service and force it to either decide or to pass back some reason why it could not decide (to do with a lack of data, say) so that the calling application can assemble the additional data required and try again.
Pass the data available to the decision service but allow it to call external services and/or databases to gather the data it needs to complete the decision. Only synchronous calls are allowed as the service remains synchronous.
Pass the data available to the decision service and allow it to call external services and to request additional data from a user interface. The decision is still synchronous in that it continues to run/use a thread until the data is provided through the user interface or the request for a decision is cancelled.
Pass the data available to the decision service and allow it to gather the data it needs in any way. While the decision remains synchronous, in that the calling service is waiting for an answer, the decision service may be passivated or otherwise put “on ice” while waiting for the necessary data.

If synchronous behavior is not required then clearly a decision service can be invoked asynchronously, allowed to gather the data it needs to make a decision and then return its result, typically through transmission of an event. This kind of service is common in event-based architectures.