# Understanding SLA Elements in Cloud Computing

Marco Comuzzi, Guus Jacobs, Paul Grefen

► To cite this version:

Marco Comuzzi, Guus Jacobs, Paul Grefen. Understanding SLA Elements in Cloud Computing. 14th Working Conference on Virtual Enterprises, (PROVE), Sep 2013, Dresden, Germany. pp.385-392, 10.1007/978-3-642-40543-3_41 . hal-01463232

HAL Id: hal-01463232

https://inria.hal.science/hal-01463232

Submitted on 9 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Understanding SLA Elements in Cloud Computing

Marco Comuzzi¹, Guus Jacobs² and Paul Grefen¹

¹School of Industrial Engineering, Eindhoven University of Technology
P.O Box 513, 5600MB, Eindhoven, The Netherlands

²PricewaterhouseCoopers Accountants N.V.
P.O. Box 6365, 5600HJ Eindhoven, The Netherlands
{m.comuzzi, p.w.p.j.grefen}@tue.nl, guus.jacobs@nl.pwc.com

**Abstract.** Cloud computing security, interoperability, and vendor lock-in are likely to act as inhibitors of the widespread adoption of cloud computing in organizations. This calls for relational and contractual mechanisms to articulate the desired outcomes of service provisioning and acceptable behavior of service recipients and providers. In this paper we conducted a qualitative study interviewing industry experts to understand the extent to which SLA specifications in traditional IT services outsourcing can be applied in cloud computing, identifying elements becoming redundant or not applicable, and new elements capturing the specificity of the business relationships in cloud computing.

**Keywords:** cloud computing, SLA, IT outsourcing, contract.

# 1 Introduction

Cloud Computing (CC) is increasingly becoming a part of information processing in organizations. Forrester Research [3] forecasts that the global market for CC will grow from $40.7 billion in 2011 to more than $241 billion in 2020. There are many uncertainties surrounding CC, however, which may hinder this growth. Security, interoperability, vendor lock-in, and compliance, among others, are considered to be inhibitors of the adoption of CC [7, 9].

In traditional Information Technology Outsourcing (ITO), formal contracts are drafted in the form of a Service Level Agreement (SLA, [4]), which describes the specifics of the service(s) to be delivered and the engagement expectations of the service recipient (SR) and service provider (SP). In this context, one can ask whether CC changes the relationship specifics between SRs and SPs and, as a consequence, their engagement expectations, i.e., the elements of the SLA.

The core of the relationship between SRs and SPs in CC is not likely to change when compared to traditional ITO: party A requests a service to party B, who can provide this. However, the features of CC form the base for differences in outsourcing relationships that are observed in practice. CC features, such as rapid scaling, pay-per-use, and lower IT upfront investments are beneficial for companies, but also cause
situations that did not occur in traditional ITO relationships. The often unilateral
nature of the relationship in CC results in the SR being more dependent on the SP
when compared to traditional ITO. Moreover, it is often unclear in CC what will
happen to the SRs' data when power outages occur or when data are lost. Another
critical aspect concerns interoperability and migration, that is, unforeseen events
causing a SR to retract the service from one SP and transfer it to another SP. The
issues created by this transfer, in particular about data, are likely to be more relevant
in CC than in traditional ITO. Finally, differences between ITO and CC are also to be
found in the cardinality of the relationship between the SP and the SRs. In CC this
ranges from a one-to-many 'anonymous' relationship in case of a public cloud,
traditionally referred to as the multi-tenancy model in the SP perspective, to a one-to-
one 'close' relationship in a private cloud. The one-to-many case, in particular, is
often not relevant in traditional ITO. Although the outsourced services in traditional
ITO can run on the same software instance, e.g. in time-sharing mainframes or in the
Application Service Provider (ASP) paradigm, the SP usually offers a dedicated
infrastructure for each SR at least for what concerns data, i.e. a separate database
instance for each customer.

