Frameworks for Business-driven Service Level Management

Frameworks for Business-driven Service Level Management A Criteria-based Comparison of ITIL and NGOSS Thomas Schaaf Munich Network Management Team, Ludwig-Maximilians University (LMU) Oettingenstr. 67, 80538 Munich, Germany E-mail: schaaf@mnm-team.org Abstract In the majority of today s IT organizations, Service Level Agreements (SLAs) are an important means for underpinning IT service provisioning by clearly defined Quality of Service (QoS) parameters as well as service costs and violation penalties. The management of those SLAs is the main subject addressed by the discipline of Service Level Management (SLM) which covers several activities vital for the deployment of customer-oriented, high-quality and well-performing IT services. This paper analyzes and compares two of the most important SLM frameworks available in business-driven IT Management: the IT Infrastructure Library (ITIL) with its SLM reference process and the NGOSS SLA Management Handbook. In order to deliver significant and helpful results, we derive a set of evaluation criteria from a realistic IT scenario. These criteria are applied to ITIL and NGOSS in order to elaborate possible areas of conflict as well as complementary fields and unaddressed issues. The results are visualized in an analysis matrix which shows whether and how ITIL and NGOSS may co-exist as SLM frameworks in one operative and management environment. I. INTRODUCTION Service Level Management (SLM) is often regarded as one of the most important management disciplines in IT Service Management (ITSM), vital for customer-orientation and provision of high-quality IT services. SLM is responsible for determining, monitoring and reporting IT service quality metrics (QoS parameters) in line with the commercial business goals of the entire organization. It is important for an improved relationship between a service provider and its customers, because at the best a common understanding of expectations and possible achievements to the agreed costs is established between provider and customer. Thus, SLM builds the interface between an IT organization and its customers and therefore plays a quite decisive role in the context of businessdriven IT management. Having gained this status and attention, various concepts for supporting effective Service Level Management have evolved from research and practice throughout the last couple of years. The most important operative instrument which all of these approaches have in common, are Service Level Agreements (SLAs). However, the approaches differ strongly in their scope, their level of detail, their feasibility for technical and tool support and their target audience. This heterogeneity may turn out as problematic when IT managers try to implement SLM: On the one hand, a holistic approach does not exist, and on the other hand the existing concepts, frameworks and technologies do not fit together like pieces of a puzzle. Guidance in integrating multiple efforts into one consistent SLM solution suite is not available today. These considerations build the starting point for the analysis presented in this paper in which we compare two of the probably most popular existing SLM frameworks by using a set of significant evaluation criteria. These two frameworks are the IT Infrastructure Library (ITIL) [1] and the NGOSS SLA Management Handbook [2] (for the remainder of this paper referred to as the NGOSS Handbook ). Both frameworks claim for themselves to be business-aligned. While the NGOSS Handbook is clearly focused on SLM issues only, ITIL is not. In fact, ITIL provides guidelines ( best practices ) for the entire field of ITSM. Service Level Management is one of the five reference processes described in the Service Delivery book [3]. The goal of the comparison presented in this paper is on the one hand to elaborate those areas where ITIL and the NGOSS Handbook can be regarded as complementary and on the other hand to find potential fields of conflict when trying to co-implement ITIL and NGOSS SLM. Finally, the comparison shall uncover those fields in SLM for which none of the compared approaches provides a solution. For that stake, the remainder of this paper is structured as follows: Section II introduces the analysis by defining a set of fundamental terms and concepts in the area of SLM. The rest of the paper will base on these definitions and, where necessary, state differences and extensions which are made by the respective approach. In Section III, we derive evaluation criteria for SLM frameworks from a realistic IT scenario. Section IV gives a survey of ITIL SLM and the NGOSS Handbook, followed by the actual comparison whose results are visualized and explained in Section V. Further related work is presented in Section VI. The paper concludes with a short summary and outlook on future efforts. II. TERMINOLOGY &COMMON CONCEPTS In the area of SLM, various terms and concepts have been established over years and are today shared between different approaches. Although as almost everywhere a uniform terminology for SLM does not exist, the following set of terms is used in the majority of the presented approaches

