Decision-Making Services

James Taylor (ebizQ) explains why we need a separation between process and decision.

• Interesting debate on business process and decisions (April 2009)
• Decision services (Jan 2007)

One of the reasons for this separation is that decisions are subject to business policies or rules, and such policies are often subject to change over time and/or variation between organizational units. If you code the decisions into process logic, perhaps using BPML to generate process services, then you will have to modify the code or BPLM script whenever the policy changes, and implement different versions for different parts of the organization.

But there are some more flexible ways of architecting decision services.

• General-purpose rule engine, driven by a standard policy language.
• Clusters of related business decisions (for example planning and scheduling) can be wrapped into a capability service.

The advantage of these approaches is that they help to separate the generic parts of the process from the specific parts, and thus increase reuse and sharing of the generic parts, while increasing accuracy and differentiation in the specific parts.

In his post on business processes and decision services, James discusses some of the technical issues that arise with this separation. It is certainly true that some technical optimization may be desirable in some situations, and this may mean implementing and deploying the process and decision services together as a fairly tightly coupled unit of software (which CBDI SAE calls an Automation Unit). But at the specification level, the logical services should still remain distinct.

For more examples of policy separation see my articles on Business Modelling for the CBDI Journal, which are archived on the Everware-CBDI website http://everware-cbdi.com/cbdi-journal-archive.