On defining Service Level Agreements for Service Oriented Architectures

A service level agreement in simple terms is a contract between two parties for the delivery of a given service with a certain standard and within a specified time period. In order to effectively manage IT services and ensure continuous support to critical business functions, it is extremely important to define clear SLAs. A good SLA covers metrics and key performance indicators such as availability and performance. It includes specifications for mean and maximum time to respond/repair, problem escalation guarantees, etc. Typically these are negotiated and agreed upon by both the provider and the consumer and tracked through predefined metrics. The loose coupling structure of a service oriented architecture brings in some additional challenges in managing individual components as services themselves.

One of the primary challenges is the sheer complexity in mapping all the technical requirements and capabilities of a service (in the context of SOA) to a meaningful service contract in business terms. Very much related is the problem of measurement. While it may be straightforward to track performance at system end points, the service levels in an SOA need to be tracked in the intermediaries as well in order to check them for conformance. While this can be achieved at the code level for services developed and consumed internally, external services will require monitoring tools or agents to track metrics such as processing time, messages per hour, rejected transaction count, etc.

While these challenges are still obvious and are handled gracefully in most scenarios, A typical example of a unique problem in an SOA system is - Even if individual services ensure to stand by their agreements, it may not however guarantee that the system as a whole does, as there may be environment specific factors that come into picture in real time systems which may have been missed while capturing the SLAs of individual services (Source). This again calls for additional monitoring to ensure end to end visibility of SOA transactions. Another interesting scenario is presented by the author of this blog, who gives a very simple example to explain how many service providers place requirements on the consumers to be able to deliver the promised SLA, but do not state it in the agreement.

As observed in this blog, a contract-centric approach to building services can help bridge the gaps between requirements modeling, design and development and this gives us some food for thought on how standardization of some these approaches across vendors can help us achieve maximum value out of an SOA!

Prepared by Saiganesh Sairaman, MSIS, Class of 2011