in basically comparable meanings. In this section, we give definitions generic enough to build the foundation for both ITIL and NGOSS: 1) Service Level Agreement (SLA): A Service Level Agreement is a written contract between a service provider and a service customer/subscriber. It must contain a description of the service functionality, definitions of related QoS parameters (service levels) and declarations of responsibilities of both parties. It may additionally contain prices for service usage to pay by the customer/subscriber and penalties for service level violations to pay by the service provider. 2) Service Catalogue: A Service Catalogue contains definitions of standard services as well as documentations of customer-specific services. It can be used as a foundation for automated service subscription or for the negotiation of SLAs. 3) Service Model, Life Cycle and Domains: When talking about SLM and SLAs, there should exist a common understanding of what the term service means. Accordant to [4], a view on a service consists of two components: the service life cycle which displays the dynamic behavior of a service, and the static service model which describes the composition of basically entities and interactions inside a service and shows the service in a role-based context. Starting with the service life cycle model, a division of the life cycle into seven phases has proved as a reasonable scheme. These phases are: offer, negotiate, implement and test, accept, operate, change and decompose. An extract of the static service model which has been developed in [5] is depicted in Figure 1. The relevant domains for the service context are the provider domain and the customer domain. The provider domain comprises all of the entities vital for providing the specified service functionality. The service provider is responsible for the task of service provisioning and therefore operates a service implementation and a service management. customer side provider side side independent customer domain service client accesses uses subscribes & manages concludes accesses service access point implements provider domain uses supplies usage functionality realizes service implementation Fig. 1. «role» user provides observes service QoS parameters manages «role» provider «role» customer realizes directs Static Service Model substantiates management functionality uses service level agreement supplies implements CSM client CSM access point concludes service management implementation The customer domain contains the customer and the user role. The user can deploy the usage functionality of the provided service via a Service Client (SC) which is connected to a Service Access Point (SAP). The customer subscribes the service, concludes an SLA with the service provider and monitors service provisioning via the Customer Service Management (CSM) access point. Further on, the model defines functionality classes and several interfaces for management and usage which we do not introduce in more detail at this point. 4) Service Availability and Reliability: Having defined the SLA and Service Catalog concepts as well as a Service Model covering dynamic and static characteristics of IT services, we finish this section by introducing some of the probably most important IT service performance indicators: availability, mean time to repair (MTTR), mean time between failures (MTBF) and reliability. Provided that T op is the agreed service operation time and T down is the (cumulative) service downtime, the (predicted, agreed or actually measured) availability of an IT service is defined as: Availability = T op T down (1) T op In practice, determining service availability may be much more complicated than this simple formula suggests, due to the complexity of most IT services and the complexity of the measurement process. The NGOSS Handbook addresses this issue by introducing Service Degradation Factors and Service Access Point Weighting which we shortly explain later on in Section IV. A doctoral thesis presenting a methodology for the determination of service availability can be found at [6]. Two common metrics in SLAs are the MTTR which is the average duration of a service incident, and the MTBF, defined as the average service uptime without interruption. Provided that n is the number of incidents within the considered time period, t 0 is the start time of this period, t i,down (1 i n) is the occurrence time of the i-th service outage, t i,up its clearing time, and t n+1 is the end time of the period, the MTTR is defined as: n i=1 MTTR = t i,down t i,up (2) n Analogous, the MTBF is defined as: MTBF = (t n+1 t 0 ) n i=1 t i,down t i,up (3) n +1 Knowing MTTR and MTBF, availability can also be calculated using the following formula MTBF Availability = (4) MTBF + MTTR which will deliver the same values for availability as the first definition. Finally, the reliability of an IT service is an indicator for the frequency of service incidents/outages. A high MTBF results in a high reliability. Compared to availability, MTTR and MTBF, reliability is a weaker performance indicator, hard to express by an intuitive formula. Nevertheless,

it is often not the service availability, but its reliability that is responsible for a customer s subjective satisfaction and the resulting provider s reputation. One goal of SLM is to maximize service availability and service reliability. III. ANALYSIS FOUNDATIONS A thorough and structured analysis and comparison of the given frameworks requires meaningful evaluation criteria which we derive from a typical SLM scenario presented below. Before this, we give a short motivation for our choice of frameworks to compare. A. Why compare ITIL and NGOSS? ITIL is a today widely-used collection of best practices in IT Service Management that has, of all standardization efforts, gained the biggest popularity. It builds the foundation for the ISO/IEC 20000 standard [7]. SLM is one of the topics addressed by ITIL and at the same time one of the ten ITIL reference processes. By contrast, the NGOSS SLA Management Handbook is by far the most comprehensive and voluminous published collection of SLM concepts and principles. In addition, both ITIL SLM and the NGOSS Handbook fulfill the following characteristics that we regard as specific and determining for any approach that can be called a framework : They can be regarded as holistic (i.e. not restricted to specific aspects, but addressing SLM as a whole ), they use and partially define their own terminology for SLM, and they are independent from specific tools. B. A typical SLM scenario As depicted in Figure 2, we consider an exemplary IT provider P that provides three different IT services (E-mail, Webhosting and Backup) for its two customers C1 and C2. While Webhosting is exclusively delivered to C1 and Backup exclusively to C2, the E-mail service is offered to both customers. Accordant to the generic Service Model presented in Section II, all services are accessed by the users of the respective customer domain via a customer-specific Service Client (SC) which is connected to the Service Access Point (SAP) of the respective service. To make its three services available, P is dependent from two external providers, the suppliers S1 and S2. S1 may be considered as a typical Telecommunication Provider, S2 as a company specialized on the implementation and operation of individual application services. Both S1 and P require one of S2 s services (the Application X service). Of course, P as well as S1 and S2 host their own IT infrastructure represented by the clouds. We assume that Service Clients are only needed when human users access an SAP. If services are needed as sub-services and thus form components of another service, they can be directly connected via the SAP. SLAs have been closed for all services, although we have only plotted two of them exemplary. We selected this scenario since it offers the following characteristics: It shows a service provider in the context of multiple customers as well as multiple external suppliers (multi domain scenario), providing a set of services that are assembled of IT components and sub-services. For an SLM framework, this is both an authentic and challenging use case. C. Assessment Criteria for SLM frameworks The following set of evaluation criteria for SLM frameworks has been derived from the above SLM scenario. What should an SLM framework provide to an IT manager or Service Level Manager in order to facilitate effective SLM? We present each criterion in the following structure: First we describe and explain it, then we show how this criterion can be derived from or motivated by the scenario. Every criterion is assigned to one of the following three categories. Management Aspects: M1 Management process Following the principle of process-orientation, any incurring task in the area of effectively managing SLAs should be embedded within an embracing management process. A management process is characterized through a well-defined sequence of activities with clearly delineated responsibilities for every step or task. A framework for SLM should specify the SLM process, its activities, corresponding responsibilities and process in- and outputs. In the scenario: The SLM process of the provider P is responsible for negotiating, establishing and monitoring all SLAs with C1 and C2 as well as S1 and S2. M2 Relationships and Dependencies to other management disciplines SLM is not a management function which acts in isolation to any other management discipline. The opposite is the case. That is why an SLM framework should be aware of its direct management environment and at the best define interfaces for the communication within this environment. In the scenario this becomes visible when effective SLM for example depends on certain outputs/data coming from Configuration Management. M3 Management assessment guidelines The degree to which the process (as is the case when looking at ITIL) or the tools and recommendations (NGOSS) perform in a specific use case should be assessable and measurable. Therefore, the framework must give concrete advice on how to evaluate its own implementation. Critical Success Factors (CSF) and Key Performance Indicators (KPI) are required. For the stake of continuous improvement, P should review its own SLM process at regular intervals. M4 Business alignment of SLM Whether recommendations or decisions that an SLM framework helps to make are sufficiently in line with business needs, is hard to determine, since business needs may vary to a great extent in different scenarios. An SLM framework can be regarded as business-aligned, if significant decisions consider business impact which is basically expressed by monetary loss or return. This is especially important when C1 and C2 are internal customers, i.e. P, C1 and C2 stand under one

