A Framework for Multi-Level SLA Management

Introduction

The paradigm of Service-Oriented Architectures (SOA) has changed the way IT-based systems are built (Papazoglu & Heuvel, 2007). Initially SOA was mainly applied to restructure the IT stack within an organisation. More recently it has also evolved as a common paradigm for cross-organisational service landscapes where services are considered as tradable goods. Consequently, services operate under a strong business context where service customers can expect services to be provided under well-defined and dependable conditions and with clearly associated costs.

Service Level Agreements (SLAs) are a common way to formally specify the exact conditions (both functional and non-functional behaviour) under which services are or shall be delivered. However, the current SLAs in practice are just specified at the customer-level interface between a service provider and a service customer. Customer-level SLAs can be used by customers and providers to monitor whether the actual service delivery complies with the agreed SLA terms. In case of SLA violations, penalties or compensations can be directly derived.

Customer-level SLAs do not allow service providers to either plan their IT landscapes according to possible, planned or agreed SLAs; nor do they allow understanding of why a certain SLA violation might have occurred. The reason for this is that SLA guarantee terms might not be explicitly or directly related to actual performance metrics or configuration parameters. This makes it difficult for service providers to derive proper configuration parameters from customer-level SLAs and to assess (lower-level) monitoring metrics against customer-level SLAs. Overall, the missing relation between customer-level SLAs and (lower-level) metrics and parameters is a major hurdle for managing IT stacks in terms of IT planning, prediction or adjustment processes and in accordance with possible, planned or actual SLAs.

As part of the European Research project SLA@SOI (SLA@SOI, 2010), we developed the vision to use the paradigm of SLAs for managing a complete IT stack in correlation with customer-level SLAs which are agreed at the business level. This complies with the current technical trend to apply the paradigm of service-orientation across the complete IT stack, i.e. infrastructure/platform/software as a service, but also with the organisational trend in IT companies to organise different departments as service departments, providing infrastructure resources, middleware, applications or composition tools as a service. SLAs will be associated with multiple elements of the stack at multiple layers, e.g. SLAs for elements of the physical/virtual infrastructure, middleware, application and process-level. Such internal SLAs describe the contract between the lower-level entities and higher-level entities consuming the lower ones. More precisely, the SLAs specify the required or agreed performance metrics but also the related configuration parameters.

The scenario of multi-level SLA management is relevant in many different contexts, where either a chain of service level providers contributes to the delivery of an eventual service or services within single providers are of such a complex nature that their proper management requires the splitting of the service into layers (and chains) of internal sub-services. As a set of complementary use case scenarios, the project SLA@SOI investigates in particular the following four industry scenarios: ERP hosting, where complex enterprise applications are managed via layers of internal services, Enterprise IT, where IT resources are to be delivered to multiple competing internal customers along business priorities, Service Aggregation, where value added services are composed of lower level IT and telco services, and eGovernment, where social services are composed of different human and IT-based services.

This paper presents the detailed conception and implementation of a multi-level SLA management framework and it is built on a previous discussion of a purely conceptual architecture (Theilmann, Yahyapour, & Butler, 2008). The remainder of this chapter is organised as follows. Section 2 discusses the state of the art. Section 3 introduces the developed framework while Section 4 provides evaluation results in the context of a case study. Section 5 concludes with a brief summary and outlook.