« IBM Announces Plan to Acquire Cognos | Main | SOA as a Cure for IT Entropy »

James Taylor recently blogged on Decision Service Design and linked to the session in SOA in Action Brenda Michelson and I did together on Business Driven Service Design. In his post James writes:

"It is pretty clear to me, having listened to their overview, that what I call a Decision Service is a subset of what they refer to as Business Function Services. Decision Services might be considered a pattern for Function Services in their approach. Decision Services typically are stateless, short-lived and used synchronously by other services. They take data in, might request additional data and then return information about a decision. They don't update databases, they don't take action, they just make decisions."

In another post James defines a Decision Service as: "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."

Using this definition, James is absolutely correct. A Decision Service is indeed a subtype of a functional service. As we build the method out the intention is to continue to identify and model different service patterns which can be used as templates for creating new services. These service models can reduce time, effort, error, cost, and risk, therefore having the potential to be extremely valuable. What Brenda and I are focusing on is a way to consistently model different types of services so the patterns are reusable.

So the essential question is, how do we model a Decision Service in a manner that is consistent, and sufficiently explicit to enable consistency and reduce risk in implementation? James picked up on the characteristics we defined to help us sort it out, characterizing a Decision Service as: "stateless, short-lived and used synchronously by other services." However, I think it is likely that this is just one type of Decision Service. I would call it a synchronous Decision Service, to be used when an instant answer is required and processing is necessarily blocked until the answer is given. However, there might also be Asynchronous Decision Services. In the post where James defines the characteristics Decision Services must conform to, one of the characteristics is:

"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."

I would characterize this type of service, which involves waiting for human interaction, as an asynchronous, long-lived Decision Service. This is a very different model than the above described Synchronous Decision Service. Perhaps there are others as well.

The real value of Business Driven Service Design is that it provides guidelines and best practices for modeling different types of services. Once we have a common way of communicating service specifications as explicit models any type of service can be designed in a consistent, reusable manner. Over time the community will define and share service models if they find the models speed implementation while reducing risk. That is one of our goals.

James asked about modeling information needed to make a decision. Each business service represents a business activity. The model includes all the business policies, actions, and information needed to perform the business activity. In this case the activity is making a decision. If you can determine specific types of information, policies, rules etc that comprise a type of Decision Service, then you can create a reusable template that will save implementation time and cost.

Does this make sense?

Posted by bethgb at 03:28 PM in Business Intelligence • SOA • SOA Design | Digg This | Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/2910