administrative business domain. SLA and QoS aspects: S1 Mapping support for QoS parameters The agreed service performance has to be quantified in terms of QoS parameters. Therefore, service quality metrics (e.g. the availability of an IT service) have to be broken down on physical resource performance metrics (e.g. router availability). This is important for the service provider in order to avoid performance promises that he will not be able to fulfill for example due to hardware restrictions. An SLM framework should give advise on how to proceed to vertically map QoS parameters between services, sub-services and resources. In the scenario: P must know which performance metrics for the E-mail, Webhosting and Backup services he is able to promise to C1 and C2 within the SLAs. S2 Measuring support for QoS parameters and service performance QoS parameters need to be measured. In most cases, the measurable units within an IT environment are not the same ones as the ones specified in an SLA. Often, the SLA-relevant metrics are aggregations of physically measurable performance metrics. However, an SLA framework should provide support in measuring and aggregating QoS parameters. P must be able to measure and aggregate the QoS metrics made available by its own infrastructure as well as the performance metrics of the sub-services purchased from S1 and S2. S3 SLA templates or design rules An essential task in SLM is the establishment of the SLA documents including negotiations with all customers. An SLM framework should support this task by providing customizable templates for SLAs or guidelines for contract design. P must establish SLAs with C1 and C2 for all delivered services. S4 Performance calculation and reporting support To calculate and report amongst others the achieved service levels, the degree of service degradation and the number of SLA violations is an essential task of SLM. A framework should provide support on this issue. Reporting and QoS determination also build the foundation for service charging which is addressed by the next criterion. P must be able to calculate the performance of its three services from the measured QoS metrics and create reasonable reports for its customers C1 and C2. S5 Support of SLA-based charging and accounting To charge a customer for service usage is not only a relevant need for companies specialized on service outsourcing. Charging becomes rather more important for all IT organizations even the ones serving internal customers only in order to strengthen the perception of internal customers as business partners. Since in Customer C1 Domain use User Customer C2 Domain SC Webhosting SC E-mail SC E-mail SC Backup SAP SAP SLA Service Webhosting Service E-mail Service Backup Implementation Webhosting realizes Implementation Backup Provider P Domain Implementation E-mail provisioning SLA substantiation Sub-service Telecom/WAN Sub-service "Application X" Implementation Telecom/WAN Implementation Application X Supplier S1 Domain Supplier S2 Domain Fig. 2. Scenario