In this paper we investigate the CC outsourcing decision process and the related
content of SLAs. About the former, we present a framework analyzing the structure of
the outsourcing decision making process. About the latter, we identify and define the
list of elements required in a SLA regulating the relationship between a SR and a SP.
In particular, we show how the content of the SLA in CC should differ from the one
of SLAs in traditional ITO, which we retrieve from an analysis of the literature.

The paper is organized as follows. In the next section we discuss the research
method that we have adopted in our study. Then we discuss the results of our
investigation. Eventually, we discuss the evaluation of our results and draw our
conclusions.

## 2 Research Method

The first stage of our research is constituted by a literature review, through which we
analyze current published work on SLAs in traditional ITO. The output of this phase
is a comprehensive specification of SLA in traditional ITO. In the second stage we
conduct interviews with experts in the domain of CC outsourcing. Through the
interviews we extend and customize the specification of SLAs in traditional ITO to
the context of CC outsourcing, identifying original SLA elements specific to CC. We
also exploit the coding of the interviews to design the Cloud Outsourcing Framework
(COF), an instrument to support the CC outsourcing decision making process.

The potential interviewees in this stage are selected from the Cloud Computing
taskforce within the Business Assurance Services (BAS) department at PwC
Eindhoven, The Netherlands. Out of the 11 experts in CC identified among group
leaders at BAS, 6 agreed to participate in our study. Each interviewee has a minimum
of 7 years experience in ITO and/or CC in financial services, with an average
experience of 13.7 years. The content of the interviews is analyzed using grounded
theory [6], which is used to enhance the starting theory of SLAs in ITO, widening its scope in the context of CC. The content of the interviews is analyzed using directed content analysis [5], using both codes pre-determined from theory and codes derived from interview content.

Interviews and theory building imply a certain degree of subjectivity in our findings. Therefore, in the last stage we validate our output to assess the clarity, completeness, and usability in practice of the Cloud SLA specification and the COF framework. Validation is performed by interviewing experts with experience in practice about IT outsourcing and CC. The interviewees are selected among the members of the Dutch CIO platform, an independent association of CIOs and IT directors from Dutch private and public organizations. We conducted interviews with 4 experts, with an average executive experience of 16.5 years. We provided the preliminary version of the framework and SLA content analysis beforehand to the interviewees.

# 3 A Framework for SLAs in Cloud Computing

This section summarizes the results of our study. For a more in depth discussion of the codes determined through the literature review and the interviews and the way those have been exploited to construct our results, we refer the readers to [10].

Given the exploratory nature of our work, in this paper we consider only the most common CC deployment models: the Private and Public Cloud (Meel and Grance 2011). In the public cloud, the organization providing cloud services owns the cloud infrastructure and makes it available to the general public or a large industry group. In the private cloud, the cloud infrastructure is operated by the providing organization solely for one specific recipient. Given its exploratory nature, our study does not focus explicitly on the differences among different service models, i.e. I/P/Saas.

## 3.1 SLAs in ITO

In our literature review, we identified two main specifications for SLAs in traditional ITO, i.e. the ones proposed by Goo [4] and Jin et al. [11]. We argue that all the SLA elements identified by Jin et al. can be mapped to elements of Goo's framework. Therefore, we selected Goo's work as the starting point for SLA specification in our research. This mapping is described in [10] and not reported here for lack of space. The SLA elements identified by Goo are listed in Table 1.

<table><caption>Table 1 - SLA elements in Goo's framework [4].</caption><thead><tr><td>Foundation Elements</td><td>Governance Elements</td><td>Change Management Elements</td></tr></thead><tbody><tr><td>Process Ownership Plan, Service Level Contents, Service Level Objectives</td><td>Enforcement Plan, Communication Plan, Measurement Charter, Conflict Arbitration</td><td>Future Demand Management Plan, Anticipated Change Plan, Feedback Plan, Innovation Plan</td></tr></tbody></table>
## 3.2 The Cloud Outsourcing Framework

The objective of the COF is to understand the implications of the nature of the SLA on the decision making process leading to CC outsourcing. We consider a single perspective and multiple aspects. The perspective is the one of the decision maker in the SR organization. The aspects that we consider are:

