Decision Engines are modules exploited for their ability to apply one or more business policies to a narrow set of criteria to derive a decision in the form of a small set of simple output variables. A simple Decision Engine may take a list of conditions as input and return a Boolean value indicating the true or false interpretation of those conditions. However, not every discrete policy will guarantee the creation of a decision engine. The art is in picking between simple decision rules, more complex Decision Engine candidates, and overly complex Process Flows that chain multiple decision rules/engines.
Identification
Like a Functional Component, a Decision Engine will not cater to the change of state or the operation on mutable objects or data. Each interaction with a Decision Engine should be stateless. Keeping the Decision Engine’s boundaries crisp will allow ultimate flexibility in selecting the appropriate host for the decision. This discipline will ensure that the decision is separated from its intended implications, which may vary from application to application. This will also increase the likelihood of reuse and limit the scope of change introduced by modifications to the Decision Engine’s implementation. Moreover, such separation greatly aids the testing of a module which is likely to represent tens of thousands of possible outcomes with frequent modifications.
Design
The specification, construction, and maintenance of a Decision Engine are tied closely to the business side of the project owners. The need for iteration with interactive sessions and knowledgeable subject matter experts makes development of this module-type more suitable for:
• agile programming methodologies;
• that are best done at onsite locations;
• by developers trained in client-facing disciplines and the problem domain.
Part of the discipline of designing Decision Engines is to isolate discrete, single decisions from a more complex intertwined chain of decision processes. A single Decision Engine should make a single decision. Complex decisions will be orchestrated by remote SOA consumers or through Process Flow modules which chain the output from one decision engine to the input of another. Doing so makes each Decision Engine simpler and more likely to be reused.
Each Decision Engine should be built to support a SOA interface. This is done to facilitate unit testing, increase the likelihood of reuse, and enforce the discipline of separation of decision elements from process elements. The Process Flows that leverage a Decision Engine may use the SOA interface to engage remote decision making or interact through a proxy interface in-process with a single Requestor. External consumers will leverage the decisions provided by a Decision Engine through SOA invocations or through in-process invocation (batch-style) using Rule-Service-Java or the JSR94 features of PRPC.
A Decision Engine will contain no user interface rules, and should never be used interactively. Neither will it contain integration rules, as all data required to make a decision should be supplied through input parameters defined in the signature of the module. And, as previously mentioned, no mutable data should be altered, therefore there are no transactional implications of invoking a Decision Engine.
Usage & Implementation
Decision Engine modules are typically incorporated into Process Flows using Decision Shapes in the Flow rules. As a result, they are implemented along with the Process Flows. A Map or When Rule shall be used as a simple, familiar façade to a more complex decision. More complex decisions, which may return multi-dimensional results, shall be implemented using a Utility activity as a façade.