Financial Management for IT Services accountable units often correlate to QoS metrics (in many cases, they are even congruent), it stands to reason to consider charging issues already in the process of service negotiations and SLA design, and thus within the responsibility of SLM. That is why an SLM framework should give guidance on integrating charges into SLAs by e.g. considering them in SLA templates or in the SLA establishment process. P has to charge C1 and C2 for the delivery of its three services. The SLA negotiations should cover agreements on rates and penalties which should be recorded within the SLAs. General aspects: G1 Support for multi domain service provisioning An SLM framework must provide support for those scenarios where service performance and the achievement of certain service levels highly depend on the performance of underlying services, obtained from third party providers. P s services are not only dependent on P s own IT infrastructure, but also on the services delivered by P s suppliers. Thus, achievable service levels highly depend on the service levels achieved by S1 and S2. G2 Support for multiple customers service provisioning At first sight, this criterion looks similar to the previous one, but means something different: While the previous aspect refers to linear chains of service provisioning over different providers, the multiple customers service provisioning support means that the SLM framework should give guidance on how to manage different SLAs of different customers efficiently. Modular design of SLAs and the establishment of a Service Catalogue are two possibilities for facilitating the management of multiple SLAs. One goal must be to avoid redundant pieces of work. Both C1 and C2 subscribe P s E-mail Service. Their SLAs concerning this service may differ in some aspects e.g. C1 and C2 may purchase different service levels. But some parts of the SLAs for the E-mail service may be exactly the same, e.g. the description of the basic service functionality. G3 Automation and Tool support An SLM framework can provide automation and tool support by maximizing its degree of formalization. The adoption of modeling languages and tools like XML or UML can help to substantiate the framework contents in a formal way to facilitate development and deployment of tools. In the scenario, tools can be a helpful addition to SLM for example at the following spots and interfaces: An automated Service Catalogue enables the customer to select between a repertoire of standard services with their default configuration. A tool for storing and administrating SLAs helps the SLM staff to manage lots of documents and avoid version conflicts. Other tools may be used to check the integrity of SLAs and find inconsistencies or to monitor process flows. D. Weighting of Criteria We forbear from assigning specific weights to the listed criteria. This is not necessary for the comparison, since we want to explore areas of conflicts and complementary fields in the approaches as well as issues unaddressed by both frameworks. The goal of this analysis is not to give a statement on whether ITIL SLM oder the NGOSS Handbook is the better (or even the best) solution. IV. SURVEY: ITILAND NGOSS In the following, we give a survey of ITIL SLM and the NGOSS SLA Management Handbook. Doing this, we keep in mind the criteria developed in the previous section to evaluate these two frameworks later on. At certain points of the descriptions, we refer to the criteria catalog in order to prepare the assessment in the next section. A. ITIL Service Level Management 1) Overview: ITIL (IT Infrastructure Library) is a collection of books, in which best practices in IT Service Management (ITSM) are described. Today, ITIL can be seen as a de-facto standard in the discipline of ITSM, for which it provides guidelines by its current core titles Service Support [8] and Service Delivery [3]. ITIL follows the principle of process-oriented (IT Service-) Management: Every management activity taking place within an IT organization is part of one of the defined management processes. Thus, processorientation extends the idea of functional management where IT management decisions and actions take place in different departments (e.g. network department, server department, storage department). In effect, the responsibilities for specific IT management decisions can be shared between different organizational units as the management processes span the entire IT organization independent from its organizational partition. Service Level Management is one of the ten ITSM processes defined by ITIL and part of the Service Delivery book. Besides Service Level Management, this book describes Availability Management, Capacity Management, IT Service Continuity Management and Financial Management for IT Services. Together, these five processes are called the tactical processes and build the direct context of SLM as depicted in Figure 3 in contrast to the operational ITSM processes described in the Service Support book (e.g. Incident Management, Change Management). 2) Roles: The relevant roles in ITIL Service Level Management are the service provider, the service customer and the service user which exactly maps the generic service model introduced in Section II. The SLM process builds the interface between the IT organization (as the service provider) and its internal and external customers. According to ITIL, any customer is characterized through the commission, payment and ownership of one or more IT services that are provided by the IT organization. Due to the roots of ITIL in the