*   **Process.** The steps involved in the CC outsourcing decision making. We use a process model (flowchart diagram) to model this aspect;

*   **Decisions.** The decision points involved in CC outsourcing decision making. We use a decision tree to model this aspect;

The COF is shown in Fig. 1, which reports the two models and their dependencies.

<figure><img src="image_2.png" /><figcaption>Fig. 1. The Cloud Outsourcing Framework (COF)</figcaption></figure>

In the first step of the decision making process the SR chooses between traditional IT outsourcing and CC outsourcing. This decision is not driven by the nature of the SLA in the two outsourcing options. SR organizations decide to outsource their IT services to cloud SPs for economic reasons, i.e. to reduce IT costs or at least transform IT investments costs into fixed operative operational costs [1], and business-related reasons, e.g. achieving more agile IT services, which can scale and be reconfigured on-demand [2].

Once CC is chosen, the implications of the nature of the SLA start coming into play. The SR organization, in fact, needs to consider the implications of the CC deployment models on the possible SLA that they will be able to establish with the SP. The interviews show consensus along four dimensions along which SLA implications should be analyzed: (i) the degree of *customization* allowed by the SLA, (ii) the *mechanism* to obtain the SLA with the SP provider, (iii) the expected *governance* model of the SLA (which derives directly from the choice of the public or private deployment model), and (iv) the degree of *visibility* that the SR expects on its outsourced IT services entailed by the SLA.

The public cloud CCO is characterized by a (i) standard SLA, based on (ii) a take-it-or-leave-it agreement mechanism (no negotiation allowed), for which (iii) decisions, i.e. governance, are managed unilaterally by the SP, resulting in (iv) the
opaque, i.e. non-transparent, visibility of the outsourced service for the SR. The private cloud CC is characterized by a (i) customizable SLA, based on a (ii) SLA negotiation process allowing for (iii) bilateral governance, resulting in (iv) a more transparent outsourced service.

In public cloud outsourcing the SP drafts a standard SLA that is usually downloadable from its website. There is no active role for the SR other than agreeing to the SLA. We label this type of SLA the U-SLA (Unilateral SLA). The bilaterally drafted SLA in the private cloud is renamed the B-SLA (Bilateral SLA), to underline that it remains a negotiable document. As far as SR's objectives are concerned, a SR in public cloud outsourcing uses the U-SLA to create internal awareness, compare SPs offers, and monitor the performance of the SP. The objectives of the B-SLA are comparable to the ones of SLAs in traditional ITO. The B-SLA, being drafted bilaterally, is used to better define the relationship between the SR and SP, in terms of structuring the relationship and negotiating the characteristics of service provisioning.

In the COF, therefore, when SRs choose for a public cloud solution, they have to evaluate the U-SLA defined by candidate SPs and choose the one that better fits their own expectations. When the private cloud is chosen, the process of choosing the SP resembles the one of traditional ITO, since the SLA would be the outcome of a negotiation between the SR and SP.

## 3.3 Cloud SLA Specification

Regarding the comparison between SLAs in traditional ITO and CC, interviews with domain experts revealed that the SLA specification in traditional ITO (i.e. [4]) is also applicable to outsourcing in CC. This is demonstrated by the fact that the codes from the literature review, i.e. Goo's framework, could be easily used to code the content of the interviews. The extent to which the SLA specification in ITO can be applied in CC, however, depends on the deployment model under consideration. The private cloud CC shares more similarities with traditional ITO and, therefore, it is not surprising that all traditional ITO SLA elements are applicable in the B-SLA. In the case of the U-SLA for public cloud CC, the interviewees identified two traditional ITO SLA elements that are redundant, and one that is partly redundant:

*   **Innovation Plan:** There are two possible scenarios for innovations in the Public Cloud, i.e. incremental innovations that are rolled out in the background or innovations that are announced and rolled out at a specific moment in time (Marston et al. 2011). The SR has no influence on the service content in both scenarios; the SP determines the number and the nature of service innovations. Therefore there is no need for the SR to include the Innovation Plan element in a U-SLA;

