Managing Composite services and gaining ROI on SOA investments

In a recent virtual SOA lecture a question came up about how to manage composite services but specifically how individual services relate to each other and the management of the configurability of composite services as a whole. This was raised from the experience on a CSC Turkish SOA project where the question was at want level do you define the interaction of ser vices and how do you define the composite services specification.

I note that these aspects come up in the 2007 Gartner summary of SOA hypercurve model which states composite applications still in the 2 to 5 year ascendancy but interestingly even further back the concept of composite service descriptors as being a future goal. Another observation occupying the same future space, Gartner define business service repositories and event–based application platforms as future capabilities. This ties in with the commentary on the next section on “what is a service” in which the aspects of event response and business level services is consistent with our service definitions (see “what is a service”). Overall the foot note to delivering business benefits from SOA is the focus on strategically, systematically oriented projects (read parameteric definable services).

Another observation that also came up in the lecture was the observation that reuse to gain ROI return on services is not from just the return of the service itself but also can be the reuse of the SOA components infrastructure that is constructed from the first project.

What is a service? The definition is based on two dimensions reuse and composable.

• Reuse - a single interaction is not a service but it this interaction occurs the same many times to different recipients of the service then this can be said to be a service. I use the “rule of 3” from Microsoft for a simple definition of a service. That is if the same function is used by more than 3 consumers then it can be defined as fulfilling a criteria that makes it a service.

• Composable – we will describe this criteria in two parts: encapsulation and composite. Encapsulate: this means that it has characteristics that make it “encapsulatable” and can have SLA type of characteristics added to it – i.e. its logic is repeatable. Not all processes are services for this reason because they may not operate in a repeatable way and may not have characteristics that are repeatable (the logic is encodable and executable). This also explains another aspect of events in the area of unplanned activities that can sometimes be defined as not SOA service invocations because they are external and unexpected. To explain this we can say that a SOA service is typically defined by a service contract has a set of defined logical operations and logical information model. If an event or request comes along that is not part of that service operation then that is not part of the expected service request and hence not executable by the SOA service. In a sense this is consistent with the first criteria that a service is reusable and hence must be used repeatedly many times (atleast 3) and therefore a known service. Two other views can pervade here that SOA is a static (stochastic) system that has to be defined by specifications in order to operate within a set of parameters and that it’s just a matter of bring in other events into the portfolio as they are needed (the change and configurability of services or composability of them to meet changing needs ) in that sense everything can be modelled if the events are captured into the SOA universe. But it also shows that SOA is a simple system that has no intelligence in it to handle the unexpected in the general sense and this perhaps points a way to the future of architectures to come. Another view is that SOA has limitations that need to be managed through the conditions of service use. In enterprise architecture this is typically through the definition of “patterns” and identifying the types of service interactions that are available in the SOA portfolio and SOA infrastructure. The perspective here is where the interaction lies between consumer and producer and to what degree does the service itself of the producer or recipient consumer have to do in order to complete the interaction. Again I see this as possibility another boundary of where future architecture may go in the ability to handle complex requests and semantics that may not be modelled in the current SOA services. While we are on this subject of other types of events another aspect is what is termed “complex event processing” CEP which covers a different aspect of high volume invocations of events that may automatically trigger services that may then need to trigger other services to manage some complex set of events. This is more in the realm of SOA service invocation for complex automated service response. Composite: The second aspect of composability is the ability to treat the service as a construct that can be used like “a Lego brick” to create composite services through combining with other services to create a new service that was not necessarily envisioned from the original conception of the individual services. Another aspect I would like to highlight here is that is not often mentioned that is now seen in “mash-ups” is that in the nature of open standards to define these SOA services this means that services can be obtained and/or combined from sources not only from your own company enterprise platforms but from 3rd party sources. The ramification of this is significant because the design of services becomes a source of real innovation potential to reach new capabilities and deploy these through the SOA framework to deliver new business capabilities.

• End to end performance. This is an important criteria that links together the service with the end use of that service in terms of its performance to support real business goals. The criteria for a service that it doesn’t exist isolation, they belong to one or more business processes. The business performance can be measured by KPIs and SLA performance that represent what needs to be achieved for the business to be effective. The underlying services at what ever level of activity as part of the business process also need to function in a way that supports the end to performance. Just measuring up and down time of service availability much like application or data base availability is only part of the story. Designing and operating better end to end business processes means that the associated end to end technology stack of services also need to be optimised and managed. This is at the heart of the idea of process reliability and process robustness and the idea of service performance and service recovery when services or business processes “break”. Cost reduction programs in IT can rationalise and reduce integration and service component build costs but this is only part of the issue if these services are not aligned or performing in a way that serves the business needs.

These definitions of service criteria for me reinforces the need for process oriented Architecture (POA) and business driven transformation where the definition of business process needs to express the events and activities that organisations expect and what to achieve. Just encapsulating the existing systems and data is a “bottom up” strategy in that it will be defined based on what you have rather than what you need. Applications modernisation and ERP-SOA embody these principles in that its more than just

Mark Skilton

Washington Aug 17 2007

#ROI #SOA #ArchitectureGovernance