Business, Customers, Users Availability Management Management Tools CMDB Fig. 3. Requirements Targets Achievements Capacity Management Alerts Exceptions Changes Service Level Management SLR, SLA Specsheet SIP, SQP Financial Management Context of ITIL Service Level Management Continuity Management British government, the focus is clearly set on internal which basically means non-commercial customers like e.g. the manufacturing or accounting department of the enterprise in which the IT organization is located. A user is defined as any person using a commissioned service (e.g. manufacturing staff or an employee in the accounting department). SLAs are closed between the IT organization and its customers. Responsible for the contract negotiations are the process owner (Service Level Manager) who represents the IT organization, and of course a representative of the customer. 3) SLA types and structures: Before discussing the management process and its activities, ITIL enhances the SLA concept by some additional aspects and terms: Any SLA that is closed between the IT organization and at least one of its internal customers in order to provide IT services to this customer, is called an Operational Level Agreement (OLA). By contrast, an SLA that the IT organization contracts with an external supplier in order to obtain (sub)services from this provider, is called an Underpinning Contract (UC). ITIL makes this distinction, because UCs may significantly impact what can be promised within an OLA. The Service Level Manager must know about the interdependencies between the existing UCs and OLAs (cf. criterion G1). Besides these two special types of SLAs, ITIL defines three different kinds of SLA structures. An SLA is called a Servicebased SLA when it is valid for all customers of one or more services and no individual SLAs are designed for different customers. This is often the case for services facing uniform customer/user requirements (e.g. e-mail, internet-access). By contrast, a Customer-based SLA is closed with one individual customer and normally for all the services subscribed by this customer. Customer-based SLAs basically find appliance when customer demands regarding service quality parameters vary to a high extent. The third SLA structure ITIL proposes is the so called Multi-level SLA which can be regarded as the composition of Service- and Customer-based SLAs. ITIL describes Multi-level SLAs to follow a three-layer structure: The Corporate Level covers generic issues valid for all customers (e.g. opening hours of the Service Desk). The Customer Level contains customer-specific issues as extensions to the Corporate Level, regardless of the services ordered by this customer (e.g. expanded Service Desk opening hours for some customers). The Service Level covers service-specific issues relevant for one customer or group of customers (e.g. agreed availability for an accounting service). The idea behind this three-layer structure is to substitute only the service and customer layers in order to avoid redundancy and reduce maintenance and administration expense when designing new SLAs (cf. G2). 4) The management process: There are six activities that build the ITIL Service Level Management process: Identify, Define, Contract, Monitor, Report and Review. Each of these activities needs certain inputs and creates certain outputs both of which are described by ITIL (cf. M1). 1) Identify: First of all, the customer demands have to be identified and described as Service Level Requirements (SLRs). This document will provide a basis for the future SLA. 2) Define: In the second step, the concrete service which is to deliver to the customer, has to be defined in case of a new/individual service. Therefore, a Service Specification Sheet (Specsheet) should be created, containing information on the technical implementation and realization of the service. The Specsheet can be seen as a translation of the SLRs into technical specifications. Additionally, ITIL proposes to develop a Service Quality Plan (SQP) as an internal document containing i.a. key performance indicators and a plan for achieving the agreed service quality. In case of existing services, the respective documents can be adopted. 3) Contract: In this activity, a written contract between the IT organization and its customer is closed, based on SLR, Specsheet and SQP. In the case of an internal customer, this contract (SLA) is an OLA. Another output of this step is the updated Service Catalogue. In case of a new or modified service, the changes should be added to the Service Catalogue in order to potentially provide this service to other customers, too. The Contract activity also implies to close or update UCs with external suppliers, if the agreed service requires sub-services, technology or infrastructure which the IT organization is unable or unwilling to provide by itself. 4) Monitor: Of course, the actually achieved service levels (QoS parameters) have to be monitored. It is important that the SLA contains information on how and how often the measurements have to take place. Measurement outputs are called Service Level Achievements and serve as inputs for the next activity. 5) Report: In this activity, the achieved service levels are compared with the agreed service levels in order to detect violations. Service Level Reports are created and

handed to the Service Level Manager. 6) Review: As the last activity in the ITIL SLM process, the Service Level Reports are evaluated with respect to the contracted OLAs and UCs and of course under consideration of the SQP. In order to continuously improve the service quality, a Service Improvement Program (SIP) should be developed and launched within the next time period. As critical factors for the success of the SLM process, ITIL names aspects such as the expertise and customer-orientation of the process manager and clearly delineated responsibilities within process execution. Key Performance Indicators (KPIs) help assessing and measuring the success and performance of the process and its outputs (cf. M3). There are of course many interdependencies between the SLM process and all the other nine ITIL processes. For example, Service Level Management and Financial Management for IT Services should cooperate closely in order to integrate service charges into SLAs. At the same time, Incident Management needs to be aware of the impending violation fees in order to assign the right priorities to the incident tickets. 5) Conclusion: ITIL gives guidance for the organizational setup of an SLM process. It is focused on a clear role model, the definition of responsibilities, activities and a common terminology as well as business-awareness and -alignment of ITSM. Covering this radius, it remains superficial in many areas. It is tool-independent, only little technology-aware and does not provide concrete templates for the various artifacts (even not for an SLA). The NGOSS SLA Management Handbook, presented in the following, gives more detailed guidance in some fields. B. NGOSS SLA Management Handbook 1) Overview: The SLA Management Handbook is a publication of the Tele Management Forum (TMF) and part of the New Generation Operation Support Software (NGOSS) project [9]. It consists of four volumes named Executive Overview [2], Concepts and Principles [10], Service and Technology Examples [11] and Enterprise Perspective. The fourth volume (Enterprise Perspective) has not been released to public yet 1. These titles address different parties of interest: Volume 1 (Executive Overview) has been written for Chief Executive Officers, Volume 2 (Concepts and Principles) for telecommunication managers, Volume 3 (Service and Technology Examples) for telecommunication implementers, and Volume 4 (Enterprise Perspective) will primary address enterprise managers. Although the contents of the NGOSS Handbook are basically aligned to businesses in the telecommunication industry, they are generally also applicable to a broader scope of IT-dependent organizations, because most of the presented concepts are not restricted to telecoms industries specifics. The probably most significant title of the SLA Management Handbook suite is the second one (Concepts and Principles). It 1 March 2007 starts with some Business Considerations including a business model, followed by a chapter on Telecommunications Services. The next three chapters deal with several subjects directly concerning SLAs, starting with SLA Content and Management, followed by SLA Management Tools and concluding with a chapter on SLA Performance Reporting. In the following, we give a survey on the contents of these five core chapters. 2) Business Considerations: In contrast to ITIL, the role model applied in the NGOSS Handbook is more diversified, particularly with respect to the existence of external suppliers in the end-to-end service delivery chain (cf. G1). But the basic business model is the same as we have already seen in ITIL: Basically, an SLA is regarded as a contract between one customer and one service provider. This contract is located at the customer-provider interface. An extension of this simple model is the provider centric Business Relationship Model. It adds the roles of complementary providers, third party service providers, function and process suppliers, intermediaries and hardware/software/solution vendors. As the biggest stumbling block in SLM, the NGOSS handbook describes the end-to-end service challenge that consists in the delivery of a seamless service through a number of trading partners which is indistinguishable from the same service provided by a single supplier. In the remainder of the handbook, this e2e service challenge is always kept in mind. The handbook even claims to be the first open document addressing e2e service performance issues in SLM. The Business Considerations chapter finishes with a section on service measurement and performance metrics (cf. S2). It first defines four basic prerequisites for an effective service measurement: 1) Parameters must be measurable. 2) The quantification method must be described. 3) A review of the delivered performance must take place. 4) Penalties or incentives must be specified. Furthermore, a metric is defined as a measurable parameter. Ten requirements are defined that should be fulfilled by any specified performance metric. To give an impression, we exemplary name three of them: The metric should provide concrete repeatable measurements in well-defined quantities and without subjective interpretation. The metric should be useful as a specification in a contract in order to enable the customer purchasing the service level he needs. The measuring process should be acceptable to service providers and customers, and artificial performance goals should be avoided. Implicitly, all of these business considerations build the requirements for the developed solutions and draw the context for them. 3) Telecommunications Services: A telecommunications service is characterized by an object-oriented model with the two central entities Service Function and Service Resource. The latter is a superclass of hard- and software, staff

