While the technical details of constructing Decision Services are outside the scope of this book, a number of best practices are worth noting.
Designing for Batch and Interactive
When integrating a Decision Service into a business process, the decision can be made before the transaction occurs: for example, pre-calculating the credit worthiness of known customers interactively while the transaction occurs: offering an up-sell offer to an anonymous web user; or, after the transaction occurs, deciding whether an insurance claim is likely fraudulent. The “pre” and “post” options could be managed as a batch process, with many items being processed through the decision as a batch in order to optimize the computing resources required. Often, this is a design choice, but sometimes integrating the Decision Service to run during the transaction is required, such as when some of inputs to the decision are only available once the transaction has started. The batch integration of Decision Services is often less complex.
An ideal design will allow a Decision Service to be designed once and deployed in a batch or interactive mode without recoding or changing the decision rules, predictive analytic models, or optimization models. This can be important when a process that is initially deployed in batch mode needs to move to interactive mode because the business requires the decision to be made as the transaction occurs. For example, a fraud detection decision may move from a post-transaction batch process that occurs every 15 minutes to an online fraud detection decision to prevent fraud as it occurs.
The data available to the Decision Service is often different between a batch and interactive environment. In the interactive environment, some data may come from the transaction being processed, such as current browsing history or call center notes. These may also be combined with existing data sources like customer history or product inventory. A separate data layer can be defined that is customized for these different environments without affecting the core Decision Service. Alternatively, two Decision Service entry points can be defined. These have different data inputs and are designed to handle batch or interactive decision-making. These can reuse the business rules and predictive analytic models involved to ensure that decisions are consistent between them. For example, a batch Decision Service might be used to determine the benefits for which a group of employees are eligible. This same decision-making might be available at an interactive kiosk for employees to see if they would be eligible for various benefits in different what-if scenarios. The same logic is applied but a separate data layer would be required for the batch situation.
When constraint-based optimization is involved in a decision, you are often choosing an optimal set of decisions from a large set of possible decisions. This tends to lend itself better to a batch process that can consider a large number of transactions and decisions about those transactions. Optimization can be used during interactive decisions, but often a simple ordering of decision values or other techniques can be used since the number of decisions being considered during a single transaction is often very small.
No Side Effects
One of the most important aspects of good Decision Service design is to avoid any “side effects.” It is possible to use a BRMS to actually send emails, update databases, or approve transactions. This means that a Decision Service could also do these things. It is generally more effective, however, to have the Decision Service determine what should be done and leave the calling application or process to actually take the action.
The reason for this is reuse. If the Decision Service takes the action itself, then it can only be called when that action is appropriate. For instance, a Decision Service that updates the price of an order based on the appropriate discount for a customer can be used when an order is placed but cannot be reused when a customer asks what the discount would be were they to place such an order. It also cannot be reused by a sales person who is trying to see how compelling the discount might be relative to a competitor.
In contrast, a Decision Service that simply returns the right answer and leaves it to the calling application to determine what to do with that answer is much more reusable. A Decision Service that calculates the discount a particular customer would earn on a particular order can be used by the process that places orders as part of the salesperson’s environment and in support of call center processes. Because the action is not taken by the Decision Service itself, there is much more flexibility in where the Decision Service is used.
Even if only one potential use of a Decision Service is apparent, building the Decision Service to recommend an action rather than taking it is a best practice.
Execution transparency is an important aspect of Digital Decisioning systems. All Decision Services should, therefore, have the ability log how decisions were made, which rules fired, what data was used, and what results were generated by analytic or optimization models. These logs can be written to long-term storage by the Decision Service directly, or the organization can have a standard design pattern for Decision Services that ensures that this information is always returned by the Decision Service as part of its signature.
If a decision is regulated, then it is worth storing these logs every time the decision is made. This will ensure that any decision made can be examined in retrospect to show that it was made in a compliant way—so that the business rules that executed when the decision was made were correct and appropriate. If the decision is not a regulated one, it may not be possible to justify the overhead of logging the execution of each decision, and the Decision Service will be set to log execution only sometimes. All Decision Services need the ability to log how decisions were made, however, as understanding how decisions were made will be important at least to the continuous improvement process, if not to external regulators.
Organizations need to be able to tie the log data to the transactions, customers, and objects involved in the decision, as well as to data that shows the downstream consequences of the decision. Generally, the input data contains a clear identifier for the transaction, and this can be stored with the log data. Failing that, the date and time of the decision, along with identifiers such as customer ID, can be stored to make it possible to reconstruct which decision is being examined when the log is reviewed.