*   **Anticipated Change Plan:** in the public cloud the SP controls unilaterally the innovation of its services and such control applies also to unforeseen changes. When unacceptable unforeseen changes for the SR occur, the SR can invoke the Exit Strategy Plan element of the SLA, which is a new contractual element for the U-SLA defined later in this section.

The element that is only partly adopted in the U-SLA is the Enforcement Plan:
* Enforcement Plan : in traditional ITO the Enforcement Plan includes the exit strategy and reward/penalty specifics. In public cloud CC the penalty/reward specifics are not negotiable and are usually downloadable by the SR from the SP website. Therefore they cannot become part of a U-SLA. In the traditional ITO SLA specification, the Enforcement Plan includes also the Exit Strategy. A well specified Exit Strategy is the main countermeasure for SRs to overcome the problem of vendor lock-in. Given the importance of such issue in CC, the interviews suggest to include the Exit Strategy as a new and independent element in the Cloud SLA specification. As a result, the Cloud SLA specification includes the Enforcement Plan element only for the B-SLA, whereas the U-SLA will only include the Exit Strategy element.

The characteristics of CC entail the definition of two new SLA elements:

*   **Data Code of Conduct:** CC inherently causes processes to become opaque (in public cloud to a larger extent than in private cloud). SPs are not or to some extent able to state the specifics of data policies. Compared to traditional ITO, where this was clear and did not require a separate contractual element, this must receive close attention. The Data Code of Conduct element includes the specification of boundaries for data storage locations (e.g., Europe only, exception for USA), and the identification of data access, change and deletion authorizations;

*   **Exit Strategy Plan:** To overcome the issue of vendor lock-in, the exit strategy must become a first class citizen in the Cloud SLA specification. In CC it is of paramount importance to ensure the seamless subtraction of SRs data from the SP, allowing SRs to restore data at a different location/provider. The increased importance lies in the fact that data in the cloud are almost always intertwined with other customer data and their exact location is often unknown. This can cause issues when the SR wants to terminate the relationship. The element Exit Strategy Plan includes the specification of roles and responsibilities for the involved parties, time schedules for exit strategy activities, and conditions that cause the exit strategy plan to be invoked.

# 4 Evaluation

All CIO interviewees in the evaluation stage of our research considered the COF and Cloud SLA specification relevant and useful in a SR's perspective. We received comments mainly about the usability and the completeness of our results.

**Usability.** The members of the CIO platform acknowledge that they, as a platform, are working towards a checklist to assist companies in taking the necessary steps to be ready for the Cloud. The COF and SLA specification can provide a valuable starting point for such a checklist. They furthermore indicate that companies currently are struggling with the exact characteristics of services in CC and what the implications are for SLAs and contracts in general. Although, as discussed later, interviews remark the need to extend the breadth, i.e. more deployment models, and depth, i.e. service models, of our work, the COF and SLA specification can also be used as-is as an initial management tool. The companies that cooperated in the interviews, in
particular, explicitly mentioned that they will distribute our Cloud SLA Specification internally.

**Completeness.** Comments about completeness have been interpreted as suggestions for possible improvement and extension of the framework and the Cloud SLA specification. Although they identified missing aspects in the framework regarding the deployment (community and hybrid) and service models (SaaS, PaaS, IaaS), the interviewees considered the study complete within its scope, with two exceptions related to (i) including industry specific aspects and (ii) the position of the CC outsourcing decision in the COF. The interviewees suggested that the SLA specification should take into account the specificity of the industry where the SR is operating. SRs in highly regulated industry, for instance, are more likely to focus their SLAs on security aspects, whereas providers of critical services will be interested in the performance and possible resilience of the cloud SP. A second important suggestion that emerged during interviews was to possibly delay the outsourcing decision point in the COF. Often, in fact, the decision to opt for a private cloud solution may be taken after a preliminary survey of possible SLAs offered by public cloud SPs.