and intellectual property and licenses, demanding only hardand software as mandatory components. Service Resources however enable Service Functions which are divided into the service s Primary Function, Enabling Function and OAM Function (Operation, Administration, Maintenance). This model is much simpler than the generic service model introduced in Section II, but not contradictory to it. It uses the same domains (customer and provider domain) and shares the concept of an SAP. New aspects are the possibility of aggregating SAPs to SAP groups and regarding different layered provider domains. An additional feature of the model is given by its Service Elements (SEs) that are abstract entities out of which a service is composed. In this capability, SEs can be shared between different provider domains e.g. a service provided by A may base upon an SE out of the provider domain of B although not being completely dependent of one of B s full services. Thus, an SE can be a sub-service, a physical resource, a human resource or what ever may be used to build a service. Furthermore, the NGOSS Handbook proposes a Customer Contact Point Reference (CCPR) model which serves as a model for exchanging service performance and management information between a provider and its customer. The Customer Contact Point (CCP) is the logical point at which a customer may manage the services he has subscribed for. In the generic service model of Section II, the CCP is given by the CSM access point which can be accessed by the customer through a CSM client. Again, the two models are very similar. With respect to service performance, the NGOSS handbook introduces additional concepts two of which are the Service Degradation Factor (SDF) and SAP Weighting. An SDF can be used when calculating service (un)availability. It is based on the idea that besides performing well and failing completely, a service may also be partially degraded, but still usable. In order to consider this fact in availability calculations, an SDF which can take any value between 0 (service fully available) and 1 (service fully unavailable) is assigned to each outage event type. Provided that T op is the agreed service operation time, T down is the service downtime and SDF is the Service Degradation Factor for the regarded outage event type, the formula for service availability is now: Availability = T op (SDF T down ) (5) T op Weighted SAPs can additionally be useful in order to take into account different impacts of outages related to different SAPs when calculating service availability (cf. S4). 4) SLA Content and Management: Based on the business considerations and the service model, the handbook gives recommendations for the concrete SLA content and design (cf. S3). These recommendations are arranged in four categories which are: 1) Fulfillment Process (Recommendations 1 to 5): This category contains recommendations concerned with the negotiation and engineering of SLAs. Example (Recommendation 2): For any service the customer should be able to select a) parameters to guarantee and b) value ranges for the parameters. 2) Assurance Process (Recommendations 6 to 13): After concluding the SLA, the recommendations in this category should be followed by the provider when delivering the service to its customer. Example (Recommendation 8): Strong access control and authentication must be provided so that customers are able to access their own data to the extent agreed in the SLA. 3) Customer Interface Management (Recommendations 14 to 16): This category contains recommendations for the communication between provider and customer concerning SLAs and services. Example (Recommendation 16): The provider s CCPs should have information available on the status of any service about which the customer could inquire. 4) General Recommendations (Recommendations 17 to 23): The last category contains general recommendations viable for SLM like e.g. modular assembly of the SLAs or the definition of provider and customer responsibilities. 5) SLA Management Tools and SLA Performance Reporting: Due to space restrictions, we only give a short overview of these two remaining chapters: The title SLA Management Tools might mislead to the assumption that this chapter deals with software tools for SLM which is not the case. It rather presents a Service Life Cycle model which is almost identical to the one we outlined in Section II, followed by a KQI (Key Quality Indicator) Development Methodology that shall help to identify metrics that capture the customer s QoS perception. The third tool is the SLA Parameter Framework that organizes performance parameters into specific categories. In the SLA Performance Reporting chapter, a Performance Reporting Interface, several sequence diagrams for different reporting scenarios as well as a Performance Reporting Process State Model are presented. 6) Conclusion: The NGOSS SLA Management Handbook covers much more aspects and detailed proposals vital for SLM than ITIL does. This is not surprising, since SLM is only one of a total of ten ITIL processes. While the second Volume of the NGOSS Handbook already consists of 204 pages of text, ITIL SLM is described within 33 pages in a comparable style. The descriptions in the NGOSS Handbook are less superficial and much more aimed at straight deployment. V. COMPARISON We now apply the assessment criteria from Section III to the frameworks presented in the previous section. The results are made visible in table form and summarized below. A. Assessment matrix The assessment matrix shown in Table I lists the three groups of evaluation criteria, and for each criterion its degree

