Joe McKendrick posted on the role of SOA in automated decision making over on the SOA in action blog. In it he saysBecause SOA involves the assembling of applications or interfaces from components or services with different properties, it paves…
Joe McKendrick posted on the role of SOA in automated decision making over on the SOA in action blog. In it he says
Because SOA involves the assembling of applications or interfaces from components or services with different properties, it paves the way for the assembly and invoking of decision services.
And of course he is absolutely right – automating decisions by building decision services and using an SOA approach and infrastructure to integrate them with other services in composite applications is by far the most effective. I would add one caution, though. Because part of the value of decision management and of business rules comes from the right rules being executed everywhere they are needed, many organizations will need to deploy their rules to environments that have not yet been service-enabled.
For instance, the rules for pricing a product might be extracted from a legacy system as it is being converted to services and a decision service created. This pricing decision would then be available to all the processes and services in the SOA environment. Great.
But the organization may have legacy environments where pricing is also an issue – an old EDI system linking them to distributors, for example, or a desktop application built around Excel. While these might be able to access the decision services they may well be more effective if the rules can be packaged up for each platform and deployed as what you could call “logical” decision services.
