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 in Business Intelligence • SOA • SOA Design | Permalink | Comments (0) | TrackBacks (0)

Today IBM announced its intention to acquire Cognos in an all-cash transaction at a price of approximately $5 billion USD or $58 USD per share, with a net transaction value of $4.9 billion USD. The acquisition is subject to Cognos shareholder approval, regulatory approvals and other customary closing conditions, and is expected to close in the first quarter of 2008.

Steve Mills introduced the analyst briefing by talking about the state of the market, with companies becoming more sophisticated about leveraging information, and using analytics for both looking back, and looking forward, becoming more pre-emptive in their decision making. He also spoke about how real-time business analytics was becoming an important part of business process management.

Just about every analyst on the call would have to agree with those statements. Last June, in the ebizQ BI in Action virtual conference this was discussed extensively both in the panel session and in a series of pre-conference podcasts. Indeed, one of the analysts questions was that we’ve been expecting this for a while, why now (answer – a $5 billion purchase takes time).

Cognos fits very well into the IBM stack. For a change it pretty much adds new functionality without adding a lot of redundancy. Furthermore, about 5 years ago Cognos re-architected their solution as a service based offering. It runs on top of IBM (and other) infrastructure software, providing real-time business intelligence and business performance management. The business performance management capabilities are key It enables companies to align, monitor and measure business operations with business strategies. This is truly good stuff – very important to business managers. Nothing for me to pick at.

Except for maybe one thing. Cognos DOES NOT provide predictive capabilities. It provides event management and alerts, but predictive capabilities require some kind of neural network or inference engine to correlate patterns of events. Such events occur throughout the organization in different processes, but when they occur together may predict something of business importance, such as a disruption in the supply chain. Both SoftwareAG (through the WebMethods acquisition) and Tibco have these capabilities. The fact that Steve Mills mentioned this as an important requirement for business management going forward may signal the fact that IBM may be in the market for some complex event processing (CEP) technology. The fact that Mills mentioned it in the context of the Cognos acquisition reveals that he considers it important moving forward. But for sake of clarity, this acquisition does not give IBM this capability.

Posted by bethgb in BI | Permalink | Comments (0) | TrackBacks (0)

Last week Brenda Michelson and I did a presentation in the SOA in Action virtual conference on Business Driven Service Design. This presentation is a sprint through about 2 days worth of material. It's something Brenda and I have been working on for over a year now, and starting talking about over 10 years ago.

The goal of the method is to design services using a business-driven top-down approach starting with events, processes, or interactions - depending upon the business scenario. Ultimately all of these resolve to business activities, which are decomposed into different types and levels of services. It is a method that enables an incremental approach to building a strategic agile architecture. We're pretty excited about it, and are looking for feedback.

Please take a few moments to answer a short survey. As a token of our appreciation, ALL respondents will receive a free copy of the SOA Illumination Service Meta Model. The meta model contains the constructs and relationships required for proper service design, repository layout, consumer-provider agreement establishment and operational instrumentation.

In case you missed it, the webcast is available for replay, as are all the sessions in SOA in Action.

Posted by bethgb in SOA Design | Permalink | Comments (0) | TrackBacks (0)