Group Assessment criteria ITIL SLM NGOSS Handbook Management aspects M1: Management process M2: Relationships and Dependencies to other management disciplines M3: Management assessment guidelines M4: Business alignment of SLM ( ) ( ) SLA and QoS aspects S1: Mapping support for QoS parameters S2: Measuring support for QoS parameters and service performance S3: SLA templates or design rules ( ) S4: Performance calculation and reporting support ( ) S5: Support of SLA-based charging and accounting General aspects G1: Support for multi domain service provisioning G2: Support for multiple customers service provisioning ( ) G3: Automation and Tool support ( ) TABLE I ASSESSMENT CRITERIA AND EVALUATION RESULTS of fulfillment by ITIL in contrast to NGOSS. A check mark means the aspect is fully or almost fully covered by the respective framework. A cross mark means the criterion is not sufficiently addressed or fulfilled. A check mark in brackets states that the aspect is addressed and partially fulfilled although essential sub-aspects are missing. B. Results The assessment matrix gives a good survey on where ITIL and NGOSS might complement one another, in which areas they overlap and what problems are not yet addressed by any of them. This section gives a summary and additional explanations. 1) Where are ITIL and NGOSS complementary?: Generally spoken, the strengths of ITIL lie in the management aspects. ITIL defines a clear SLM process as well as interfaces to other ITSM processes. Further on, ITIL defines a number of KPIs for evaluating the performance of the process itself. Since the NGOSS Handbook is not process-oriented, there is no overlap or contradiction in this field. Thus, from a management process perspective, ITIL and NGOSS can be used together. The NGOSS guidelines can be assigned to the activities provided by the ITIL SLM process. For example, the NGOSS SLA content recommendations can be applied within the third ITIL SLM process activity ( Contract ). 2) Areas of overlap and potential conflicts: An overlap in the assessment table does not necessarily mean ITIL and NGOSS to be contradictory in the respective aspect. Examination of S3 and S4, the criteria with the most overlap, has proved that again ITIL is much more abstract than NGOSS in its recommendations and practices. Thus, in the end it can be said that there arise no critical conflicts when putting ITIL and NGOSS together. This makes it very attractive to use both ITIL and NGOSS as complementary frameworks in SLM. 3) Unaddressed challenges: For future work in the area of business-driven SLM, the areas of S1 (Mapping Support for QoS parameters), S5 (Support for SLA-based charging and accounting) and G3 (Automation and Tool support) have turned out as most challenging and at the same time most necessary in order to add the missing features to an environment of coexistence of ITIL and NGOSS. In the area of QoS mapping (S1), various efforts have been undertaken in the past, but the fundamental problem of vertically mapping resource QoS to service QoS has not been solved in generality, since each partial solution of this problem needs to address the semantic specifics of a respective service or scenario. A promising approach is the development of a Service MIB that aims at making IT services manageable by adopting a management concept known from traditional Network and Systems Management the Management Information Base (MIB) to them [12]. With respect to Automation and Tool support (G3) there are several pieces of work some of which we shortly present in the next section. All have in common that they support specific elements in SLM and do not cover the entire process. For SLA-based accounting (S5) there are no feasible solutions available today. VI. RELATED WORK Besides the approaches presented in this paper, a lot of papers and white papers on the issue of SLM have been released in the last years. We selected ITIL SLM and the NGOSS Handbook because of their increasing popularity, while at the same time their roots are very different: The ITIL guidelines have been released from the British government as Best Practices. By contrast, the NGOSS Handbook is a development of the Tele Management Forum which is composed of telecommunication enterprises, but also researchers in the area of IT and Telecommunication Service Management. To our knowledge, business-aligned frameworks with a comparable scope as the one of ITIL and NGOSS do not exist. Surprisingly, neither ITIL nor NGOSS have proved as business-aligned in the way we described it in the criterion M4: considering the real monetary business impact of ITSMor SLM-related decisions. In the year 2004, an interesting approach, covering particularly this field, has been published by HP and is called Management by Contract (MbC) [13]. Although MbC would not fit into our frameworks comparison, since it does not share the specifics a framework should entail, we give a very short survey on the objectives of MbC, because