Our work did not explicitly consider the impact of different service models (e.g., SaaS, PaaS, IaaS) on the content of SLAs in CC. There are, however, indications from the interviews that the different service models do influence the characteristics of SLAs. For instance, SaaS models may trigger further analysis of the SLA elements capturing policies about data management, i.e. data code of conduct and exit strategy. While IaaS and PaaS models usually consider data at a limited level abstraction, i.e. database instance, SaaS model introduce higher levels of aggregation, e.g. business objects in enterprise systems. Further investigation is therefore required to understand how to relate the management of low level database records to higher level entities, such as business objects, when services are retracted by the SR.

The U-SLA and B-SLA analyzed in our work can be used as a starting point for extending our work to include the service models as well. An extended version of our COF framework addressing these comments is presented in [10].

The scope of this research is restricted to the Public and Private Cloud deployment models. The interviews, however, have revealed that there is a practical need for the inclusion of the Community and Hybrid deployment models as well. Since these models derive from a combination of the two models that we considered in this paper, the results of our study should be applicable also to the other two deployment models with only limited further investigation. In particular, we argue that the Community deployment model can be assimilated to the Public Cloud model, provided that the SP has sufficient bargaining power to offer a U-SLA to the community of SRs. In the Hybrid deployment model, more attention has to be put on the analysis of those SLA elements that may cross the boundaries of individual clouds bound together in the hybrid model. The data code of conduct, for instance, should be drafted in such a way that data management policies become homogeneous across the SLAs established for each individual cloud entity.
# 5 Conclusions

In this paper we presented an analysis and specification of SLAs in cloud computing as compared to SLAs in traditional ITOs. We also discussed a framework to support the decision making process in CC outsourcing. The work presented here can be extended along several lines. From the research method perspective, our exploratory approach should evolve into theory building and hypotheses testing as more empirical data about CC adoption become available. From the research output perspective, we are currently working on extensions regarding different service and deployment models, the relative importance of SLA elements as related to industry-specific features, and new aspects and perspectives in the enterprise modeling of the CC outsourcing decision.

# References

1. Alford, T. and Morton, G. (2009) The Economics of Cloud Computing, Booz Allen Hamilton.

2. Amburst, A., Fox, A., Griffith, A., Joseph, A., Kats, R., Knowinski, A., Lee, G., Patterson, D., Rabking, A., Stoica, I., Zaharia, M. (2009) Above the Clouds: A Berkeley View of Cloud Computing, University of California at Berkeley.

3. Forrester Research (2011) Sizing the Cloud. Forrester Research, 2011.

4. Goo, J. (2010) "Structure of service level agreements (SLA) in IT outsourcing: The construct and its measurement." Inf Syst Front, 12: 185-205.

5. Hsieh, H. F., and Shannon, S.E. (2005) "Three approaches to Qualitative Content Analysis." Qualitative Health research, 15(9): 1277-1288.

6. Yancey, M.P. and Turner, B.A. (1986) Grounded Theory and Organizational Research, Journal of Applied Behavioral Science, vol. 22, no. 2, pp. 141-157.

7. Marstons, S., Li, Z., Bandyopadhy, A.Y., Zhang, J., and Ghalsasi, A. (2011) Cloud computing - The business perspective, Decision Support Systems, 51, 176-189.

8. Meel, P. and Grance, T. (2011) The NIST Definition of Cloud Computing (draft). Gaithersburg: National Institute of Standards and Technology, 2011.

9. Northbridge (2011) The Future of Cloud Computing Survey Results. Survey Results, North Bridge, 2011.

10. Comuzzi, M., Jacobs, G., Grefen, P. (2013) Clearing the Sky - Understanding SLAs in Cloud Computing. BETA Working Paper 412, Eindhoven University of Technology, 2013.

11. Jin, L.-J., Machiraju, V., Sahai, A. (2002) Analysis on Service Level Agreement of Web Services. HP Laboratories, 2002.