it could be a suitable concept for filling this specific gap. Management by Contract: This approach has been developed and wants to be understood as a paradigm for businessaligned IT Management. Its most important goal is to rationally meet and justify IT-related management decisions on the basis of contractual relationships, considering the business environment and impacts of IT management actions. Insofar, contracts and SLAs are not regarded as a product of, butmore as a basis for IT Service Management. Within the MbC architecture, SLAs play a quite decisive role, though their establishment does not matter for the approach. In the MbC architecture description, SLAs are characterized by the following three aspects: SLAs represent the requirements under which the service provider must deliver. The guarantees are negotiated prior to service deployment, but can be renegotiated over time. SLAs contain parameters of the service (availability and service latency are exemplary mentioned) as well as associated penalties and rewards for both parties. This characterization is very close to the one we gave in Section II. The initial perspective of MbC is the so called conventional 3-layer IT Management Stack which consists of a Monitoring Layer, a Diagnosis Layer and a Recovery Planning Layer. MbC extends this model and adds a fourth layer: the Contract-based Analysis Layer. This one is meant to give a business context to the recovery options coming from the Recovery Planning Layer, reflecting the impact a recovery option would entail based on the commitments specified in the SLAs. Due to space restrictions, we refer to [13] for a summary of the MbC approach. This paper does not only describe the architecture in more detail, but also addresses the process of contract-based analysis and decision making taking place on the Contract-based Analysis Layer. VII. SUMMARY &CONCLUSION In this paper, we analyzed ITIL Service Level Management and the NGOSS SLA Management Handbook as two important frameworks for business-driven SLM. By putting both approaches into a common context of service provisioning and applying a consistent terminology to them, we were able to show how they correlate to each other. The ITIL and NGOSS approaches have shown as quite complementary which already provides an excellent starting point for further integration efforts. While ITIL proposes structure and content of the entire SLM process, NGOSS may be used in order to enrich this framework by valuable recommendations in specific partial aspects especially the concrete design of SLAs. The results of the comparison make one thing visible: Neither ITIL, nor NGOSS should compulsory be considered to be implemented exclusively in one environment. The analysis shows that there are many fields in which ITIL and NGOSS SLM are complementary to each other. Insofar, the relationship between ITIL and NGOSS is not XOR. However, neither ITIL nor NGOSS gives sufficient guidance in the fields of SLA-based charging and accounting and Automation and Tool Support. An application note as it is available for etom and ITIL is not available for the NGOSS Handbook and ITIL SLM, but could be a helpful support for implementers and IT managers who want to adopt concepts from both ITIL and NGOSS. ACKNOWLEDGMENT The author wishes to thank the members of the Munich Network Management (MNM) Team for helpful discussions and valuable comments on previous versions of the paper. The MNM Team directed by Prof. Dr. Heinz-Gerd Hegering is a group of researchers of the University of Munich, the Munich University of Technology, the University of the Federal Armed Forces Munich, and the Leibniz Supercomputing Center of the Bavarian Academy of Sciences. Its web-server is located at http://www.mnm-team.org. This paper was supported by the EC IST-EMANICS Network of Excellence. REFERENCES [1] OGC, Ed., Introduction to ITIL, ser. IT Infrastructure Library. The Stationary Office, 2005. [2] Tele Management Forum (TMF), Ed., SLA Management Handbook: Volume 1 - Executive Overview, ser. NGOSS SLA Management Handbook. Morristown, USA: Tele Management Forum (TMF), 2005. [3] Office of Government Commerce (OGC), Ed., Best Practice for Service Delivery, ser. IT Infrastructure Library (ITIL). Norwich, UK: The Stationary Office, 2001. [4] B. Stiller and D. Hausheer, State-of-the-Art in Economic Management of Internet Services, 2006. [5] M. Garschhammer, R. Hauck, B. Kempter, I. Radisic, H. Roelle, and H. Schmidt, The MNM Service Model Refined Views on Generic Service Management, Journal of Communications and Networks, vol. 3, no. 4, pp. 297 306, Dec. 2001. [Online]. Available: http://wwwmnmteam.informatik.uni-muenchen.de/ php-bin/ pub/show pub.php?key=ghkr01 [6] T. Kaiser, Methodology for the Determination of the Availability of Distributed, Application-oriented Services, Munich, Germany, Apr. 1999. [7] ISO/IEC 20000-1:2005 Information Technology - Service Management - Part 1: Specification, ISO/IEC, Dec. 2005. [8] Office of Government Commerce (OGC), Ed., Best Practice for Service Support, ser. IT Infrastructure Library (ITIL). Norwich, UK: The Stationary Office, 2000. [9] Tele Management Forum (TMF), NGOSS (New Generation Operations Systems and Software) initiative, Object Management Group, Tech. Rep. telecom/01-04-13, Apr. 2001. [Online]. Available: ftp: //ftp.omg.org/pub/docs/telecom/01-04-13.pdf [10] Tele Management Forum (TMF), Ed., SLA Management Handbook: Volume 2 - Concepts and Principles, ser. NGOSS SLA Management Handbook. Morristown, USA: Tele Management Forum (TMF), 2005. [11], SLA Management Handbook: Volume 3 - Service and Technology Examples, ser. NGOSS SLA Management Handbook. Morristown, USA: Tele Management Forum (TMF), 2005. [12] M. Sailer, Towards a Service Management Information Base, in IBM PhD Student Symposium at ICSOC05, Amsterdam, Netherlands, Dec. 2005. [13] C. Bartolini, A. Boulmakou, A. Christodoulou, A. Farrell, M. Salle, and D. Trastour, Management by Contract: IT Management driven by Business Objectives, in Proceedings of the 11th Workshop of the HP OpenView University Association (HPOVUA 2004), vol. 2004, Paris, France, Jun. 2004.