Towards a cloud computing evaluation and governance framework Addressing its organizational impact, risks, business case and governance.
First supervisor
Second supervisor
External supervisor
Dr. R. S. Batenburg Institute of Information and Computing Science Utrecht University
Dr. M.R. Spruit Institute of Information and Computing Science Utrecht University
Dr. A. Shahim RE Atos Consulting Nedertherlands
Steven Jol 3200442 25-01-2014 Master Thesis Business Informatics
Preface This research is part of the Business Informatics Master at Utrecht University. I hope the developed framework will succeed in assisting management with the evaluation and governance of cloud computing. First of all I would like to thank my supervisors, Ronald Batenburg, Marco Spruit and Abbas Shahim, who gave up some of their valuable time for providing feedback on the deliverables. Also, I would like to thank all the experts and managers who provided input for the development of the framework. Finally, I would like to thank my girlfriend, who did most of the housekeeping so I could concentrate on finishing my research. Steven Jol January 25, 2014
Abstract This research aims to contribute to the body of knowledge on the topic of cloud computing and thereby assisting organizations with the adoption of this technology, by addressing two concerns for top management which are not yet adequately researched: the evaluation of cloud computing and cloud governance. In order to evaluate cloud solutions effectively, a good understanding of its risks, organizational impact and business case is needed. However, these aspects were not researched in an integrative way. Also, a top management’s responsibility is the governance of IT and a concern when adopting cloud solutions. But what does governance mean for cloud computing? Most cloud governance frameworks only address security and do not take into account governance mechanisms, such as processes and structures, to enhance the value of cloud computing applications. Therefore, in this research, a framework is developed which aim to assist higher management with the evaluation and governance of cloud computing by integrating the business case, risks and organizational impact aspects, and providing insights into cloud governance. In order to develop the framework, literature was reviewed in conjunction with additional interviews with six cloud computing experts. This resulted in an initial framework, on which feedback was provided by six potential users and cloud experts. Based on these results, a revised framework was developed, consisting out of two separate models for the evaluation and governance of cloud solutions. After a second round of feedback, a final framework was developed. The main limitations of this research are the limited amount of interviewees that provided feedback on the framework, the possible lack of depth of the cloud evaluation framework and that the focus of the cloud governance model is on reducing risks, despite the objective of approaching cloud governance in a wider perspective. Future research can be done on the topics of cloud security, the organizational impact of cloud computing and cloud governance. The cloud governance framework of this research can also act as input to compare the governance of cloud computing to that of traditional IT outsourcing.
Table of contents 1.
Introduction & Problem statement .................................................................................................. 1 1.1.
Research questions .................................................................................................................. 2
1.2.
Scientific & Social relevance .................................................................................................. 3
1.3.
Thesis structure........................................................................................................................ 3
2.
Research model ............................................................................................................................... 4
3.
Background ..................................................................................................................................... 6 3.1.
Cloud computing technology .................................................................................................. 6
3.2.
Cloud computing defined ........................................................................................................ 8
3.2.1.
Definition......................................................................................................................... 8
3.2.2.
Characteristics ................................................................................................................. 9
3.2.3.
Deployment models ......................................................................................................... 9
3.2.4.
Delivery models............................................................................................................. 10
3.3.
Differences with traditional IT outsourcing .......................................................................... 12
3.4.
Similar work: existing cloud evaluation and governance frameworks .................................. 15
3.4.1.
Cloud evaluation frameworks ........................................................................................ 15
3.4.2.
Cloud information security governance frameworks .................................................... 17
3.4.3.
Cloud governance frameworks ...................................................................................... 19
3.4.4.
Conclusion similar frameworks ..................................................................................... 21
3.5.
Conclusion ............................................................................................................................. 22
4. A semi-structured literature review on the relevant cloud evaluation aspects and cloud governance............................................................................................................................................. 23 4.1.
Method................................................................................................................................... 23
4.2.
Results ................................................................................................................................... 25
4.2.1.
Business case ................................................................................................................. 26
4.2.2.
Organizational impact ................................................................................................... 32
4.2.3.
Risks & Risk management ............................................................................................ 35
4.2.4.
Corporate, IT & Cloud governance ............................................................................... 46
4.3.
5.
Conclusion ............................................................................................................................. 52
4.3.1.
Business case ................................................................................................................. 52
4.3.2.
Organizational impact ................................................................................................... 52
4.3.3.
Risks & Risk management ............................................................................................ 52
4.3.4.
Corporate, IT and Cloud governance ............................................................................ 52
Expert views on the relevant cloud evaluation aspects and cloud governance ............................. 54 5.1.
Method................................................................................................................................... 54
5.2.
Results ................................................................................................................................... 55
5.2.1.
Business case ................................................................................................................. 55
5.2.2.
Organizational impact ................................................................................................... 56
5.2.3.
Risks & Risk management ............................................................................................ 57
5.2.4.
Cloud governance .......................................................................................................... 58
5.3. 6.
7.
8.
Synthesis between literature and expert views .............................................................................. 61 6.1.
Business case ......................................................................................................................... 61
6.2.
Organizational impact ........................................................................................................... 62
6.3.
Risks & Risk management .................................................................................................... 64
6.4.
Cloud governance .................................................................................................................. 65
6.5.
Conclusion ............................................................................................................................. 69
Development of the initial framework: version 1.0 ....................................................................... 70 7.1.
One integrated framework ..................................................................................................... 70
7.2.
Framework requirements ....................................................................................................... 71
7.3.
Cloud governance model high-level design .......................................................................... 72
7.4.
Cloud governance model detailed design .............................................................................. 74
7.5.
Corresponding table & cloud evaluation aspects .................................................................. 78
Expert feedback on the initial framework ..................................................................................... 81 8.1.
Approach ............................................................................................................................... 81
8.2.
Results ................................................................................................................................... 81
8.2.1.
Understandability .......................................................................................................... 82
8.2.2.
Usefulness ..................................................................................................................... 82
8.2.3.
Governance activities .................................................................................................... 82
8.2.4.
Information accuracy ..................................................................................................... 83
8.2.5.
Additional comments..................................................................................................... 83
8.3. 9.
Conclusion ............................................................................................................................. 59
Conclusion ............................................................................................................................. 84
Development of the revised framework: version 2.0 .................................................................... 85 9.1.
Two separate frameworks...................................................................................................... 85
9.2.
Cloud governance framework ............................................................................................... 86
9.2.1.
Cloud governance framework development .................................................................. 86
9.2.2.
The revised cloud governance model ............................................................................ 88
9.2.3.
The corresponding table of the cloud governance model .............................................. 90
9.3.
Cloud evaluation framework ................................................................................................. 92
9.3.1.
Cloud evaluation framework development.................................................................... 92
9.3.2.
The cloud evaluation model .......................................................................................... 94
9.3.3.
The corresponding table of the cloud evaluation model ................................................ 96
9.4.
Relation between the cloud evaluation and governance frameworks .................................... 98
10.
Expert feedback on the revised framework ............................................................................... 99
10.1.
Approach ........................................................................................................................... 99
10.2.
Results ............................................................................................................................. 100
10.2.1.
Understandability ........................................................................................................ 100
10.2.2.
Usefulness ................................................................................................................... 100
10.2.3.
Information accuracy ................................................................................................... 100
10.3. 11.
Conclusion ....................................................................................................................... 101
Development of the final framework: version 3.0 ................................................................... 102
11.1.
Final cloud governance framework ................................................................................. 102
11.1.1.
Final cloud governance framework development ....................................................... 102
11.1.2.
The final cloud governance model .............................................................................. 103
11.1.3.
The corresponding table of the final cloud governance model.................................... 105
11.2.
Final cloud evaluation framework ................................................................................... 107
11.2.1.
Final cloud evaluation framework development ......................................................... 107
11.2.2.
The final cloud evaluation model ................................................................................ 108
11.2.3.
The corresponding table of the final cloud evaluation model ..................................... 110
11.3.
Relation between the cloud governance and evaluation frameworks .............................. 112
12.
Conclusion & Summary .......................................................................................................... 114
13.
Discussion, Limitations & Future research ............................................................................. 117
References ........................................................................................................................................... 120 Appendix A: risk-reducing controls .................................................................................................... 133 Appendix B: interview protocol (development phase) ........................................................................ 137 Appendix C: interview transcripts (development phase) .................................................................... 139 Appendix D: summary expert interviews (development phase) ......................................................... 154 Appendix E: interview protocol (first feedback round)....................................................................... 160 Appendix F: interview transcripts (first feedback round) ................................................................... 161 Appendix G: summary expert interviews (first feedback round) ........................................................ 181 Appendix H: feedback management processes ................................................................................... 182 Appendix I: interview transcripts (second feedback round) ................................................................ 184 Appendix J: summary expert interviews (second feedback round) ..................................................... 199 Appendix K: tools, techniques and additional information ................................................................. 201 Appendix L: existing frameworks analysis ......................................................................................... 208
1.
Introduction & Problem statement
August 26 2006, San Jose VS. The IT sector’s jargon was changed for good. Eric Schmidt, Google’s top man at the time, spoke during the Search Engine Strategies conference and introduced a new concept to describe his company’s software: cloud computing. Although this concept was never heard of, the technology behind it already existed for a couple of years. Basically, cloud computing are services provided over the internet. Whether it is Google’s Gmail, Microsoft’s Hotmail or the social network Facebook, almost everyone will have encountered this kind of software. The success of for instance Gmail is due to its low costs and convenience. Instead of synchronizing e-mails through multiple devices and desktop applications, Gmail allows its users to access mails everywhere and anywhere for free. Cloud computing also promises multiple benefits to organizations, from costs reductions to new strategic possibilities. According to some, it is underhyped (Asay, 2013). The vice president of the data center company Telx even refers to cloud computing as “the latest example of Schumpeterian creative destruction: creating wealth for those who exploit it; and leading to the demise of those that don’t.” (McKendrick, 2013). Success stories of organizations already adopting this kind of software support these statements (Babcock, 2013; Ribeiro, 2013). For example, the entertainment park Six Flags offers occasional promotions for millions of customers on their website, which is hosted on Amazon’s Rackspace. This enables them to scale their resources on-demand and deal with the huge peaks in website traffic when the promotions are online. However, while the benefits apparent, many organizations are still reluctant to move to the cloud. This adoption is inhibited by the concerns of senior decision makers regarding cloud computing (Arlotta, 2013; D'Addario, 2013; Savvas, 2011; PwC, n.d.). These concerns are not limited to security related ones, but also include privacy, migration issues, cloud evaluation/value assessment and governance issues. This research aims to contribute to the body of knowledge on the topic of cloud computing and thereby assisting organizations with the adoption of this technology, by addressing two concerns which are not yet adequately researched: aspects relevant to the evaluation of cloud computing and cloud governance. The first element of this research addresses aspects relevant to the evaluation of cloud computing; that is deciding whether to adopt cloud solutions instead of traditional IT. Cloud computing is perceived as a disruptive technology (Dikaiakos, Katsaros, Mehra, Pallis, & Vakali, 2009) and therefore has unique characteristics compared to traditional solutions. First, it fundamentally changes how IT is provisioned and used (Khajeh-Hosseini, Greenwood, Smith, & Sommerville, 2012). The people, processes, culture and structure of the organization may be impacted (Conway & Curry, 2012). For example, the role of IT employees will become different, as certain technical aspects are not managed internally anymore. Second, as data is often stored on external data centers of the cloud providers, security, privacy and compliance issue arise (Bisong, Syed, & Rahman, 2011).
1
The decision making process on adopting a cloud solution instead of a more traditional IT service is therefore complicated (Morgan & Conboy, 2013). To deal with these complexities, organizations must prepare a business case which covers these factors (Speed, 2011). However, no existing research approaches these elements in an integrative way. This research will therefor address the business case for cloud solutions, the impact of cloud computing on the organization, the risks are of moving to the cloud and how these elements relate to each other. The second element of this research is governance for cloud computing, which is a concern for higher management when adopting cloud solutions (PwC, n.d.). IT governance is applied to ensure the value of IT investments are maximized and its risks are minimized (IT Governance Institute, 2006). Supposedly, the organization’s governance needs to be adapted for cloud solutions (Maches, 2010). But what does this entail? What does governance mean for cloud computing? To the author’s knowledge, most research on cloud governance is limited by security issues. Solely focusing on cloud security possibly leaves out other governance mechanisms which contribute to get the most out of cloud solutions and thus maximizing its value. This research will therefore approach governance for cloud computing from a wider perspective than security. The goal is to provide a high-level overview on cloud governance, in order to provide insights into what cloud governance entails. This may take away higher managements concerns regarding cloud governance, fostering cloud adoption. This could also be used as a basis to structure the governance activities. As governance is a concept which is interpreted and used in many different ways (Simonsson & Johnson, 2006), this research will also address ‘governance’ in general. To fill the gaps in literature, the relevant aspects related to the evaluation of cloud computing and its governance will be addressed in this research. In order to actually assist higher management, a framework is developed which includes the research results. The target organizations are large public and private companies. Small-to-medium sized organizations are already eager to adopt cloud computing, as opposed to larger organizations (Wittenberger, 2013).
1.1. Research questions The main research question is as follows: How can a framework be designed that assists higher management in their evaluation and governance of cloud computing? The first three sub-questions deal with the mentioned aspects which help higher management with the evaluation of cloud computing. I. How can a business case be developed for cloud computing? II. What is the impact of cloud computing on an organization? III. What are the risks of adopting cloud solutions and how can they be managed?
2
The fourth question addresses cloud governance and consists out of three sub-questions. As mentioned in the introduction, governance in general will also be addressed (RQ 4.1). The different perspectives on cloud governance are identified and assessed according to their relevancy, in order to determine which perspective on cloud governance should be included in the framework (RQ 4.1 & 4.2). The content of cloud governance is the subject of last subquestion. IV. How does governance apply to cloud computing? 4.1. What is governance? 4.2. Which perspectives on cloud governance can be identified? 4.3. Which view(s) on cloud governance is (are) the most relevant and therefore the most appropriate perspective(s) for the framework developed in this research? 4.4. What does the relevant perspective(s) on cloud governance entail? The integration of the research aspects into a framework is addressed by the main research question.
1.2. Scientific & Social relevance The main scientific relevance is the construction of a new framework that does not exist yet. It therefore contributes to the body of knowledge on the topic of cloud computing and may be of input for further research. Further, the research presents an integrated overview on the literature of the mentioned aspects, which can be of help to researchers in this field. The expert interviews have also provided new knowledge on the specific aspects which were not covered in literature yet. The social relevance is that the framework aims to help organizations. The framework will help higher management evaluate and govern cloud computing. By taking advantage of the benefits of cloud computing and governing the solutions effectively, organizations can improve its performance. More productive organizations are of benefit to the whole society.
1.3. Thesis structure In the next chapter, the research model is discussed. In chapter three some background is given on cloud computing and related frameworks are discussed. Hereafter the literature review on the relevant subjects for developing the framework is presented. The expert interviews are addressed in chapter five, whereas chapter 6 provides the synthesis between the literature and expert views on the relevant concepts. Chapter seven presents the initial cloud evaluation and governance framework. Chapter 8 presents the results of the feedback on this framework, whereas chapter 9 discusses the feedback on the revised framework. The revised and final frameworks are presented in chapter 9 and 11. Hereafter the research is concluded, the limitations are discussed and future research is presented.
3
2.
Research model
An often applied method in information research is Design Science Research. It entails the construction of an artifact to explain, understand and often improve certain practices relevant to information systems (Peffers, Tuunanen, Rothenbergen, & Chatterjee, 2007). As an artifact is created in order to improve the evaluation and governance practices regarding cloud computing, DSR is the type of research performed in this work. To ensure high quality results are achieved and the research approach is rigor and relevant, the framework of Hevner, March, Park, and Ram (2004) is applied. The framework (adapted for this research) is shown in Figure 1. The environment that is central in this research are higher management of large organizations who want to optimize their cloud computing investments. The business need is some guidance for the evaluation and governance of cloud computing. Another type of input to this research is formed by the knowledge base. This research is based on existing scientific and 'grey' literature and methods are applied for the literature review and the analysis of the interviews. Based on this need and the knowledgebase a framework is developed. Evaluation was done through expert interviews to ensure the provided information in the framework is correct and interviews with possible or potential users gave insights whether the artifact indeed is able to solve the business need. Also Hevner et al. (2004) proposed several guidelines: 1. Design as an Artifact: Design-science research must product a viable artifact in the form of a construct, a model, a method, or an instantiation. 2. Problem Relevance: The objective of design-science research is to develop technology-based solutions to important and relevant business problems. 3. Design Evaluation: The utility, quality and efficacy of a design artifact must be rigorously demonstrated via well-executed evaluation methods. 4. Research Contributions: Effective design-science research must provide clear and verifiable contributions in the areas of the design artifact, design foundations, and/or design methods. 5. Research Rigor: Design-science research relies upon the application of rigorous methods in both the construction and evaluation of the design artifact. 6. Design as a Search Process: The search for an effective artifact requires utilizing available means to reach desired ends while satisfying laws in the problem environment. 7. Communication of Research: Design-science research must be presented effectively both to technology-oriented as well as management-oriented audiences. In this research an artifact is created that can be used by top management, so guideline 1 is met. The framework, based on the technological concept of cloud computing, addresses the problem stated in the problem statement section, is developed in an incremental fashion (guideline 2 & 6) and is of social and scientific relevance (guideline 4). Research rigor is obtained by the usage of well-known research-methods for the literature review and the interviews (guideline 5). The framework that is developed was evaluated by experts and users in order to assess its utility, quality and efficacy (guideline 3). Finally, guideline 7 is met by writing a thesis which includes a detailed description of the research process and how the framework can be applied in practice. 4
Higher management
Cloud evaluation & governance f.w.
Literature and related work on evaluation aspects & cloud governance
Large public and private organizations
Cloud computing
Semi-structured literature review approach Content-analysis for interviews
Literature review Expert interviews User & expert feedback
Figure 1: information systems research framework applied to this research (Hevner et al., 2004)
In Figure 2 the research process is shown. Literature on the cloud business case, risks, organizational impact and governance are used in conjunction with expert interviews to develop an initial, integrated framework. Feedback on this framework was provided by experts and Csuite executives (or people working close to them) leading to a revised framework. Based on another feedback round, a final framework was developed. Chapter 1
Research goal Assist higher management with the evaluation of cloud computing Research goal Assist higher management with the governance of cloud computing
Chapter 4
Chapter 5
Literature on business case, risks, organizational impact
Expert interviews on business case, risks, organizational impact
Literature on cloud governance
Expert interviews on cloud governance
Chapter 6 Synthesis literature and experts view
Chapter 7 & 9
Chapter 8 & 10
Initial and revised Potential user & 2x Expert feeback framework
Chapter 11
Final framework
Figure 2: research process and corresponding chapters.
5
3.
Background
In this chapter the concept of cloud computing is elaborated and related work is discussed. Cloud computing generally refers to IT resources delivered as services over the internet and the hardware and software that provide these services (Zissis & Lekkas, 2012). First the technology behind cloud computing is described. Hereafter the definition that is used in this research is presented, which includes a description of the characteristics of cloud computing, the deployment models and the different delivery models. Hereafter the differences to traditional IT outsourcing will be discussed. Some forms of cloud computing can be considered as a type of IT outsourcing. For this research and the development of the framework it is interesting to assess whether cloud computing is similar to traditional outsourcing or whether it needs to be approached as a distinct concept. Finally, related evaluation and cloud governance frameworks are discussed and arguments are given why they do not adequately address the research objectives.
3.1. Cloud computing technology
Figure 3: technological evolution cloud computing (Klems, Nimis, & Tai, 2009)
Cloud computing is based on already existing techniques, but combines them in a new way. It resulted from the convergence of grid computing, utility computing and web services (Zissis & Lekkas, 2012). Some therefore argue that it is not really a technological shift, but more an economic one (Baars & Spruit, 2012). Figure 3 shows the technical evolution of the technologies enabling cloud computing (Klems et al., 2009). Grid computing is a form of distributed computing that emerged in the 90’s. High performance computers were interconnected with the aim of solving or supporting complex 6
calculations and scientific applications (Zissis & Lekkas, 2012). It is similar to cloud computing in the sense that it employs distributed computing resources to achieve objectives. On the computational level, cloud computing can be seen as a subset of grid computing (Huang & Hsieh, 2011). However, while Grid Computing achieves a high utilization of resources through the allocation of multiple servers onto a single computational tasks, virtualization in cloud computing allows one server to compute several tasks at the same time. This enables the maximization of computing power (Zissis & Lekkas, 2012). Another difference relies in the economic model of the two concepts. Grid Computing is mostly adopted in the public sector, by data intensive users such as universities, whereas cloud computing originates in the private sector (Rings et al., 2009). Virtualization, multitenancy and web services are the main technological enablers of cloud computing (Marston, Li, Bandyopadhyay, Zhang, & Ghalsasi, 2011). Virtualization dates back from 1967, but for decades it was only applied to main frames. The host computer runs a hypervisor, a software application that creates multiple virtual machines. To the user these virtual machines act like physical hardware, which can run any software. This technology is the main enabler of the cloud characteristics. Multitenancy is a related concept, which refers to the sharing of resources. Memory, programs, networks and data are shared between multiple users or tenants at the network level, host level, and application level. With a multitenant architecture, a software application is virtually partitioned, so that each client works with a virtual application instance. One instance of an application thus serves multiple clients or tenants. Web services: this concept refers to clients and servers that communicate on the web over the HTTP protocol. They help standardize the interfaces between applications, making it easier for a software client, such as a web browser, to access server applications over a network. The delivery model of cloud computing is based on utility computing. This concept represents the model of providing resources on-demand and charging customers based on usage rather than by a fixed price (Zhang, Cheng, & Boutaba, 2010). The technical architecture of cloud computing is shown in Figure 4. At the hardware level, a number of physical devices, including processors, hard drives and network devices, are located in datacenters and are responsible for storage and processing of data. The infrastructure layer consists of hypervisors running on the physical hardware, which are responsible for the virtualization of the resources by creating multiple virtual machines. Software platforms are installed (Platform layer) on these virtual machines which deal with the development, deployment and configuration of the software applications. On these platforms the applications are provided to the user (Application layer).
7
Figure 4: architecture of cloud computing (Zhang et al., 2010)
3.2. Cloud computing defined This section will present the definition for cloud computing which is used in this research. This definition includes several characteristics to scope cloud computing and refers to multiple deployment and delivery models.
3.2.1. Definition Many (diverse) definitions of cloud computing exist in literature (Huang & Hsieh, 2011). One of these definitions is proposed by Vaquero, Rodero-Merino, Caceres, and Lindner (2008): “Clouds are a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically re-configured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLAs”. While the authors do mention delivery models in their research, no reference is made to different deployment models. Many researchers that use this definition, seem to scope cloud computing by public cloud solutions. Another definition that is also often used that does take into account different deployment models, is provided by the US National of Standards and Technology (Mell & Grance, 2011): "Cloud computing is a model for enabling convenient, ondemand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three delivery models, and four deployment models." The distinction between the deployment models is important, as other options than public cloud computing could be viable options for companies and the benefits and risks differ between these models. Therefore, this definition is chosen as a point of reference to cloud computing in this 8
research. The characteristics, delivery models and deployment models will be discussed in the succeeding section. The information is based on two papers from the NIST (Mell & Grance, 2011; Badger, Grance, Patt-Corner, & Voas, 2011).
3.2.2. Characteristics The definition for cloud computing used in this research, that of the NIST (Mell & Grance, 2011), includes 4 characteristic to scope cloud computing. These are described below. On-demand self-service. A consumer of cloud services can unilaterally provision computing capabilities, such as network storage, without interacting with the provider. Broad network access. The computing capabilities are available over the network and accessed through mechanisms that promote use by different platforms, such as PC’s, mobile phones and laptops. Resource pooling. The computing resources of the service provider are pooled to serve multiple consumers in a multi-tenant fashion, with different resources dynamically assigned and reassigned according to consumer demand. The consumer of the service generally has no control or knowledge over the exact location of the provided resources, but may be able to determine where de data center is resigned. Examples of resources are storage, processing, memory, and network bandwidth. Rapid elasticity. The computing capabilities can elastically and quickly be provisioned. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time. Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability. Monitoring of the resource usage provide transparency for both the provider and the cloud consumer.
3.2.3. Deployment models The 4 cloud deployment models are private, community, public and hybrid cloud. A private cloud is a cloud solution in which the cloud infrastructure is used exclusively by a single operation, managed and operated by the organization itself or by a third party. The owners can control the infrastructure. One aspect that is often neglected by researchers, is that the infrastructure does not need to be located at the organization's site. It can exits on the premise of the subscribing organization, but also off-premise, at the providers site. In the first situation, the users access the private cloud from within the security perimeter, the policies to protect from remote malicious intruders. In the latter, the private cloud is secured from the other computing infrastructure at the cloud provider’s site and a connection is established between the boundary controllers (e.g. firewalls) of the provider and the customer through a protected communication link, such as a VPN. 9
A community cloud means the infrastructure is shared by several organizations, based on similar interests, like security requirements and compliance considerations. It may be managed by the organizations or a third party and may exist on-premise or off-premise. Within an on-site cloud, each participant may provide services, consume them or provide and consume them both. It is necessary for at least one community member to provide a cloud service. Each organization probably implements a security perimeter. In this case, the participants are connected through protected communication links between the boundary controllers, which allow access through the security perimeters. Optionally, the providers may implement extra security perimeters to isolate the local cloud resources from data centers that are not used for the community cloud. A cloud provider is the one providing the cloud service in the case of an outsourced (offpremise) community cloud. This model is very similar to the outsourced private cloud scenario. The server-side responsibilities are managed by the cloud provider and a security perimeter secures the community cloud resources from other resources. A public cloud is offered to the general public and is owned by an organization providing cloud services. So with this particular model, the infrastructure is always hosted, operated and managed by a third-party vendor from data centers off-premise. The provider's computing and storage resources are potentially large, which serve a diverse pool of clients. The communication links can be assumed to be implemented over the public internet instead of secure connections such as a VPN. Finally, the hybrid cloud is a combination of two or more private, community or public clouds. A hybrid cloud can be extremely complex, but the most adopted configurations are less complex. An example is the combination of a private cloud for routine workloads and public clouds during periods of high demand. Because the communication in the public cloud between the provider and the consumer is in most cases done on the public internet and not through secured communication links, many researchers argue that the public cloud won’t be an option for big companies for years to come (Marston et al., 2011). Others are less conservative and argue that the best combination will be a hybrid cloud: non-sensitive data can be processed on public clouds, while more confidential data will be maintained within a private cloud (Xie, 2011).
3.2.4. Delivery models Cloud computing services are generally delivered through three main delivery models to the consumer, namely Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a service (IaaS). Software as a Service is based on licensing applications on demand, which are already installed on a cloud platform. It is also known as ‘Web services’. Consumers, organizations or users, rent access to an application over a network, typically the internet. SaaS replaces traditional software usage with a rent model, reducing the cost and effort of deploying and managing software. The 10
consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems and storage. The usage fees are typically calculated based on the number of users, the time in use, per-execution, per-record-processed, network bandwidth consumed, and quantity of data stored. Examples are Google Apps and SaleForce, a CRM application. IaaS can be best explained by referring it as Hardware as a Service (Jin et al., 2010). Instead of constructing own data centers, a firm could consider paying to use infrastructure provided by a professional enterprise when they don’t mind to use outsourced clouds. The main consumers are system administrators, who get access to virtual computers, network-accessible storage, network infrastructure, firewalls and configuration services. They are able to deploy and run software, such as applications and operating systems. The consumer does not manage or control the underlying cloud infrastructure, but has control over operating systems, storage and deployed applications. Usage fees are typically calculated per CPU hour, data GB stored per hour, network bandwidth consumed, IP addresses per hour and value-added services used. A well-known IaaS application is Amazon EC2, which stands for ‘Amazon Electric Compute Cloud’. With PaaS, the consumer has the ability to develop, deploy and test applications on the cloud infrastructure using programming languages and tools provided by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations. The consumers can develop their own applications without having to take care of the resource management or allocation problems such as automatic scaling and load balancing (Jin et al., 2010). The usage fees are typically calculated based on the number of subscribers, requested services, the time the platform is in use and the storage, processing, or network resources consumed by the platform. Examples are Google App Engine and Microsoft Azure. This chapter provided some background on the economic and technical concept cloud computing, by providing a definition, describing its characteristics and listing its deployment and delivery models. This is summarized in table 1. Main technological enablers Definition
Characteristics Deployment models
Virtualization, multitenancy and web services "Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three delivery models, and four deployment models." (Mell & Grance, 2011) On-demand self-service, Broad network access, Resource pooling, Rapid elasticity Private (on- and off-premise), community (on and offpremise), public and hybrid cloud
11
Delivery models
Software as a Service, Platform as a Service (PaaS) and Infrastructure as a service (IaaS)
Table 1: summary on the concept cloud computing.
3.3. Differences with traditional IT outsourcing Off-premise cloud computing is a form of outsourcing (Wang, Ren, & Wang, 2011). A third party is responsible for the infrastructure and the maintenance of soft- and hardware. Outsourcing can be defined as “the transfer of services and where applicable, staff and assets to a specialized service provider, and then for the duration of the contract, the receipt of services at an agreed level of quality and an agreed financial compensation structure” (Wijers & Verhoef, 2009). The main motives for outsourcing decisions are economic benefits, technological advantages, innovation and strategic advantages, including increased flexibility and service quality (Böhm, Leimeister, Riedl, & Krcmar, 2011). Traditional outsourcing can be seen as the first options available in the market for companies intending to move some part of their information system outside their organization and consist out of three main models of outsourcing (Salleras, 2013). Infrastructure outsourcing: in order to reduce costs, companies transferred partial or total control of their information system infrastructure to a specialized provider. This include networks, hardware, software and user services (e.g. helpdesk). Typically, long-term contracts were used and outsourcing services were customized. The providers adapted its solutions to every customer to fulfill their individual needs. Application outsourcing: entails the licensing and implementation of software applications by service providers. In-house application outsourcing refers to external personal deploying software on the customers’ infrastructure. The provider develops the application and is responsible of its maintenance. The advances in global internet infrastructure enabled providers to deliver applications to their customers hosted on their own infrastructure. Business process outsourcing: this outsourcing model refers to transferring and delegating technology enabled, non-strategic, business processes to an external service provider. The provider takes care of the information systems hardware and software and is responsible for the management and execution of the processes. While cloud computing is an evolutionary development of various techniques and application outsourcing (Salleras, 2013), there are multiple differences with traditional outsourcing models (Wahlgren & Kowalski, 2013; Benson, & Morgan, 2013; Dhar, 2011; Talukder & Zimmerman, 2010; Hon, Millard & Walden, 2012; Firdhous, Ghazali, & Hassan, 2012; Bradshaw, Millard, & Walden, 2011; Willcocks, Venters & Whitley, 2012; Böhm, Leimeister, Riedl, & Krcmar, 2011). Dhar (2011) provides an overview of the difference between cloud computing and traditional IT outsourcing and is shown in Figure 5. The main difference lies in the degree of flexibility of deploying resources and services (Böhm et al., 2011). The technology behind cloud computing enables elasticity and scalability and services can be procured quickly (Wahlgren & Kowalski, 2013). Because services can be procured easily, cloud computing comes together with a multi-provider environment (Firdhous et al., 2012). Other advantages are lower or no 12
upfront investments (Wahlgren & Kowalski, 2013) and consumers are solely charged for consumption, as opposed to a fixed price of most traditional outsourcing models (Firdhous et al., 2012).
Figure 5: difference between traditional IT outsourcing and cloud computing (Dhar, 2011).
Cloud computing does not solely bring benefits compared to the traditional outsourcing models. Especially regarding security, compliance, governance and data control, multiple disadvantages can be identified (Dhar, 2011; Wahlgren & Kowalski, 2013; Benson, & Morgan, 2013; Hon et al., 2012; Bradshaw et al., 2011). With traditional outsourcing, the customers typically know where their corporate data is hosted, how data is transported and how it is managed. With cloud computing, data is separated from infrastructure through virtualization techniques. Therefore, the precise hardware location of a specific piece of data is difficult to identify (Benson & Morgan, 2013).This leads to a worse legal compliance and a loss in control of the data (Wahlgren & Kowalski, 2013). This difference in control between in-house computing, traditional outsourcing and cloud computing is shown in Figure 6. This level of control does not differ that much between delivery options, but do between deployment models (Wahlgren & Kowalski, 2013). A private, off-premise cloud is more like traditional outsourcing as the customer knows where their data resides (Wahlgren & Kowalski, 2013).
13
Figure 6: difference in control between traditional outsourcing and cloud computing (Wahlgren & Kowalski, 2013).
The more informal relation between customers and providers and the flexible nature of cloud services also lead to a reduced certainty of appropriate legal clauses in the contract and a higher change of hidden costs and risks (Bradshaw et al., 2011). Further, compliance and security risks can arise because most cloud providers are more reluctant for consumers to investigate security breaches and controls at their site, compared to providers of traditional outsourcing services (Hon et al., 2012). Because of the differences between cloud computing and traditional outsourcing, they serve different purposes. Projects that require both economies of scale as well as flexible skills, are best addressed by cloud solutions (Talukder & Zimmerman, 2010). Summarized, off-premise cloud computing is a form of outsourcing, as infrastructure and maintenance is outsourced to a third party. It is an evolution of traditional application outsourcing, enabled by specific technologies. Compared to the more traditional outsourcing models, it brings multiple benefits, such as scalability, no up-front investment and a quick procurement process. As the relationship between the customer and provider is less formal and virtualization techniques are applied, there is a loss of control on the data and infrastructure, leading to more uncertainties regarding security and compliance. Because cloud computing has multiple characteristics which are different than traditional outsourcing, it is expected the evaluation of cloud computing and its governance will need a different approach. It will therefore be tackled in this research as a distinct concept. Traditional outsourcing is out of the scope of this research and literature regarding outsourcing is not taken into account. The results of this section are summarized in Table 2. The next chapter discusses related cloud evaluation and governance frameworks and their shortcomings in addressing the research objectives of assisting higher management with the evaluation and governance of cloud computing. Traditional IT outsourcing
Cloud computing sourcing Benefits of cloud computing compared to traditional IT outsourcing models. Downsides of cloud computing compared to traditional IT outsourcing models.
First options in the market for organizations outsourcing elements of information systems. Consist out of infrastructure, application and business process outsourcing. A type of application outsourcing, enabled by specific technologies. Benefits of cloud computing include flexibility, scalability and no up-front investments. Not always clear where data relies, often no option to check security controls at providers site, possible hidden costs and risks in cloud contracts.
14
Other differences
Cloud computing comes with a multi-vendor environment, shorter contracts and serve different purposes. Table 2: summary of difference between cloud computing and traditional IT outsourcing.
3.4. Similar work: existing cloud evaluation and governance frameworks This section explores existing frameworks for the evaluation and governance of cloud computing in order to underpin why this research needs to be done. First, similar evaluation frameworks are discussed. Hereafter, information security governance frameworks will be explored. As was argued in the introduction, these solely focus on security issues of cloud computing and possibly leave out other mechanisms to enhance the value of cloud solutions. Examples are processes and structures included in the Val IT (ITGI, 2008) framework for IT Governance, which should be implemented to improve the return on investments (ROI) of IT investments, such as portfolio management. Two scientific cloud governance frameworks adhere to a broader view then security, but lack in other areas. These will be discussed as last. The frameworks are identified through a semi-structured approach, as explained in the next chapter on the literature review and the corresponding process.
3.4.1. Cloud evaluation frameworks One element of this research, next to cloud governance, is assisting higher management with the evaluation of cloud computing by providing information on the risks, organizational impact and business case for cloud computing. While no research has addressed these elements integrative, multiple frameworks are proposed to guide decision makers considering a cloud solution, such as the ‘Cloud Adoption Toolkit’ (Khajeh-Hosseini et al., 2012). According to this framework, first the suitability of the cloud technology for the proposed solutions should be assessed. If positive, the decision makers proceed with calculating, for different cloud solutions, the costs, the energy consumption, the impact on the stakeholders (including organizational risks) and modeling the responsibility structure. This framework also includes a suitability assessment questionary, a cost modeling tool and a detailed spreadsheet of the benefits and risks as described by Khajeh-Hosseini, Bogaerts, and Teregowda (2011). Another adoption or evaluation framework is presented by Klems et al., (2009). They discuss some business and technical related issues, which are presented as a framework that could be used to compare the costs of using an outsourced cloud solution to in-house IT infrastructure. According to this framework, first the business domain and the business objectives need to be defined. Technical considerations are the demand usage and requirements such as ‘ease of deployment’ and ‘availability’. The second phase entails the comparison between a cloud solution and a conventional approach. Based on the resource usage (i.e. how much storage or processing power is needed?) and the pricing scheme or utility computing model of the provider, the costs between the two approaches can be compared, which includes indirect and direct costs. 15
A framework that deals with moving a legacy application to the cloud is proposed by Beserra, Camara, Ximenes, Albuquerque, and Mendonca (2012) and is called CloudStep. While its focus is not on the decision of whether to move to the cloud, it takes into account organizational, security and financial constraints. The framework of Conway and Curry (2012) provides a good overview on the activities that need to be performed for adopting a public cloud service, including the evaluation or ‘Architecting’ of a cloud solution. It is developed by a consortium of prominent organizations from the IT industry, including Microsoft and the Boston Consulting Group, and academia. The life-cycle model is shown in Figure 7. For each phase the authors describe the activities that need to be performed, the outputs of these activities and the required capabilities, which are based on the IT Capability Maturity Framework. It can be applied for the migration to the cloud as well to the ongoing management of cloud services. While it does contain planning activities, it does not mention a business case, nor does it provide information on the risks or organizational impact.
Figure 7: the cloud adoption life cycle (Conway & Curry, 2012).
A somehow similar framework as the previous one is proposed by Shimba (2010) as part of his dissertation at the Dublin Institute of Technology. His model, ROCCA (Roadmap For Cloud Computing Adoption) acts as a roadmap for organizations that wants to adopt cloud computing and includes a questionnaire for assessing whether the activities have been performed adequately. Also within this framework, the business case is not included, although it is mentioned in the dissertation. In this section two evaluation frameworks and two adoption frameworks are discussed (see Table 3). Also, one framework deals with the migration of legacy applications. None of them integrated the risks, organizational impact and business case for cloud computing.
16
Authors
Khajeh-Hosseini et al. (2012)
Klems et al. (2009)
Beserra et al. (2012)
Conway an Curry (2012)
Shimba (2010)
Name framework
Cloud Adoption Toolkit
-
CloudStep
Scope
Evaluate cloud computing.
Evaluate cloud computing.
ROCCO: Roadmap for Cloud Computing Adoption Cloud adoption activities
Main disadvantage
Business case not being referred to. No information on organizational impact.
Does not address any of the research aspects.
Evaluate whether to move legacy systems to the cloud. Is focused on which legacy systems to deploy on the cloud, not on the overall decision of adopting cloud solutions. No information on business case or organizational impact.
Managing Cloud Computing-A Life Cycle Approach. Cloud adoption activities Business case not being referred to. No information on organizational impact.
Business case not being referred to.
Table 3: similar work: evaluation frameworks.
3.4.2. Cloud information security governance frameworks Most of the ‘governance’ frameworks for cloud computing address security issues. Rebollo, Mellado, and Fernández-Medina (2012) have performed a systematic analysis of available ‘information security governance’ frameworks. Included frameworks are the security guidelines offered in the whitepapers of CSA (2009) and ENISA (2009), a book written by Mather, Kumaraswamy, and Latif (2009), the ‘Cloud Cube Model’ (Jericho Forum, 2010) and a Virtual Security Information Management System developed by Julisch and Hall (2010). The first three publications only propose guidelines and do not offer a graphical model. More interesting are the proposals of ISACA (2011), Jericho Forum (2009) and Julish and Hall (2010). These frameworks do all, in their own way, assist in developing a strategy around safeguarding information. ISACA’s framework, the COBIT adaptions, will be discussed in the next section, as it is more an overall IT governance framework for cloud computing (Rebollo, Sánchez, Daniel Mellado, & Fernández-Medina, 2011). One interesting note is that according to the authors none of the frameworks addressed all the criteria for an ISG framework they defined. So also in this specific area, more research may be needed. The Cloud Cube Model (Jericho Forum, 2009) helps organizations to discriminate between the available cloud offerings and to choose the formation that best fits the organization’s needs. Also, the Cloud Cube Model proposes the implementation of a Collaboration Oriented Architecture (COA) for securing cloud services in de-perimeterised environments (outside firewall). The COA framework includes a set of guidelines for a secure interaction between users and end-systems located in different security domains. The architecture and guidelines can’t be implemented by cloud consumers on their own, because all participants are required to
17
cooperate in implementing this security architecture. It seems that it would only by viable when all the providers adopt this architecture as a standard. Julisch and Hall (2010) proposed the Virtual Information System Management System (ISMS). ISMS originates from ISO ISO/IEC 27001 and includes a set of processes and policies used by an organization to implement, operate and monitor information security in a plan-do-check-act cycle. A Virtual ISMS expands this concept by addressing the transfer of security controls in cloud environments to make it “suitable for virtual enterprises where IT services are partially outsourced to providers” (Julish & Hall, 2010). Like Julisch and Hall (2011), Ahmad and Janczewski (2011) focus on the responsibilities of the cloud consumer and cloud provider and view these as a central aspect of cloud security governance. The authors introduced a ‘Joint Governance Board’, which acts as a bridge between the consumer and provider and consist out of members of both organizations. It will be responsible for the analysis, approval and implementation of the governance functions, such as risk management. Two frameworks were found which were not included in the review of Rebollo et al. (2012). Almorsy, Grundy and Ibrahim (2011) have proposed a collaboration based security framework. It is based on aligning the FISAM security standard with cloud computing and on security standards for automating the security management process. The focus is on improving collaboration between cloud providers, service providers and service consumers in managing the security of cloud computing. The SeCA model (Spruit & Baars, 2012) allows decision makers to analyze cloud services and architectures on their security specifications based on data classifications. It was meant as an upgrade to the Cloud Cube Model (Jericho Forum, 2009), by including eight attributes instead of four. Before using the model, data classifications should be defined and implemented, describing who can and cannot see, use and execute data, and under which circumstances. Based on these classifications, the model outputs guidelines stating the specifications for appropriate cloud services. The model can also be used ‘back-wards’. Based on a specific cloud model and the data classifications, a short list of services are the output of the model. Four security governance frameworks propose a certain form of collaboration architecture between providers and consumers to safeguard the assets (see Table 4). Further, one model can be used to classify services based on data classifications. However, they do all only cover security issues and do not approach cloud governance in a broader perspective. Authors
Jericho Forum (2009)
Julisch and Hall (2010)
Name framework
Cloud Model
Virtual ISMS
Cube
Ahmad and Janczewski (2011) Governance Life Cycle Framework for Managing Security in Public Cloud:
Almorsy al. (2011)
et
Collaborationbased cloud computing security management framework
Spruit and Baars (2012) SeCA Model
18
Scope
Assist in choosing cloud formation & collaboration architecture
ISMS for cloud services
Main disadvantage
Only security.
Only about security.
about
From User Perspective Joint Governance Board for ‘bridge’ between consumer and provider. Only about security.
Alignment of FISAM security standard with cloud computing
Assist in choosing cloud service based on data classification.
Only about security.
Only security.
about
Table 4: analysis cloud information security governance frameworks.
3.4.3. Cloud governance frameworks Two scientific cloud governance framework were found. Both of them adopted Service Oriented Architecture governance techniques. Guo, Song and Song’s (2010) governance framework (Figure 8) adheres to the view of cloud governance being similar to that of SOA (Service Oriented Architecture) and is applicable when an organization has to “manage and control thousands of services and data elements in the Cloud environment”. They define cloud governance as “controlling access to services using policies, tracking services using repositories, and logging and monitoring the execution of those Services.” Guo et al. (2010) basically translated the governance principles of SOA, outlined by amongst others Linthicum (2009), to cloud computing. They describe the policies that need to be implemented (policy model), operational elements, such as monitoring and interfacing with identity and access systems (operational model) and the core management elements with regards to security, services, risks and policies (management model). The focus is solely on governing policies and services and is therefore not very useful when an organization does not have to manage “thousands of services”.
19
Figure 8: Guo et al.’s cloud governance framework (2010).
For his Master thesis at the University of Twente, He (2011) has developed a process model for introducing cloud governance and is shown in figure 9. In contrast to Guo et al.’s model (2011) it is process-oriented and the strategic goals of the organization and organizational alignment are taken into account. Each phase is described in detail, including the steps that need to be performed and the tools that can be used. It is based on the domains included in the SOA Governance model of Schepers (2007). Schepers (2007) concluded in his paper that the scope of his governance lifecycle is very broad and that it should be aligned with the maturity of SOA. Therefore a maturity model is included which outlines the content of the activities for each maturity level. The model of He (2011) lacks these adjustment for specific maturity levels. When a company does not have a mature Service Oriented Architecture or it is about to introduce only a single service, the governance activities seems overdone. For example, when a company is about to introduce a single CRM application a ‘team of excellence’ is probably not necessary. Further, the model of Schepers (2007) is not validated, while the model of He (2011) is built on top of it.
Figure 9: high level of Cloud governance process model (He, 2011).
Further, The Information Systems Audit and Control Association (ISACA) (2011) has produced an extensive report on control objectives for cloud computing. The main contribution of the report is the adaption of COBIT for governing the cloud. Four governance domains are distinguished, which each contain 34 processes. Every process has four to 15 control objectives. For each objective the applicability and the priority for the cloud delivery and deployment models are depicted. While this is an extensive framework, it is considered to be overkill for higher management to get insights on cloud governance. The goal of this research is not only to assist in governing cloud solutions, but also to take away the concerns of higher management on what governance for cloud computing entails by providing a high-level overview. Second, there is no maturity model provided for the controls, while this is supplied with the ‘normal’ COBIT framework. Many controls seem too excessive for a less-mature cloud environment, such as when adopting a single solution. For example, a control is ‘IT Value Management’, which is noted to be critical for all delivery and deployment models. It seems not clear to what extent the organization has to implement or improve this control when adopting a single cloud solution. Also, it is not a scientific framework. The mentioned frameworks addressed cloud governance in a broader perspective than security, but were not perceived as an adequate framework for providing insights into cloud governance. Guo et al.’s (2010) framework is only applicable when an organization has to manage thousands of services and the one of He (2011) seems overkill because of the resemblance to Service Oriented Architecture governance mechanisms and is based on a non-validated model. The 20
COBIT adaption of ISACA (2011) is too extensive and does not provide a good overview on cloud governance for higher management. Therefore, it is concluded a new governance framework needs to be developed, approaching cloud governance in a wider perspective than security, abstracting away from the level of cloud services and providing a high-level overview. The summary of these frameworks is shown in Table 5. Authors Name framework
Guo et al. (2010) A Governance Model for Cloud Computing
He (2011) The Lifecycle Process Model For Cloud Governance
ISACA (2011) Control Objectives For Cloud Computing.
Scope
Service and policy management through SOA-related tools
Governing a cloud solution through distinct activities
Main disadvantage
Only applicable for managing thousands of services.
Applies SOA methods to cloud computing, which seem overkill.
Controls which need to be implemented to manage a cloud computing environment. Too extensive and complicated for providing an overview on cloud governance.
Table 5: analysis cloud governance frameworks.
3.4.4. Conclusion similar frameworks Related evaluation and governance frameworks were discussed. Two evaluation frameworks aim to assist organizations on whether to move to the cloud and two frameworks cover the whole process of adopting cloud solutions. One framework deals with the migration of moving legacy applications. None of them integrated the cloud risks, organizational impact and business case for cloud computing. It is therefore concluded a new cloud evaluation framework must be developed, which integrates and provides information on the business case for cloud solutions, the impact on the organization and the corresponding risks. Multiple information security governance frameworks were found in literature. Most of them focused on the responsibilities between the consumer and provider. Further, the SeCA model (Spruit & Baars, 2012) is a tool to select cloud services based on data classifications. These frameworks were scoped by security issues and did not take into account other governance aspects, such as processes to enhance the value of cloud computing. Three cloud governance frameworks include other elements than security related ones, but were not considered to be adequate. Guo et al.’s (2010) framework is only useful when an organization has to manage thousands of services, while He’s (2011) seems overkill and it is based on a non-validated framework. The COBIT framework for cloud computing of ISACA (2011) is considered to be too extensive and does not provide a high-level overview on cloud governance. As none of the cloud governance or evaluation framework is considered to be sufficient in assisting higher management evaluating and governing cloud solutions, a new artefact is developed in this research. The results of the similar framework analysis is summarized in Table 6. 21
Existing cloud evaluation frameworks
Existing cloud information security governance frameworks
Existing cloud governance frameworks
Five frameworks were found which assist organizations with the decision-making process of adopting cloud computing. None of the frameworks integrated the business case, organizational impact and risks aspects of cloud computing. Many publications focus on reducing risks of cloud solutions. Five authors provided a model. Most of them focused on the responsibilities between consumers and the providers. The SeCA model provides risk-reducing requirements or an architecture based on the data classification. These frameworks focused solely on security and were not addressing cloud governance in a broader perspective. Two scientific cloud governance frameworks were found. They both adhered to Service Oriented Architecture governance principles, which seem overkill for governing a small amount of cloud services. The non-scientific adaption of COBIT does not provide a good high level overview and no maturity model is provided, which makes it difficult to determine how important a certain control is for a specific level of cloud adoption.
Table 6: summary existing frameworks.
3.5. Conclusion In this chapter the concept of cloud computing is elaborated, the differences to traditional IT outsourcing were discussed and several cloud evaluation and governance frameworks were analyzed. Cloud computing in this research is defined as “a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three delivery models, and four deployment models.” (Mell & Grance, 2011). It consists out of three deployment models, namely a private, public, or hybrid cloud, and three delivery models, Software as a Service, Platform as a Service and Infrastructure as a Service. Although off-premise cloud computing is a form of outsourcing, it has multiple differences compared to traditional IT outsourcing models. It brings additional benefits, such as no upfront investments and scalability of resources, but also risks. The risks are mainly caused by the more formal relationship between the cloud provider and the consumer. The providers are more reluctant to let them investigate security controls and breaches at their site. There is also a higher change for unforeseen risks in the contract. As cloud computing is different than traditional IT outsourcing regarding its purpose, risks and benefits, it is approached as a distinct concept. Finally, this chapter provided an overview on related cloud evaluation and governance frameworks. The evaluation frameworks did not integrate the risks, organizational impact and the business case. The cloud governance frameworks solely focused on security or lacked in other areas, such as being only applicable when managing thousands of services. The collection of information through a literature review for the development of the new framework is addressed in the next chapter. 22
4. A semi-structured literature review on the relevant cloud evaluation aspects and cloud governance This chapter covers the method and the results of the literature review on the subjects relevant for developing the framework. First a description of the structured literature review process is given, which includes the used keywords and search engines. Hereafter, the results are presented for the literature review on cloud governance and the three aspects relevant for the evaluation of cloud computing, namely the business case, organizational impact and risks. While similar frameworks are part of the literature scan, they were discussed and analyzed in the previous chapter.
4.1. Method In this research the purpose of the literature study is twofold. The results were used as input for the development of the framework. Second, it pointed out certain research gaps, which is of scientific relevance. In order to gain a complete set of studies within the literature study, the guidelines of Watson and Webster (2002) were applied. Two approaches were used for obtaining relevant scientific literature (Watson & Webster, 2002). These are the use of the scholarly search engines and following the references from relevant articles. Google Scholar is used as the search engine as it contains studies from multiple journals and the results are ordered by popularity (citations). Below in Table 7 the keywords are shown which were used in the search for literature. The keywords related to the aspects were used in combination with the keywords related to cloud computing. There are five sets of keywords. With regards to the business case of cloud computing, the benefits and cost calculations methods are also considered to be relevant, based on the concept of a traditional IT business case, which roughly consist out of the benefits, risks and costs (IGIT, 2008). Risks are often seen as ‘security’ or ‘compliance’ issues and ‘risk management’ is relevant for the management of cloud computing risks (ENISA, 2009), hence the selected keywords According to Conway and Curry (2012), cloud computing may impact the organizational ‘people/stakeholders’, ‘processes’, ‘organizational structure’ and ‘culture’. The research aspect of the impact on the organization by cloud computing is therefore scoped accordingly. To review governance literature, ‘governance’ was used as a keyword. To find related work regarding the governance part of this research, ‘governance framework’ and ‘information security governance framework’ were used. For identifying cloud evaluation frameworks, ‘evaluation’, ‘decision’ and ‘adoption’ was used, as it is presumed these could all be used to refer to the decision making process whether to adopt cloud computing. The related frameworks were already discussed in the previous chapter.
23
The keywords related to cloud computing consist of the different delivery models and 'Cloud', which covers all the deployment models (private, public and hybrid cloud). For each set of keywords, the first 25 pages of results were taken into account. First the papers were selected based on the title and description provided in Google Scholar. Next, their abstract was read. The articles that were deemed relevant were subject of a whole article analysis. Hereafter, the references were followed. The following inclusion criteria were applied:
The article discussed a relevant topic regarding the organizational impact, the business case, risks or governance of cloud computing.
The following exclusion criteria were used:
The article was written in a language other than English or Dutch. The article was not a scientific paper, but a book or whitepaper. The article addressed the perspective of the provider, instead of the consumer.
The literature scan was finished when no new concepts were found in the set of articles (Watson & Webster, 2002). Based on the initial Google Scholar search, 253 papers were part of the literature set. After the abstract, article analysis and the following of references, 132 papers were selected for the literature review.
24
Research aspects
Cloud computing
Business case Business case Return on investment Benefits Costs Risks Security Compliance Risks Risk management Risk management frameworks Organizational impact Organizational impact Changes in organization Impact on processes Changes in processes Impact on people Changes for people Impact on stakeholders Changes for Stakeholders Impact on Structure Changes in structure Impact on culture Changes in culture Governance Governance Related work Governance framework Evaluation framework Adoption framework Decision framework Table 7: keywords used for literature search.
Cloud IaaS PaaS SaaS
Because the academic domain of cloud computing is relative new and in development, not everything is covered in scientific literature. Less scientific sources were therefore also of help. The normal Google search engine was used besides Google Scholar to find scientific papers and whitepapers that were added to the set of articles in a flexible way in order to illustrate concepts that were not covered by the initial set of articles gained through the structured approach. 38 scientific papers, whitepapers and books were added to the set.
4.2. Results The first part of this literature review will be an exploration of the aspects which were deemed important for top management to evaluate cloud computing. That is the development of a solid business case for cloud computing, the impact on the organization and dealing with cloudrelated risks. Hereafter, the results of the literature on the governance of cloud computing is discussed.
25
4.2.1. Business case An organization bases its decision of adopting a cloud solution on its business case (Ezzat, Elzanfaly, & Mostafa, 2012). That is, as specific cloud solution, a public or private cloud, instead of another more traditional IT service. As already mentioned in the introduction, this is often a complicated process for organizations. While at least the benefits, risks and the organizational impact should be considered in this decision (Khajeh-Hosseini, Sommerville, & Sriram, 2010), other organizational, social, psychological, political and technological factors as well as market dynamics and other hard to quantify factors could all be relevant in this decision making process (Martens, Benedikt, & Teuteberg, 2012). This section explores several areas that are relevant to building the business case for cloud computing. First, the benefits of cloud computing are discussed. These are the reasons why a business case could be positive. Hereafter, the costs calculation methods are bespoken as these are used to determine the value of cloud computing. Finally, the content of a cloud business case and the process of the development are discussed. 4.2.1.1.
Benefits
Because of the mentioned characteristics of cloud computing (e.g. resource pooling), this paradigm could add value to organizations in multiple ways. The main benefits can be grouped into strategic, technical and economic benefits (Zabalza, Rio-Belver, Cilleruelo, Garechana, & Gavilanes, 2012). The latter category entails cost savings, which is the benefit that is most mentioned in literature (Carroll, Van der Merwe, & Kotze, 2011). Organizations that adopt off-premise cloud computing pay only for the time or amount a service is used, so no upfront investments are needed in infrastructure (Brohi & Bamiah, 2011) and no resources are spoiled for unused server space (Maurya, 2010). Less maintenance of the infrastructure and the applications is needed which reduces labor costs (Carroll et al., 2011). An important note is though, that the economic benefits of outsourcing IT capabilities (off-premise), are expected to lasts 2 years compared to private, on-premise clouds (Géczy, Izumi, & Hasida, 2011). Further, with SaaS the software packages do not need to be bought separately for every desktop in the organization (Aljabre, 2012). An important strategic benefit is flexibility (Zabalza et al., 2012). Cloud applications and infrastructures can be rapidly leveraged and will be scaled according to demand (Maurya, 2010). This enables organization to deploy new business services in a fast way (Bhardwaj, Jain & Jain, 2010) and under-provisioning will be avoided, which prevents amongst others downtime of websites that could cause a loss in customers (Brohi & Bamiah, 2011). The elasticity of resources is bounded though by a fixed amount of resources with private cloud computing, but unlimited with public cloud computing (Badger et al., 2011). SaaS offers the flexibility to find an offering that suits the business needs the best, as they are ‘rent’ instead of bought with an off-premise solution (Xie, 2011). Further, cloud services can be accessed everywhere and anywhere with all kinds of network enabled devices (Brohi & Baima, 2011), which allows employees to collaborate on projects and documents on the road (Aljabre, 2012). 26
Besides flexibility, cloud computing also enables organizations to gain a competitive advantage by being able to focus more on their core competence when managed by a third party (Maurya, 2010) and cloud computing could be an answer for a ‘green’ IT strategy (Baliga, Ayre, Hinton, & Tucker, 2011). A technical benefit is the up-to-datedness of the provided capabilities (Géczy et al., 2011). When the software and infrastructure is managed by a cloud provider, the consumers have access to up-to-date computing environments and do not need to be concerned with updates or upgrades issues. Even with on-premise cloud computing managed by the organization themselves updating and upgrading is less burdensome, because of the centralization of IT resources. Also, the compatibility is improved between operating systems. A user can share documents with others having a different type of operating systems (Aljabre, 2012). Further, employees can store more data in the cloud than on their own computers (Bhardwaj et al., 2010) and with SaaS there is no need to download anything, saving time and storage space (Bhardwaj et al., 2010). An important benefit which can be considered a technical, as well as a strategic benefit, is improved security. While security issues are still the main reason organizations are reluctant to adopt cloud computing, it also has some security related benefits (Bhardwaj et al., 2010). Security measures are cheaper when implemented on a larger scale. The centralized nature of as well off and on-premise cloud computing means the application of security-related processes is cheaper compared to a non-cloud IT landscape and security updates for the software and infrastructure can be quicker applied (ENISA, 2009). Further, cloud providers can dynamically reallocate resources for defensive measures, which has advantages for resilience (ENISA, 2009). What not always is mentioned, are to which deployment or delivery model the benefit applies. The NIST provides a good overview of the (detailed) benefits for the specific delivery models (Badger et al., 2011). The cloud migration decision support tool planforcloud.com (formerly known as shopforcloud.com) provides an extensive list of benefits for each of the service and deployment models (Khajeh-Hosseini et al., 2011). 4.2.1.2.
Cost calculation
Relatively many papers discuss the calculation of the costs of cloud computing or determine its value and differ with regards to the used financial metrics, included cost factors and the degree to which ‘soft factors’ are quantified. Yam, Baldwin, Shiu, and Ioannidis (2011) proposed a real option model to help decide decision makers when to switch to a cloud solution. They use NPV as a financial metric and quantified the benefits received from cloud computing, the costs and the risk uncertainties. Because of the use of the real option theory, companies could choose to adopt cloud computing or wait and monitor until for example an improved financial situation or the uncertainty relating to the business value (i.e. Security incidents) is reduced. Another approach is the use of total cost of ownership (TCO), which addresses the real costs of owning and operating IT infrastructure. Martens, Walterbusch, and Teuteberg (2012) proposed a mathematical model to calculate the TCO of off-premise cloud solutions. The included cost 27
factors are based upon a structured literature review. The model only focuses on ‘hard costs’ and do not include any security or risks costs. Li, Li, Liu, Qiu, and Wang (2009) have proposed a similar cloud cost calculation model. Further, return on investment (Misra & Mondall, 2011; Wu & Gan, 2011) or a cost benefit analysis could also be used to determine the value of cloud computing (Kornevs, Minkevica, & Holm, 2012). In the research of Kornevs et al., (2012) the benefits, such as scalability, were quantified. For calculating the costs of an on-premise cloud solution, literature addressing the TCO of cloud computing from a providers perspective (e.g. maintaining a data center) is insightful, as creating these clouds would probably include similar costs as public cloud providers deal with, but on a smaller scale (Khajeh-Hosseini et al., 2010). 4.2.1.3.
Developing the business case
A business case can be defined as "a justification for pursuing a course of action in an organizational context to meet stated organizational objectives and goals" (Remenyi & Sherwood-Smith, 2012). In the context of IT investments, it involves assessing the value of these investments in terms of its potential benefits and its costs, while taken into account the associated risks. Most of the literature that explicitly refer to a cloud business case, are books or whitepapers. An ICT innovation program supported by the Dutch government 'Kennisnet' has provided some information about what a business case for cloud computing entails (“De business case”, n.d.). The decision about adopting a cloud solution is based on the qualitative and quantitative benefits and costs and the associated risks. A cloud computing investment seems to be not that different than other IT investment with regards to the business case. A more elaborated view on the business case for cloud computing is given by Linthicum (2009) in his book. He defines the exact steps that need to be performed to develop a business case for cloud computing, namely ‘Understand the existing issues’, ‘Assign costs’, ‘Model “as is”’, ‘Model “to be”’, ‘Define value points’, ‘Define hard benefits’, ‘Define soft benefits’, ‘Create final business case’. Because the focus of this book is on public cloud computing, He (2011) has adjusted these steps in his master thesis to be suited for all deployment models. The content of a cloud business case according to He (2011) is as follows: 1. A clear understanding of the current business and IT issues the business is facing. 2. The amount of money lost regarding the business issues. 3. The proposed improvements using cloud computing to address the identified business issues. 4. The amount of money, if any, that can be saved using these improvements. 5. Soft benefits: refer to the value points which are difficult to quantify such as customer satisfaction. 6. Hard benefits: refer to benefits in terms of direct and visible cost reduction and/or business efficiencies that are corrected. 7. Holistic impact on the business: evaluate impact of cloud computing for the business in general such as good or bad; perform risk analysis for the possible occurrences
28
which will influence the business case such as legal changes or market changes; articulate chances that the organization will switch cloud In the whitepaper of Raines and Pizette (2010), which is about cloud computing for federal organizations, the content of the business and the context in which it is used are discussed. According to these authors, the business case is part of ‘solution scoping and definition’, as shown in Figure 10. Before establishing a business case, the “cloud services are clarified”. This entails the definition of the exact cloud services the organization intends to consume in order to scope the project. An example is given in the form of this definition: “We will establish a means to lease computer storage by the GB using a monthly payment such as a purchase card.” The next step is to develop a business case. According to the authors, the focus should be on the business needs and objectives, the expected benefits and whether a cloud solution is an appropriate alternative. Hereafter, the service requirements are established, which include among others security and performance requirements. Based on the business case (is a cloud solution an appropriate and beneficial solution?) and the service requirements, a deployment model and service provider is chosen. Supporting information during these steps are the enterprise architecture, program concept of operations and security policies. How these are of support is not mentioned. Further, what is a notable, is the position of the cloud model in the process. It would seem important to for the development of the business case to already decide which model is addressed in order to determine the benefits and risks, as these differ between the models. The authors argue the business case should be based on organizational goals. Examples that they mention are costs reduction and soft benefits like IT agility, access flexibility and scalability. Further, they mention aspects such as the impact on the support staff, performance risks and mission assurance. They summarize it accordingly: “The business case needs to effectively weigh the benefits of cost reduction, scalability, location independence, and other benefits, against the additional exposures or risks added.” When costs can be reduced and the mission of the company can be assured (e.g. the risks are not too high), the business case for cloud computing is positive and thus cloud computing is an appropriate choice.
29
Figure 10 business case and the scoping and definition phase (Raines & Pizette, 2010).
The steps mentioned in the whitepaper of Bruszewski (2011), which discusses the development of a business case for Universities, correspond to the steps mentioned earlier, but also provides some extra insights into how the enterprise architecture could be of support to the business case. The steps in establishing a business case are related to the organizational objectives, the current IT situation, costs and risks and migration issues. Although they do not refer to the concept of enterprise architecture, the second step seems to explain how it could be of use. They argue that a good understanding of the current IT systems is necessary to get an idea of what (which areas or services) are appropriate to migrate to a cloud solution and that the impact on the business processes should be determined for an accurate costs estimation. This is exactly what an enterprise architecture should reveal. The enterprise architecture could also be used to model the ‘As is’ and the ‘To be’ state of the IT landscape, what was proposed by Linthicum (2009) and mentioned earlier. This could be an important step, because a strategic direction of the IT architecture is important for getting the most out of cloud computing (Conway & Curry, 2012). While, it is clear that the business case includes costs, benefits, downsides and risks, the previous two articles that were discussed do not provide support in performing the necessary steps. In a whitepaper about COBIT adaptions for cloud computing, ISACA (2011) makes references to their governance frameworks for assisting top management in developing a business case. The steps and references are shown in Figure 11. First the organization agrees on the business objectives for a new cloud program, such as the introduction of a public CRM service. These objectives are then further detailed into a business case for the cloud. This includes the “itemization of the specific sought-after cloud business advantages compared with known, but allowing for yet-to-be-determined, cloud risk”.
30
Figure 11: establishing a business case according to ISACA (2011).
The overview of the steps and content of the business case mentioned above by the different authors is shown in Table 8. Authors
He (2011)
Scope
Business case
Steps/co ntent
-Current business and IT issues -The proposed improvements -Cost savings -Soft benefits -Hard benefits -Holistic impact on the business
Raines and Pizette (2010) Business case
Bruszewsi (2011)
ISACA (2011)
Business case
-Organizational goals -Cost savings -Soft benefits -Organizational impact (risks, mission assurance, support staff)
-Organizational objectives -the current IT situation -Costs savings -risks and migration issues.
Goal setting & Business case -Goal setting -Develop business case ( -Identify full lifecycle costs and benefits. -Develop the detailed program business case. -IT value management)
Table 8: overview of the content of a cloud business case.
It can be concluded that a business case for cloud computing should evolve around the soft and hard benefits (based on business goals) and the risk. The impact on the organization is an important aspect of the evaluation of cloud computing, as it provides a more holistic view of all the benefits, cons and risks of cloud computing and therefore needs to be assessed. Two aspects were not very clear, that is the exact role of the enterprise architecture and the role of the cloud models in the business case development process. The findings of this chapter are shown in Table 9. In the next section, literature about the impact on the organization by cloud computing is discussed. 31
Benefits
The main benefits can be grouped into strategic, technical and economic benefits. Costs calculation To calculate the costs of deploying a cloud solution, a Total Quality of Ownership method should be applied. To assess the financial benefits, the NPV or ROI metrics can be used. Cloud computing business case Does not seem to differ that much to that of traditional IT investments. It roughly includes the soft and hard benefits (based on business goals) and the risk. The organizational impact analysis should identify the total benefits and risks. Table 9: summary of the benefits, cost calculation methods and the business case for cloud computing.
4.2.2. Organizational impact As mentioned in the previous section, the impact on the organization of a cloud solution should be taken into account when considering cloud computing. The organizations people, processes and culture will be affected, because cloud computing is not only a technical improvement of the IT infrastructure, but also a fundamental change in how IT is provisioned and used (KhajehHosseini et al., 2010). The aspect of an organization that will be impacted the most seems to be the IT department. Although cloud computing is based on existing technologies, the IT employees need to update their skills when working with cloud applications (Rashmi, Mehfuz, & Sahoo, 2012). Their role is likely to change. Users can consume public cloud services instead of internal services, so cloud computing can turn “users into choosers” (Yanosky, 2008). An example is provided in a whitepaper of BP. A group bypassed the companies IT department by using Amazon Web Services to host a new customer facing website (Khajeh-Hosseini et al., 2010). As a reaction, the role of the IT employees could change from “provider to certifier, consultant and arbitrator” of cloud services (Yanosky, 2008). In the case of a large collection of hybrid cloud services, their role will also focus on brokering, integrating and managing public and private cloud services (Erbes, Nezhad, & Graupner, 2012; Sarkar & Young, 2011). The private cloud infrastructure mainly hosts IT management applications, communications tools and business applications such as ERP. E-mail, hosting and storage services are often used from a public cloud. While the portfolio of internal and external services differs between enterprises, in most cases the IT department manages a hybrid IT service portfolio. Therefore, they need to understand which types of services are consumed and needed from as well an operational as a financial perspective (Erbes et al., 2012). An important responsibility for IT managers is to identify the risks in using cloud services and negotiate SLA’s with the providers of these services, in order to ensure that no security, privacy or intellectual property policies are violated (Sarkar & Young, 2011). Also, system support will change. Because administrators will no longer have complete control of a system’s infrastructure anymore in most cases, their work could increasingly involve contacting cloud providers and waiting for them to look into problems (Khajeh-Hosseini et al., 2012).
32
There new role comes together with a decrease in authority and control. The IT department can view this change of role as a threat to their corporate culture, in which they had a certain amount of authority, and to the security of their job (Khajeh-Hosseini et al., 2010). However, according to the case study performed by Sarkar and Young (2011) at a University which moved to an external managed and hosted private cloud, this as a gradual transformation, rather than decline. Besides the changes for the IT department, relatively few scientific research is performed on the effects on other stakeholders or the users. Ali Khajeh-Hosseini et al. (2012) mention that the accounting department will be impacted, because hardware and network infrastructure will be consumed according to a utility model in the case of an outsourced cloud, instead of upfront procurement. Khajeh-Hosseini et al., (2010) have performed a case study to identify the organizational implications of external hosted cloud computing, by researching the perception of the stakeholders with regards to the benefits, risks, opportunities and concerns of the organizational changes. The case study entailed the migration of a quality monitoring and data acquisition system to a public IaaS service Amazon EC2. Some of the mentioned benefits and risks were related to the performance of the organization, such as the opportunity to grow and the risk of decreased service quality. A personal benefit for non-IT related employees was the improvement in job satisfaction and the opportunity to develop new skills, as the cloud environment enabled the creation of new products and services due to cost effectiveness and scalability. This created new challenges for sales and marketing employees and provided the opportunity for them to develop new skills in developing new products. The ability to create new products and services was also perceived as a concern. According to these employees, their job satisfaction could be decreased when unrealistic sales goals were set for these new cloud based services. Further, Sultan and van de Bunt-Kokhuis (2012) discussed cloud computing adoption from the perspective of a radical innovation and the role of the corporate culture in the adoption and use of cloud computing. The authors conclude “that cloud consuming organizations will need to reconsider how they deliver their products and services, view their IT resources and roles, evaluate and calculate their expenditures, value and manage their security, and how they foresee themselves in a, potentially, more environmentally friendly future environment with ethically conscious consumers.“ However, not much concrete changes of the organizational culture are mentioned. One example is a given of a company which adopted a hybrid cloud that began to see their IT infrastructure as a commodity service, instead of a strategic asset. Whether opting for a private, hybrid, or a public cloud implementation, the move to cloud computing will impact the organization’s processes (Rebollo, Mellado, & Fernndez-Medina, 2012). Cloud solutions may alter the way work is done because of the standardized nature of SaaS applications or because of new possibilities, such as the flexibility to work with cloud applications on the road with mobile devices. Also, off-site cloud services need other management than traditional IT infrastructure (Birla & Sinha, 2011).
33
Erbes et al., (2012) emphasize the importance of an integrative service management function for the management of a hybrid cloud solutions. This business role involves the governance of the whole life-cycle of the services, including supplier selection, SLA management, and financial management and to ensure the service portfolio is aligned with the business strategy. This implies the responsibility of life cycle of cloud services move to specific ‘life cycle’ roles within the organization when the cloud environment becomes complex. Further, the management or cloud adoption frameworks of Shimba (2012) and Conway and Curry (2012) present or mention the processes needed for maintaining a cloud solution. They correspond to the ones included in the management or governance framework ‘Information Technology Infrastructure Library’ (ITIL). This is the most used framework for IT service management (Sahibudin, Sharifi, & Ayat, 2008). Two activities are of a higher monitoring layer though and that is the monitoring of service requirements and metrics, such as costs. Jansen (2010) analyzed the processes of the ITIL framework for applicability to cloud solutions. He concluded all of the processes (from service strategy to service design) are relevant, but need to be adapted. Further, security management processes are required for securing a cloud solution (Mather et al., 2009) and a risk management process is needed to identify, manage and monitor risks (CSA, 2011). The processes are shown in Table 10. Authors Conway and Curry (2012)
Shimba (2012)
Processes Issue management Change management Supplier relationship management. Continual service improvement Audit cloud supplier performance and compare to alternatives (vendor management) Service requirements monitoring
Process type Service management
Service management
Contract management Vendor management Technical support Performance monitoring through metrics (e.g. costs) CSA (2011) Risk management Mather, Kumaraswamy, and Latif Access control (partial) (2009) Monitoring system use and access(partial) Incident response Additional processes for PaaS and IaaS (e.g. configuration management). Table 10: processes needed to be implemented to manage cloud solutions.
Monitoring
Monitoring Risk management Security management
Further, ISACA’s (2011) adaption of COBIT for cloud computing provides some information on structural changes within the organization. While there is no need for a new decision making
34
structure, the roles of the employees change towards managing contracts and providers. This corresponds to the processes mentioned in Table 10. The summary of the organizational impact of cloud computing is shown in Table 11. Organizational aspect Processes
Impact Service (e.g. SLA management), security (e.g. access control) and risk management processes must be implemented. Non-IT business processes may be impacted because of standardized nature of SaaS services and the new possibilities of cloud services. Structure Roles of IT employees change to managing services and contracts. Culture Decreased authority of IT employees as business can bypass IT for procuring services. Outside IT department Accounting department will procure services differently. New opportunities (and possibly concerns) for employees because of new possibilities enabled by cloud technology. Table 11: summary of organizational impact of cloud computing.
4.2.3. Risks & Risk management This section deals with the risks of cloud computing. First these risks will be listed. By discussing cloud risk management and appropriate risks responses and controls some light is shed on how these risks can be controlled and managed. 4.2.3.1.
Risks
The security issues of cloud computing is the main reason why organizations are still reluctant to adopt cloud services. As Gartner says, cloud computing has " unique attributes that require risk assessment in areas such as data integrity, recovery, and privacy, and an evaluation of legal issues in areas such as e-discovery, regulatory compliance, and auditing” (Brodkin, 2008). The words ‘risk’, ‘threat’, ‘vulnerability’ and ‘exposure’ are concepts that are often used in literature to point out the security risks of cloud computing, but their exact meaning differ (Dahbur, Mohammad, &, Tarakji, 2011). Vulnerabilities refer to weaknesses in software, hardware or procedures that enables attackers to access resources. This may be a service, unpatched application or an unsecured physical entry. A ‘Threat’ is any potential danger to information or a system due to someone or something exploiting a vulnerability. A ‘risk’ is then the likelihood of someone or something exploiting the vulnerability and the impact on the business. It can be defined as “the possible impact of an event on an organization’s assets and the corresponding expected and unexpected consequences that occur as a result” (Troshani, Rampersad, & Wickramasinghe, 2011).
35
Many scientific papers discuss the security risks, threats or vulnerabilities of cloud computing (Bhadauria, Chaki, Chaki, & Sanyal, 2011; Bisong, Syed, & Rahman, 2011; Carroll et al., 2011; Chen & Yoon, 2010; Dahbur et al., 2011; Paquette, Jaeger, & Wilson, 2010; Sengupta, Kaulgud, & Sharma, 2011; Shaikh & Haider, Dec.; Srinivasan, Sarukesi, Rodrigues, Manoj, & Revathy, 2012; Subashini & Kavitha, 2011; Tanimoto, Hiramoto, Iwashita, Sato, & Kanai, 2011; Yang & Chen, Dec.; You, Peng, Liu, & Xue, 2012; Zissis & Lekkas, 2012). A very comprehensive description of the associated risks and vulnerabilities of cloud computing is provided in a report of the European Network and Information Security Agency (ENISA) (2009). Many other whitepapers have been published on this topic, including by Gartner (Brodkin, 2008). The popular report of ENISA (2009) groups the risks into organizational, legal and technical risks. These categories are often used by scholars. A categorization provided in a scientific paper is provided by Carroll et al., (2011). They have performed an extensive literature review to identify the main security risks of cloud computing and the results were validated through expert interviews. They grouped the risks into six categories described below. (Confidentiality &) Privacy The storage of data on external data centers with off-premise hosting causes issues regarding the legal status of the storage of personal information and the protection of business information. Further, the data’s location could influence the legal requirements for processing and storage and compliance issues could arise due to not knowing where the data is stored. The external storage of data can lead to confidentiality issues too, as it increases the vulnerability of the data being accessed or copied. Also, data leakage can occur due to failures in the networks and authentication mechanisms. Further, a malicious insider of the cloud provider could access the data. Data control When using an outsourced cloud deployment model, the customers have to deal with a loss in governance or data control. As the data is managed outside the organization, it is difficult to protect data and to enforce privacy, identity theft and security policies. Also, as computing resources are shared with other companies, the data could be exposed when one of the sharing companies has violated the law. Availability of data and services The availability of services is threatened by natural disasters and by unclear data backup procedures of the provider. Also, because of lacking standards in tools, procedures and data formats, it is difficult for organizations to migrate from one provider to another or back inhouse. When a cloud provider goes out of business and the customer does not get warned on time, this could have a huge impact on the organization. Further, as cloud services rely on an internet connection, possible bandwidth or connection problems lead to availability issues.
36
Data integrity Data integrity could be affected when networks, applications, databases and system software are not patched adequately or not on time. Further, the integrity could be affected by unauthorized changes made by the service provider and when the shared resources are not isolated well enough. Data encryption Adequate data encryption, key management and cryptographic techniques are very important to prevent unauthorized access by the cloud provider and other tenants who share the resources in a public cloud environment and to prevent data leakage or hijacking of data when it is transported over the network. Logical access As administrative and managed access of the cloud services is gained through the internet, the risk to unauthorized access is much higher than with traditional computing where only a few administrators have access to the system. Weak authentication mechanisms (e.g. weak passwords) increases this risk. Network security There is an increased risk of hacking and intrusion in cloud environments, through security threats such as man-in-the-middle attacks, authentication attacks, side channel attacks, social networking attacks, and denial of service (DoS) attacks. Mobile devices are a new emerging risk, as the mobile users can access the data by bypassing the corporate network. Physical access Large distributed threats are expected for public cloud providers, as attackers can gain access to a large amount of data at one virtual location. Compliance Organizations must comply with legal or in-house requirements for securing data and applications. With off-premise cloud computing data is hosted externally. Still the organizations have to comply with the requirements. Most of the risks mentioned in the other scientific and white papers correspond to the risks mentioned above, so the list is pretty exhaustive, but at a certain abstraction level. Other researchers look more at the detailed network and application attacks (Bhadauria et al., 2011) and the vulnerabilities of cloud technologies (Subashini & Kavitha, 2011). A risks that was mentioned by many other authors, but was obsolete in this list, regards the properly deletion of data. With public cloud computing, the customers are isolated at a virtual level and not through the hardware. This concept is called multitenancy. When data is not properly deleted from the hardware, it could be accessed by other (malicious) customers and so affecting data confidentiality (Zissis & Lekkas, 2012). Also, the availability of services are not only affected by natural disasters, but also by man-made mistakes and security problems at the provider’s site
37
(Badger et al, 2011). Further, some ‘legal risks’ were not covered by the categories, namely licensing and intellectual property issues (ENISA, 2009). An important note are the security differences between public and private clouds. Most of the mentioned risk do not apply to private cloud computing (Chen & Yoon, 2010). Even in offpremise hosting, a real secure network connection can be established. In comparison to public cloud computing which uses the public internet, the hardware is secured from other resources and the consumer knows where the data is stored. So data leakage, compliance issues and many other threats are less likely to occur with this deployment model. The described risks are relevant to all the delivery models, but the specific threats (e.g. man-in-the-middle attacks) differ between these models (Behl & Behl, 2012) and should be taken into account when adopting cloud computing (Subashini & Kavitha, 2011). The delivery models are built upon each other, so the associated vulnerabilities are inherited from lower layered delivery models (Behl & Behl, 2012). It is therefore argued that SaaS introduces more risks than PaaS and IaaS, because more control over the infrastructure has shifted to the providing organization (Bisong et al., 2011). 4.2.3.2.
Risk & Compliance management
IT risk management can be defined as “the process that allows IT managers to balance the operational and economic costs of protective measures and achieve gains in mission capability by protecting the IT systems and data that support their organizations' missions” (Paquette et al., 2010). In cloud settings, “risk management can help deal with the consequences of modification, destruction, theft, or lack of availability of computer assets such as hardware, software data and services that are likely to occur” (Troshani ea., 2011). Basically, it entails the identification, assessment and management of risks (Paquette et al., 2010). The management of the risks should be aligned with the risk apatite and tolerance of the data owner (CSA, 2011). Used risks response strategies are often ‘risk transference’, ‘risk avoidance’, ‘risk acceptance ‘and ‘risk mitigation’ (Tanimoto et al., 2011). If the services are essential to the functioning of the organization, a risk management approach is advised to include the following (CSA, 2011):
Identification of assets Identification of threats, vulnerabilities and their potential impact on assets (risk and incident scenarios) Analysis of the likelihood of the incident scenario’s Management-approved risk acceptance levels and criteria The development of risk treatment plans.
According to CSA (2011), the risk management process should be a shared responsibility between provider and consumer. They need to develop the risk scenario’s together (outcome of risk treatment plan should be part of the SLA) and their risk assessment approaches and assets classification and valuation schemes should be consistent. Julisch and Hall (2010) advise cloud providers to aid their clients in the risk management process by being transparent about the security controls that are implemented. 38
Some of the risks associated with cloud computing are related to compliance. While IT compliance can be integrated into the process of risk management by including the risk of noncompliance (Racz, Weippl, & Seufert, 2011), they are often treated as separated concerns within companies (Guo et al., 2011). Compliance can be defined “as the awareness and adherence to obligations (e.g. corporate social responsibilities, applicable laws, ethical guidelines), including the assessment and prioritization of corrective actions deemed necessary and appropriate” (CSA, 2011). Before moving to the cloud organizations need to understand the relevant legislative and regulatory requirements. For example, if a company processes credit cards, it probably has to adhere to the Payment Card Industry’s Data Security Standard (PCI DSS) (Chaput & Ringwood, 2010). Moyle (2011) describes in a whitepaper how information security and compliance are managed within organizations with regards to cloud computing. According to this author, information security professionals focus on technology-related risks and on deploying controls to lower overall technological risks. Compliance professionals, by contrast, need to ensure that the technology controls address regulatory requirements. As the security controls are often supplied by the cloud provider, the compliance department need the technical knowledge of information security professionals to get insights into the implemented security controls at provider’s site. So both camps need to work together to validate that the security controls of the provider meets regulatory requirements. One approach often used to secure the appropriate collaboration between the two departments is the introduction of a governance, risk and compliance (GRC) function (Racz et al., 2011). Multiple aspects regarding the management of cloud related risks are covered in scientific literature. Rabai, Jouini, Aissa, and Mili (2013) offered a quantitative risk assessment model that enables as well cloud providers as consumers to quantify the risks in order to make decisions according to a quantitative analysis instead of a qualitative one. The Quirc framework is another quantitative risk assessment model that can be used to assess the robustness of different cloud offerings (Saripalli & Walters, 2010). Kaliski and Pauley (2010) introduced the paradigm of ‘Security as a Service’, which involves automated security assessments. An example of such an automation is CloudAudit (CSA, 2011) that provides consumers on-demand information regarding the status of the security controls at supplier’s site. Luna Garcia, Langenberg, and Suri (2012) researched the benchmarking of security assurance of cloud providers according to security statements in their SLA’s. Further, a lot of research has be done on the automated monitoring of Quality of Service (QoS) and availability in SLA’s (Almorsy et al., 2011). Martens, Benedikt, and Teuteberg (2011) have proposed a reference model for the management of risks and compliance issues. Its meta-model is shown in Figure 12. As it is a reference model, it contains all the elements or perspectives that were identified in literature by the authors. One of these elements is the use of key performance indicators. This perspective involves the operationalization of measures and strategic objectives. KPI’s monitor the performance of cloud computing services, risk factors and compliance issues. If a risk factor refers to a compliance regulation it is labeled as a ’regulatory/legal’ risk. A risk is also always 39
specified by a compliance regulation. What this means for risks not related to compliance regulations is not made clear by the authors.
Figure 12: meta-model for risk and compliance management in the cloud (Martens et al., 2011).
While the assessment and management of risks of cloud computing is covered in literature, no comprehensive process-oriented risk and compliance management framework is proposed. However, existing methodologies can be used in developing a risk management framework (Guo et al., 2010). The much known framework COSO is adapted and described in a whitepaper (Chang et al., 2012) for managing risks of cloud computing. The process steps are as follows: Internal environment The internal environment defines the risk appetite of the organization. This determines how risks and controls are viewed and includes internal policies, such as not outsourcing any of its operations. Objectives setting This component entails the evaluation by management of how cloud computing aligns with the organization’s objectives. It may present an opportunity to achieve existing objectives or to gain a competitive advantage, which would require the definition of new objectives. Event identification Opportunities or risks should be identified that can affect the achievement of objectives. External environmental factors (e.g. regulatory, economic, natural, social and technical) as well as the organization’s internal factors (e.g. culture, personnel and financial health) should be considered when identifying and assessing risk events. With the use of public or hybrid clouds events should be taken into account affected by the internal and external factors of the cloud service provider. Risk assessment The risks events associated with the organizations cloud strategy should be evaluated to determine the potential impact of the risks associated with each cloud computing option. The risk assessments should be completed before an organization adopts a cloud solution.
40
Risk response Once the risks have been identified and assessed in the context of organizational objectives relative to cloud computing, the risk responses need to be determined. Four types of risks responses are included in this framework: avoidance, reduction, sharing and acceptance. Control activities The traditional types of controls also apply to cloud computing. Policies and procedures are established and implemented in order to effectively implement the risk response strategies. The difference introduced by cloud computing is that some control responsibilities will be transferred to the provider. Information and communication To effectively manage the risks, management relies on timely and accurate information and communications from various sources regarding external and internal events. External information related to the service provider should also be monitored, as certain events impacting the service provider or fellow cloud tenants might have an impact on the organization. Monitoring The effectiveness of the enterprise risk management program must be continuously monitored for its effectiveness, as risk responses may become irrelevant, control activities may become less effective and the organizational objectives may change. Compliance is integrated in the risk management process through the organizational objectives. An organizational objective is therefore to be in compliance with regulations and laws. The best-practice situation is when the framework is used to identify the ideal configuration of cloud solution options (i.e., business process, deployment model, and service delivery model) by evaluating different solutions in the context of each of the components. This evaluation will enable management to make adequate risk management and governance decisions in both selecting an ideal set of cloud solution options and creating a cloud governance program (risk management strategies, roles and responsibilities) before the cloud solution is implemented. A ‘tool’ to support risk identification is developed by the Cloud Security Alliance (2011), called the Cloud Security Reference Model and is shown in Figure 13. An organization conduct a gap analysis of cloud computing service and deployment models by mapping them against a set of required or recommended security controls and corresponding compliance models (E.g., SOX, HIPAA, PCI). The output of this tool are the ‘gaps’, the security risks which must be managed. It will also guide organizations to select a cloud offering that suit their specific needs.
41
Figure 13: the Cloud Security Reference Model (CSA, 2011)
4.2.3.3.
Risk responses and controls
What controls should organizations implement as a response to the identified cloud related risks? Carroll et al. (2011) did not only provide a list of risks in their research, which were discussed in the previous section, but also controls that can be applied to manage these risks. Other authors that proposed risk response and controls in scientific papers are Tanimoto et al., Fan, Chiang and Kao (2012) and Bisong et al. (2011). Chen and Yoon (2010) describe for each deployment and delivery model the specific aspects that need to be considered when auditing the security of cloud computing. This also provides insights into mitigating security risks. Further, the publications of Badger et al. (2011), CSA (2011), Brodkin (2008), ENISA (2009) and Chang, Leung, and Pili (2012) provide risk responses and controls. The guidelines of CSA (2011) for securing cloud computing are very detailed and therefore not taken into account in this section. They do provide comprehensive information about amongst others securing applications, incident handling and assurance of cloud providers and should be reviewed when moving to the cloud. Summarized, the controls entail identifying SLA and provider requirements, evaluating of service level agreements and providers, monitoring (including third party audits), developing availability-risk-reducing strategies, implementing security controls at consumer’s site and a data classifications scheme (see Appendix A). In this section the controls are described for three broad categories of risks. These differ from the categories used to describe the risks, which were adopted from Caroll et al. (2011), but do cover the same risks. Privacy is a different concern than data confidentiality (Mather et al., 2009), hence the distinct category. The controls for the risks other than compliance and 42
availability related ones are overlapping and could therefore be placed in one category concerning data confidentiality, integrity and control. Privacy: To ensure the data processing adheres to privacy laws, the providers have to prove the effectiveness of their data privacy controls (Carroll et al., 2011) and that they obey to local privacy requirements and processing (Chang et al., 2012). It is not recommended to allow sensitive data on the public cloud. Therefore effective data classification policies and processes should be in place to determine which data is appropriate (Chang et al., 2012). Further, the location of the data that will be processed by a cloud provider should be evaluated whether data protection compliance laws will be achieved (Chang et al., 2012). Data confidentiality, integrity and control: Cloud computing often introduces a loss in governance or control on the data and infrastructure (Figure 14). Therefore, it must be assured the service provider provides transparency of security controls (Carroll et al., 2011) and data operations (Badger et al., 2011). The security controls of the provider should be evaluated before adopting the cloud service (Carroll et al., 2011). The level of these controls should fit with the risk appetite of the consuming organization (Chang et al., 2012). Also, the employees of provider should have adequate skills for managing security breaches (Carroll et al., 2011). The provider should inform about people who manage and access the organizations data and who hires administrators and how (Brodkin, 2008). The Cloud Security Alliance offers the GRC stack, which includes a control matrix. This matrix can be used to assess the security controls at the provider’s site. Similar assurance tools are also provided by ISACA (2011) and ENISA (2012).
Figure 14: level of control for each cloud model (Mather, Kumaraswamy & Latif, 2009).
Depending on the selected cloud delivery model, security control responsibilities might be shared and should be made clear in the SLA with regards to patching, control and access over encryption, standards and key management (Carroll et al., 2011) and other issues with regards to implementation, technology operations and user access administration (Chang et al., 2012). ENISA (2011) provides a table with the responsibilities for each delivery model that are typically determined in a service level agreement (SLA). The appropriate security controls the consumer is responsible for should be implemented, including encrypting data hosted on cloud 43
solutions to overcome cyber-attacks (Chang et al., 2012) and securing mobile devices that are connected to the services (Carroll et al., 2011). The cloud adapted COBIT framework of ISACA (2011) also provides information about proper security controls at consumer’s site. Further, an agreement should be made about the reporting structure of incidents and its control mechanisms all the way to the CIO and CEO (Chen & Yoon, 2010). After adoption, the security controls of the provider should be periodically verified for its effectiveness (Chang et al., 2012). Another issue is data ownership. The consuming organization should ensure that the SLA agreement clearly state the data is owned by the consuming organization (Chen & Yoon, 2010). The consumer needs to research which regulations and laws apply (e.g. patriot acts) to the stored data that can lead to data surrender, what information in this situation will be surrendered and about the options to avoid such surrenders (Chen & Yoon, 2010). To prevent data leakage and unauthorized changes to the data, the SLA should state the cloud provider is obligated to provide auditable records of changes made to cloud data or should provide prove that no unauthorized changes occurred (Carroll et al., 2011). A mechanism should also be offered for reliably deleting subscriber data on request as well as providing evidence that the data was deleted (Badger et al., 2011). The consumer could insure themselves against data leakage (Tanimoto et al., 2011). Third party audits play an important role in assuring that appropriate data security controls are implemented and compliance is achieved. Therefore, the consuming organization has to investigate whether the provider is willing to be subjected to external audits and security certifications (Badger et al., 2011). These audits should “be performed on a regular basis to monitor the cloud service provider's compliance to agreed terms, and the effective implementation of and adherence to security policies, procedures and standards” (Carroll et al., 2011). Further, after adoption, a third party should check whether the SLA content is filled (Tanimoto et al., 2011) and should be requested to surveillance the movement of data when the provider is asked to remove the data (Tanimoto et al., 2011). Lastly, in order to assure information quality and prevent unauthorized cloud action, the consumer has to implement policies that clarifies the business process and data that is appropriate to be supported by cloud solutions, who procures cloud solutions and how to manage the relationship with cloud providers (Chang et al., 2012) Availability: A big concern regarding availability, is the cloud-provider lock-in. To prevent this from happening, the consuming organization must check whether the cloud provider support adequate interoperability standards (Carroll et al., 2011) and an exit strategy or contingency plan should be developed (Chang et al.,, 2012). Further, when using an IaaS service, a strategy for the migration of Virtual Machines and their associated storage among alternative cloud providers should be formulated (Badger et al., 2011). To mitigate the risk of the cloud provider going out of business, the continuity plan should be evaluated whether the availability goals are supported (Badger et al., 2011). The providers 44
should convince customers that their data will remain available when they go out of business (Brodkin, 2008). As a response to natural disasters, the capabilities of providers with regards to the backup of data, archiving and recovery should be examined and whether the provider offers redundancy (placement of data in multiple data centers) (Badger et al., 2011). The consuming organization self should also write a disaster recovery plan (Badger et al., 2011). With cloud computing the services are depended on the network. To ensure there is no latency and that an adequate performance can be achieved, network limitations of the organization should be determined before moving to the cloud (Carroll et al., 2011). The current applications should be benchmarked and key performance score requirements should be established before deploying the applications in the cloud (Chang et al., 2012). The desired performance and availability of the application should be stated in the SLA (Badger et al., 2011). For several reasons outages could occur on the providers site. A fail-over strategy should be developed. Another provider’s service solution or an internal solution should be used when services are not available (Chang et al., 2012). One approach is to contact providers that offer the same solution as your primary CSP and maintain copies of your organization’s data so it can easily be deployed to the backup provider (Chang et al., 2012). Also tools scan be implemented that provide resources on demand for the cloud solution from another provider (Chang et al., 2012). Further, to mitigate the availability risks, an insurance can be closed for a provider going out of business or the unavailability of services (Tanimoto et al., 2011). After adoption the system availability and performance should be monitored (Chang et al., 2012). Compliance: The controls concerning compliance related risks overlap with these of the security risks that are associated with the loss of data governance, as security controls are as well relevant for securing data as complying to regulations and industry standards. The consuming organization should check whether the appropriate security controls are applied at provider’s site. It should also be ensured that the cloud service provider is open to external audits and security certifications and that logs ensuring compliance are available (Carrol et al., 2011). A big issue with regards to compliance is that the data location is not always known to the consuming organization and that specific regulations could apply to the location. Therefore, providers should prove that the data is only stored in the geographic locations specified in the SLA or another contract (Carroll et al., 2011). The consumer should evaluated whether data protection law compliance will be achieved by storing data in this location (Chang et al., 2012). It must be ensured that the providers adhere to requirements specific to the data location, comply with regional laws and regulations and that the laws and regulations are formally incorporated and documented in governance policies (Carroll et al., 2011). The SLA or other contracts should define the providers responsibilities regarding adhering to compliance and regulatory requirements on behalf of the organization (Chang et al., 2012). 45
After adoption, regulatory changes that would affect the consumers and the providers operations should be monitored (Chang et al., 2012). Just like the risks differ between service and deployment models, so do the controls. However most researchers do not discriminate between these models and only list generic risks and controls. As mentioned previously, Chen and Yoon (2010) list specific area’s that should be investigated when auditing a cloud for each deployment and delivery model. For the private cloud this only entails the establishment of a reporting structure and the development of a disaster recovery and continuity plan. For a community cloud, the tenants should develop an exit strategy and a clear management structure should established. In their research the private and community cloud do not make use of outsourced IT services. In case of an outsourced private and community cloud more risks controls are probably necessary. In this section the risks of cloud computing and how they can be managed were addressed. The summarized results are shown in Table 11. The next section discusses cloud governance. Aspect Risks
Risk management
Risk-reducing controls
Results Private cloud has less risks than public clouds. Risks can be grouped into: Confidentiality & Privacy, Data control, Availability of data and services, Data integrity, Data encryption, Logical access, Network security, Physical access and Compliance The process for identifying and managing risks. The process entails identifying assets in the cloud (processes and information), identifying risks and developing risk mitigation strategies. To manage cloud risks, SLA and provider requirements should be identified, the SLA and provider should be evaluated or negotiated, internal security must be addressed, availability strategies must be developed, a data classification must be implemented and certain aspects must be monitored.
Table 11: summary of cloud risks and risk management.
4.2.4. Corporate, IT & Cloud governance The previous sections explored the aspects relevant for the evaluation of cloud computing. That is, adopting cloud solutions instead of traditional IT applications. This section will discuss cloud governance, the second aspect of this research, and is addressed by the fourth research question. The three sub-questions are all addressed in this section.
46
Originally, ‘governance’ is a term which originated from the Greek, and means ‘to govern’, steer, devise, guide and control (Ahmed & Janczewski, 2011). Plato was the first one to use this word to describe a system of rules. Corporate governance is the highest level of governance in an organization. The scope of this concept differs between definitions, because they are dependent on the perspective of the author (Babic, 2010). There should be no debate though, on the goal of corporate governance. Within organizations the managers control the key decisions of the corporation, while not owning the company. The subject of corporate governance is how the shareholders, as external stakeholders, control management. Corporate governance mechanisms entail the solution to this problem of separation of ownership and control (John & Senbet, 1998). These mechanisms together, form the system of corporate governance and can be defined as “the manner in which companies are controlled and in which those responsible for the direction of companies are accountable to the stakeholders of these companies.” (Babic, 2010). Financial suppliers (i.e. shareholders) use these mechanisms for a maximization of their return on investment and fall in two groups, internal to the organization and those external to the organization (Gillan, 2006). The internal mechanisms include ownership concentration, board of directors, management incentives and a multidivisional organizational structure. The external mechanisms refer to the market for control, such as hostile takeovers for a change of top management (Babic, 2010). The board of directors is an important aspect of corporate governance, as they monitor management and have the mandate to hire and fire the senior management team on behalf of the stakeholders (Gillan, 2006). The actions of this board are considered as enterprise governance and include, besides monitoring management, the overall corporate culture, policy and direction setting (Bird, 2001). While IT governance is commonly seen as a subset of corporate governance (Webb, Pollard, & Ripley, 2006), it is a more ambiguous term, often referring to very different aspects of IT within an organization (Simonsson & Johnson, 2006). What is clear though, is that the goal is different than to that of corporate governance and is mainly focused on optimizing IT (Webb, Pollard, & Ridley, 2006). The ambiguity of this term can be described by elaborating one of the most used definitions of IT governance, that of the IT Governance Institute (2006): “IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization’s IT sustains and extends.” What constitute these structures and processes is not made very clear and often interpreted differently by scholars. Some authors, which use this definition, refer to the processes as strategic decision making processes (Heas & Grembergen, 2005), others to all processes for managing IT within an organization (Ribeiro & Gomez, 2009). The second problem of this definition, is that IT governance is described in the corresponding document as a process performed by the board and executive management of setting objectives and strategy, directing management and monitoring of to what extend the objectives are achieved. This is a step of actions, a process, and not a system or framework of structures and processes. 47
ISACA’s COBIT version 5 (2012) possibly provides some insights into the difference between the concept of IT governance and the actions performed by a governing body. According to their ‘Evolution of scope’ (see figure 11), COBIT 4’s processes, which include organizational structures, are combined the system of IT governance. This is for management to gain control on IT through ensuring “business objectives will be achieved and that undesired events will be prevented or detected and corrected” (Heas, Grembergen, & Derbenceny, 2013). The difference with IT management (COBIT 3), is that IT governance also includes a strategic element like portfolio management (Grembergen & Heas, 2004). Operational IT Governance, such as development processes, is similar to IT management. COBIT 5 adds a ‘governance’ layer to IT Governance, and is being referred to as ‘Governance of Enterprise IT’ (GEIT) (Figure 15). The difference between COBIT 4 and 5 is that this version also contains governance processes, which deal with the implementation and monitoring of the management processes (Lew, 2013) (Figure 16). So where the IT Governance Institute (2006) tried to catch both the framework of processes and structures as well as the actions of a governing body under the umbrella of IT governance, ISACA seems to use different terms.
Figure 15: ISACA’s COBIT evolution of scope (Lew, 2013).
Figure 16: The relation between governance and management (ISACA, 2012).
48
This ‘Evaluate, Direct and Monitor’ perspective on IT Governance is adapted from ISO/IEC 38500, an international standard on the ‘Corporate Governance of IT’ (ISO/IEC, 2008). The relation between business and management processes and these governance practices is shown in Figure 17. According to ISO/IEC 38500 (ISO/IEC, 2008) the governors should do the following: “a) Evaluate the current and future use of IT. b) Direct preparation and implementation of plans and policies to ensure that use of IT meets business objectives. c) Monitor conformance to policies, and performance against the plans.” (ISO/IEC, 2008).
Figure 17: governance activities of directors (ISO/IEC, 2008).
To make things even more complicated, the popular definition of Ross and Weill (2004) does not refer to any of these aspects. They argue corporate governance is extended by making use of corporate governance mechanisms for and effective management of IT to achieve organizational goals. They define this concept as: “the decision rights and accountability framework for encouraging desirable behaviors in the use of IT” (Ross & Weil, 2004). The need for this framework, is to prevent IT managers to handle issues in isolation. By making people accountable for IT, its effectiveness are assumed to be improved. However, they do argue this accountability framework should be used in conjunction with specific IT decision making domains or processes. Their perception of IT governance does therefore not differ that much with the vision of Haes and Grembergen (2005) mentioned above, although they emphasize accountability. So there seems to be three different perspectives on IT governance. At one side, there is the perspective of an organizational framework of structures and processes to optimize IT. Some authors scope the processes by strategic decision making processes, others include all IT 49
related processes as are covered by for example the ITIL framework. On the other side, it refers to a process performed by the board and top management who are responsible for this framework and the monitoring thereof, to which ISO/IEC 38500 (ISO/IEC, 2008) refers to as ‘Corporate Governance of IT’. The relation between the two types of governance and traditional IT management is shown in Figure 18, based on the views of Grembergen and Haes (2004), ISACA (2012) and ISO/IEC 38500 (ISO/IEC, 2008). The popular governance frameworks of COBIT and ITIL are placed within the figure to show to which type of governance they belong. Corperate Governance of IT Directors (Board & Top management) Oversight of IT
ISO/IEC 38500
COBIT 5 Governance processes
Evaluates & Directs
Monitors
IT Governance Committees, Executives & Management Processes & Structures to manage IT COBIT 4 / 5 (Management processes)
Operational Governance = Traditional IT management (E.g. Delivery)
ITIL
Strategic Governance = Additional layer to IT management (E.g. Portfolio management)
Figure 18: relation between two types of governance and traditional management (ISACA, 2012; ISO/IEC, 2008, Grembergen & Haes, 2004).
Opposing views are not only restricted to IT governance. With regards to cloud governance, multiple ‘schools of thought’ can be distinguished. The first one is the SOA (Service Oriented Architecture) governance school (Guo et al., 2010; Lithithicum, 2009). SOA governance refer to the controls and processes to enforce and monitor the application of SOA policies (Schepers, 2008). This type of governance mechanisms are to gain control on the cloud services. The authors which support this view assume an organization has many cloud services which are integrated into their Service Oriented Architecture. The second school is that of security. Ahmed and Janczewski (2010) define cloud governance as the processes and structures for reducing security issues, while Halpert (2011) defines cloud governance as the strategic management of cloud security. This actually refers to information security governance (ISG) for cloud computing. ISG is a subset of IT governance and entails the leadership, organizational structures and processes safeguarding information (Rebollo et al., 2011). The identification of risks and the mitigation plans (i.e. risk 50
management) are part of information security governance, but also other aspects can be included in an organization’s ISG approach or strategy. The third school sees cloud governance as the extension of IT governance; that is all the processes and structures needed to maximize value and minimize risks (Remmé, 2010; ISACA, 2011). As this view also include processes to enforce and manage policies and covers security, it is the most comprehensive one. However, because multiple views on cloud and IT governance exist, the interviews which were held in this research also addressed the views of the experts on cloud governance. The definition for ‘cloud governance’ which was used in this research will therefore be discussed in the section afterwards. Table 12 provides an overview of the identified perspectives and the corresponding authors. Perspective on cloud governance Author Cloud governance is similar to Service Oriented Guo, 2010; Lithithicum, 2009; Architecture governance Cloud governance is about securing information and Ahmed and Janczewski, 2010; Halpert, 2011 business processes Cloud Governance is the extension of IT Remmé, 2010; ISACA, 2011 Governance: processes and structures. Table 12: the three perspectives on cloud governance and corresponding publications.
This section addressed corporate, IT and cloud governance. The summarized results are shown in Table 13. Aspect Corporate governance
Result Mechanisms for company owners to control management, such as the board of directors and managing incentives IT Governance Diverse interpretations for IT governance How an organization is structured (processes and structures) to maximize value and minimize risks Some only include strategic processes, such as portfolio management, others all processes as are included in for example the ITIL framework. Accountability framework for IT related decisions Evaluate, Direct and Monitor activities are directing the management processes and structures (IT governance), which is referred to as ‘Corporate Governance of IT’. Cloud governance Three schools of perspectives: Addressing security Controlling cloud services through SOA governance principles. Extending IT governance; processes and structures to manage cloud solutions Table 13: results of literature review on corporate, IT and cloud governance.
51
4.3. Conclusion In the literature review the topics of the four research questions were researched. The evaluation-aspects and governance of cloud computing were addressed by exploring the business case, the organizational impact, the (management of) risks and corporate, IT and cloud governance through a semi-structured literature review approach.
4.3.1. Business case The content of the business case for cloud computing or the steps that need to be performed to develop a business case were mentioned in whitepapers. Summarized, the business case should entail the costs, cons, risks and benefits relative to organizational objectives. The business case for cloud computing is therefore not that different than for any other IT investments. The organizational impact is part of the business case. It provides a holistic view on the benefits, costs and risks of cloud computing. Two aspects were not very elaborated. According to Raines and Pizette (2010), the enterprise architecture is important, but they did not explain its role in developing the business case. Also, they argued the cloud model is chosen after the business case is developed. This is particular, as the benefits and risks differ between cloud models. These aspects will therefore be addressed explicitly in the expert interviews.
4.3.2. Organizational impact The risks, benefits, cons or costs also include the organizational impact of cloud computing. On this topic, most research is performed regarding the IT department. The role of IT employees will change, which include a loss in control and authority. Also, the service management processes, for which ITIL is the de facto standard, security management processes and risk management will be impacted. The amount of research found on the impact on other areas in the organization was small. More research, such as detailed case studies, is necessary to identify the overall changes of cloud computing with regards to the impact on processes, organizational structure, culture and the people.
4.3.3. Risks & Risk management The area of security is well addressed in scientific literature. Many papers discuss the vulnerabilities, threats and risks of cloud computing including appropriate risk management responses and controls. Risk management is about the identification and assessment of risks and applying the appropriate risks-reducing controls. Many recommend risks responses were found in literature which can be applied by consuming organizations to reduce the risks of cloud computing. There is no comprehensive (enterprise) risk management framework proposed in scientific literature specific for cloud computing consumers, but existing frameworks can be adapted, such as COSO.
4.3.4. Corporate, IT and Cloud governance IT Governance is still an ambiguous term. Some refer to IT governance as strategic IT related decision making, others to the management of IT or an accountability framework for IT 52
decisions. Another aspect of IT governance, which is referred to as ‘Corporate Governance of It’ by ISO 38500 (ISO/IEC, 2008), are the actions of the board and top management regarding directing the IT function, such as the implementation and monitoring of IT management processes. Also multiple views on cloud governance exists. Some opt for a very operational view of enforcing and monitoring of policies for cloud services and basically apply SOA governance principles to the cloud services. Others refer to reducing security risks as the main aspect of cloud governance. Finally, the most comprehensive view, is to see cloud governance as an extension of IT governance: the structures and processes which are implemented in the organization need to be extended for the management of the cloud services. Because as well IT governance as cloud governance are arbitrary concepts, the definition for cloud governance used in this research is also dependent on the views of the experts, which are addressed in the next chapter.
53
5. Expert views on the relevant cloud evaluation aspects and cloud governance Next to the literature review, cloud computing experts were interviewed on cloud governance and the three aspects relevant for the evaluation of cloud computing, the business case for cloud computing, risk/risk management and organizational impact. Ambiguities and gaps in literature, which were relevant for the development of the framework, were addressed explicitly. These include the role of enterprise architecture in developing a business case, the precise moment of choosing a cloud model and as some view cloud governance to be similar to Service Oriented Architecture (SOA) governance principles, more research was needed to what extend this is appropriate. This section describes the method that was applied to the interviews, the results and their conclusions.
5.1. Method As the goal in this research is to elicit detailed and complete information on specific topics, holding interviews is the most appropriate data collection method next to the literature review. Five semi-structured interviews were held in this phase with six experts from various companies, as shown in Table 14. The ID’s are used to refer to the experts. The experts were selected if they adhered to any of the four criteria:
They had knowledge on the development of a business case for cloud computing. They had knowledge on the organizational impact of cloud computing. They had knowledge on the risks of cloud computing and/or how these should be managed. They had knowledge on the governance of cloud computing.
Expert profession
Two IT strategy consultants
IT strategy consultant
Organization
Consultancy company IT / cloud strategy
Consultancy company IT / cloud strategy
Cloud infrastructure consultant
Consultancy company Expertise area IT / cloud strategy and cloud infrastructure ID Expert 1 Expert 2 Expert 3 Table 14: cloud computing experts and corresponding ID’s.
Cloud manager
risk
Educational cloud project manager
Consultancy company Cloud risk management
Government agency Cloud project management
Expert 4
Expert 5
For the interviews a protocol was used. The complete set of questions are shown in Appendix B. First, the background of this research was explained. Hereafter, five sets of questions were asked to the experts. 54
1. 2. 3.
4. 5.
The experience or work activities of the interviewee regarding cloud computing The content of a business case and the process of building it, including the role of the enterprise architecture and the different service and deployment models. The impact on the organization, including its processes, people, organizational structure, roles and responsibilities and culture. For comprehensiveness, policies were also addressed. The management of cloud related risks. As the risks of cloud computing was profoundly covered in literature, these were not the main focus. Cloud governance: what does it entail? How does SOA (Service Oriented Architecture) governance apply to cloud computing?
Some interviewees were discussing the different subjects by themselves and so there was no need to address them explicitly by asking all the questions. Others were more passive and the questions were used to guide the interviewee covering all the subjects. The interviews were recorded by a mobile phone and transcripted afterwards. For the analysis, a qualitative content analysis method was applied (Zhang & Wildemuth, 2009). For each of the categories ‘business case’, ‘organizational impact’, ‘risks’ and ‘cloud governance’ the main message of each interviewee was extracted, which is shown in Appendix D (interview transcripts are presented in Appendix C). Because of the experience of the interviewees regarding the cloud computing subjects differed, not all were addressed in each interview. Also because of limited time, one risk manager was only asked to address the risk aspect and the content of the business case.
5.2. Results This section presents the results of the expert interviews. Hereafter, the results will be concluded by providing a generalized summary of the findings.
5.2.1. Business case Six of the interviewees addressed the business case aspect of cloud computing, but one of them only addressed the content. Most of the experts commented on the whole process towards building the business case, as this is more differentiating with traditional IT than the business case self [Expert 1, 2 and 4]. The business case is seen as the final step of a whole process, to make the benefits of the cloud solutions explicit compared to traditional IT [Expert 1, 2, and 3]. This starts as a sourcing alternative to a problem (can we do this cheaper?) or cloud computing is taken as a starting point to look at the current strategy (IT push) [Experts 1, 2 and 3]. In both ways, there will be an application or a set of applications for which cloud computing can be a candidate. The candidate applications are based upon an application landscape or enterprise architecture and should fit within the strategy and security policies [Expert 1, 2 and 3]. Some applications cannot be outsourced for example, while others can without a problem. All of the experts commented on the level of standardization of SaaS applications. This should fit the strategic purpose of the application: is a standard application adequate for the business 55
process? Summarized, the business case for cloud computing should be based on the IT strategy of the organization and the service should be closely aligned to the organization’s needs [Expert 1, 2, 3 and 5]. Most of the experts also agreed upon the phase in which the deployment or service model is chosen. According to them, the security policies and the IT strategy principles already scope the number of optional cloud formations in an early stage [Expert 1, 2, 3 and 5]. If an organization wants to outsource one application, a SaaS solution would be a value choice, but IaaS would be something to be considered when an organization wants to outsource its whole infrastructure. Most of the times the security principles also determine whether a private cloud is necessary or a public cloud is sufficient. However, still, multiple business cases can be developed for different cloud formations [Expert 1, 2, 3 and 5]. Further it is important to start the process with a suitability or readiness assessment to ensure the organization is ready to move to the cloud. This identifies possible change management costs (such as new processes and trainings) or it could reveal the organization is not suitable for off-premise cloud computing [Expert 3]. It can be concluded that the most important aspect of the cloud business case is the costs. Three of the interviewees mentioned companies look especially at the financials of the cloud business case [Expert 1 and 4]. For many organizations it is the cheapest option compared to other outsourcing options and traditional IT. Four interviewees argued the organizational impact is very important to take into account [Expert 1, 2, 3 and 5]. That are the adapted processes, migration issues and the education needs for their employees. Two experts argued that these impacts will be quantified to financial terms, as that is the most decisive factor of the cloud business case [Expert 1 and 4]. Besides the quantitative aspect, also qualitative aspects will be taken into account, such as the strategic benefits, security issues and organizational impacts that are not easy to quantify [Expert 1, 2, 3 and 5]. [Expert 5] argued an important aspect of the business case for him is the flexibility of using applications anywhere and anytime.
5.2.2. Organizational impact As mentioned in the previous section, the organizational impact is an important factor to take into account in the business case. Most of these aspects are quantified to financial terms, such as new processes that need to be implemented and the new skills the IT department has to develop. Five experts commented on the organizational impact of cloud computing. For the users the changes are neglectable, as for them, only the functionalities may change [Expert 1 and 2]. Most of the impact is on the IT department according to the experts [Expert 1, 2, 3 and 5]. Depended on the maturity of cloud adoption (i.e. the level of applications replaced with cloud solutions) and the level of infrastructural support needed (i.e. IaaS vs. SaaS), the IT department will be downsized. For example, [Expert 5] explained all the data centers in the various educational institutions will be redundant when the applications will be available as
56
SaaS services from a central educational community cloud. They do not have a solution yet for what to do with the IT employees. The change in the IT department comes together with new service management processes and new roles and responsibilities [Expert 1, 2 and 3]. The process which all the experts mentioned is the management of SLA’s. The appropriate SLA’s have to be defined and negotiated with the suppliers, including security issues, and it has be to monitored whether these are fulfilled. Also one interviewee [Expert 3] addressed the processes which can be seen as security controls (i.e. risk mitigation response) such as what to do when a provider goes out of business. Two experts addressed the adaption of ITIL processes, such as the helpdesk and financial, vendor and SLA management [Expert 1 and 2]. The roles and responsibilities should fit these new processes. Important roles are service manager, including SLA manager, and vendor manager [Expert 1]. In a mature SaaS organization the IT role will shift to advising the business in appropriate SaaS applications [Expert 1 and 3]. For some organizations these changes will be enormous, for others who already have a shared service center and are familiar with SLA’s, this impact will be less. Most of the experts argued cloud computing fits within the existing organizational structure, especially if cloud adoption is in an immature stage [Expert 1, 2 and 3]. No cloud team of excellence is needed at this moment for most companies. [Expert 5] expected though, when the whole IT is centralized, there will be a central cloud board. The opinions on the necessary policies vary between the experts. According to one expert the policies are in most cases already present in the organization [Expert 2]. The cloud solutions have to comply with these policies, such as the Quality of Service (QoS) and security policies, but they do not need to be developed specifically for cloud computing. Exceptions are the policies for reducing risks, such as audits [Expert 2]. For the educational community cloud, the policy makers are evaluating multiple policies regarding amongst others the procurement of IT services by the institutions [Expert 5]. The other experts did not have explicit ideas for necessary policies. Finally, regarding organizational culture, [Expert 2] thinks the service management will be more formal, as a cloud client-provider relationship demands a more professionalized change management and portfolio management. [Expert 3] mentioned cloud computing comes together with a more innovative organizational culture of working everywhere and anywhere (i.e. the new way of working). Organizations with this kind of culture will be more eager to adopt cloud computing.
5.2.3. Risks & Risk management Because the risks, vulnerability and security issues of cloud computing were already extensively covered in literature, the focus was on the management of risks and whether a risk management framework, such as COSO, needed to be implemented. Six experts commented on the risks aspects, but most of them were not very familiar with this subject. 57
[Expert 1 and 3] mentioned that auditing moves towards monitoring certifications. This leads to a problem though, as they may be inaccurate. It is not always clear which security controls were audited for a specific certification. It is therefore important that the security controls of the provider are evaluated [Expert 1 and 3]. No new risk management framework is needed, except some impacts for cloud related risks need to be adjusted, as they are more intensive than for traditional IT [Expert 1 and 3]. [Expert 4] is a risk manager and very familiar with the management of risks of cloud computing. Also according to him, no new risk management framework is needed and internal audit teams need to trust the certification of the suppliers. A cloud specific certification is in development in the industry. The expert explained the process how cloud risks are managed. An external party goes through the risks identified by the CSA and ENISA together with the provider and the customer. After adoption, the clients depend on external certification or logs, such as produced by ClaudAudit (i.e. on-demand compliance logs). Most organizations do not perform the audits at the supplier’s site by themselves, because of the costs and many suppliers are reluctant in allowing them.
5.2.4. Cloud governance [Expert 2] views cloud governance as the decision making structure around the cloud investments and therefore follows the view of Ross and Weill (2004) of IT governance being an accountability framework. However, according to most of the experts, cloud governance is about ensuring the application fits the business needs, risks are mitigated and the SLA and providers are managed [Experts 1, 3 and 5]. [Expert 3] provided the most detailed description of cloud governance. According to him it is about the business case, a readiness assessment, composing, managing and monitoring the SLA’s, evaluating the provider, monitoring whether the service still fits the needs to the organization and ensuring a proper security. [Expert 5] provide a similar, but more abstract opinion. According to him it is about strictly aligning the service to the needs of the organization and institutions, security is ensured and the agreements and policies are complied with. [Expert 1] argued you won’t steer the organization in a different way, but that it is important to manage risks and to assess whether the standard SaaS packages fit within the architecture. So summarized, according to the experts the most important aspect of cloud computing is to align the service with the organization’s needs and managing the risks through establishing and monitoring the SLA’s, although this is not interpreted as ‘cloud governance’ by all experts. SOA tools and governance mechanisms such as repositories or automatic monitoring of SLA’s are not necessary when adopting a cloud solution [Expert 1, 2, 3 and 5]. Cloud computing does fit within a Service Oriented Architecture and it could be governed accordingly, but not the other way around [Expert 2]. Adopting a cloud solution does not mean a Service Oriented Architecture is implemented [Expert 2]. 58
5.3. Conclusion Five interviews were held with six experts as input for the development of the framework in this research. The expertise on the subjects varied between the experts and not all of them commented on all the subjects. The opinions between the experts were not always in conformity. However, based on the most common opinions some general conclusion could be made. Regarding the business case, the most decisive aspect seem to be the costs. For an accurate cost calculation, the impact on the organization should be taken into account, such as training of employees. The content of the business case also contains qualitative aspects, such as the risks and strategic benefits. The business case itself should be build according to the IT strategy and business needs. An enterprise architecture or an application landscape should provide insights into the candidate applications for outsourcing to the cloud. An important aspect is whether the level of standardization fits within the IT strategy of the organization. Further, a readiness assessment is done in practice to evaluate whether an organization is ready to move to the cloud. Multiple business cases can be developed for different cloud formations (i.e. deployment and service model), but in an early stage the security and enterprise architecture principles already scope a smaller set of formations. Cloud computing mostly impacts the IT department. Based on the level of cloud maturity, the amount of applications moved to the cloud, the IT department can be downsized. The ITILkind of processes will also be impacted. Especially SLA management will become important. The new roles and responsibilities should fit these adaptions. There is no need for a new organizational decision making structure at this moment when cloud computing is in its initial stage. When the adopted cloud architecture is more complex this could be different. Most of the experts did not have deep knowledge on the topic of cloud risks and risk management. They were consent though that there is no need for a new risk management framework for cloud computing. Existing methodologies used in the company can be applied to identify risks. One expert was a cloud risks manager and pointed out his company identified risks and risk mitigation strategies together with the provider and the consumer. Further, auditing moves towards evaluating and monitoring certificates and compliance logs. Whether called cloud governance or not, the most important things to deal with when adopting cloud is to ensure a proper strategic alignment, establishing and monitoring SLA’s and ensure risks are managed. At the moment, in an initial stage of cloud adoption there is no need for SOA kind of governance tools.
59
The summary of the generalized conclusions are shown in Table 15. In the next chapter, the information collected through the literature review and the expert interviews is analyzed in order to answer the four research questions. Aspect Generalizable result
Business case
Cost is most decisive factor. Qualitative factors include strategic benefits, security issues and organizational impact. The need for cloud comes as a sourcing alternative or when the trend of cloud is researched. For a specific application a model is chosen and in the business case the solution is compared to traditional IT. The Enterprise Architecture or application landscape should reveal the appropriate applications. They should conform to strategy and security policies. Cloud models are in most cases predetermined. Table 15: summary results expert interviews.
Risks
No new risk management framework is needed Risks should be identified and risks mitigation strategies should be developed together with the provider. Auditing moves towards monitoring certifications (compliance logs).
Organizational impact Most impact on IT department; can be downsized and roles change ITIL kind of processes need to be adapted or implemented No need for new decision making structure
Cloud governance
SOA governance tools not needed Cloud governance should involve strategic alignment, establishing and monitoring SLA’s and ensuring risks are being managed.
60
6.
Synthesis between literature and expert views
This chapter deals with the analysis of the gathered information out of the literature review and expert interviews. Each of the research questions will be answered, based on the conclusions which have been made regarding the corresponding aspects in literature and the interviews.
6.1. Business case In the literature section the content of the cloud business case was addressed. Also, cost calculation methods and the benefits of cloud solutions were researched. The expert interviews mostly addressed the process of building a business case and its content. Combined, the first research question can be answered. RQ1: How can a business case be developed for cloud computing? From literature it can be concluded the business case includes the hard and soft benefits, the risks, cons and the organizational impact. The views of the experts correspond to this. The interviews also addressed the preceding steps which are performed before the business case is built, as the business case for cloud computing is not that different than for other IT investments [Expert 1 and 2]. First a readiness assessment should determine whether the organization can adopt an offpremise cloud solution, which include evaluating the organizations culture, IT processes and capabilities [Expert 5]. Online questionnaires could be used for this assessment, such as that of EMC (“EMC Readiness”, n.d.). Hereafter, the service should be defined. The service should comply with security policies (can the data and the process go into the cloud?) and it should fit in the strategy and architecture. An example is the standardized nature of SaaS applications. Strategic processes which need custom applications are therefore not suitable to be supported by SaaS applications [Expert 1, 2, 3 and 5]. Although not addressed by the experts, it is also important to take into account the network performance of the organization (Carroll et al., 2011). Some critical applications may need a better performance than the organization’s network allows. After the service is defined, the model is chosen. These are in most cases predetermined by the strategic intent (infrastructure outsourcing vs. applications) and security policies (private vs. public) [Expert 1, 2, 3 and 5]. Still multiple business cases can be developed to compare the cloud models [Expert 1, 2, 3 and 5]. Based on the business case, an organization decides to adopt a cloud solution instead of using traditional IT or other forms of outsourcing [Expert 1, 2, 3 and 5]. Also in literature, the benefits of cloud computing and cost calculation methods were addressed. The benefits of cloud computing can be grouped into cost reduction, strategic and technical benefits. While costs seem to be in practice the most important benefit, flexibility is at least for [Expert 5] an important benefit. For calculating costs, the Total Quality of Ownership approach should be applied and to assess quantified benefits, a NPV or ROI metric
61
may be used. It is important when identifying costs to take into account the migration, training and configuration costs [Experts 1]. The above findings are shown in Table 16. Aspect Business case content
Business case development process
Literature view Soft benefits, hard benefits (cost savings), risks, cons and organizational impact. The benefits must be based on business goals or objectives. Only ISACA’ (2011) input covered the development of the business case: goal setting, identifying benefits, costs, and risks, developing the business case.
Experts view Costs is most decisive factor, but also included are (strategic) benefits, risks and organizational impact.
Covered a broader scope. It starts with a readiness assessment, then defining the service (which should comply with EA and security policies), and then the model is determined. As a final step a business case is developed in which the cloud solution is compared to traditional IT. Not addressed, but important to take into account are migration, training and configuration costs. Not addressed explicitly, but costs is most important benefit. Flexibility is also a reason to adopt cloud.
Network performance of the organization should be adequate for the service. Costs calculation method TCO approach must be applied to cover all possible costs, such as migration costs and support staff. Benefits Strategic, cost reductions and technical benefits. For assessing the quantified value, a ROI or NPV metric may be used. Table 16: summary synthesis for cloud computing business case.
Synthesis Business case includes soft and hard benefits, cons, risks and organizational impact. The benefits should be based on business goals and drivers. It starts with a readiness assessment, then defining the service (which should comply with EA, network performance and security policies), and then the model is determined. As a final step a business case is developed: the benefits, risks, organizational impact and costs are determined. TCO approach must be applied to cover all possible costs, such as migration, configuration and training costs. Strategic, cost reductions and technical benefits. For assessing the quantified value, a ROI or NPV metric may be used.
6.2. Organizational impact Literature was researched regarding the changes on people, structure, processes and culture. The same aspects were covered by the expert interviews, but policies were also included for comprehensiveness. The second research question can be answered. RQ2: What is the impact of cloud computing on an organization? Most of the literature regarding the organizational impact of cloud computing was about the IT department. Less IT employees are needed as infrastructure moves out of the organization and their roles change to managing services and contracts. As business can bypass IT when procuring services, their authority may be reduced. Not much research was done on changes outside of the IT organization, but cloud computing provides new opportunities for all employees, the accounting department must get used to renting services instead of buying ones and existing non-IT business processes may be impacted.
62
Cloud adoption frameworks provided some insights into the processes which need to be implemented. These fit in the scope of the ITIL framework (service management), such as continuous service improvement, incident management and provider management. Jansen (2010) concluded all the processes of the ITIL framework can be used for delivering cloud solutions, but they need to be adapted. Also, Mather et al. (2009) presented the security management processes which need to be implemented for cloud solutions and, as covered in the risk-section, a risk management process is important for reducing risks. The views of the experts correspond to the findings in literature that the biggest impact is on the IT department. Less IT employees may be needed, they gain new roles of managing services and providers and ITIL-like processes must be implemented, such as SLA, financial and provider management [Expert 1, 2, 3 and 5]. Further, according to the experts, no changes need to be made regarding the decision making framework [Expert 1, 2 and 3]. [Expert 5] mentioned though, that a central cloud board may be needed when the whole infrastructure is centralized. While some information was found in literature on the impact of cloud computing out-side the IT department, the experts did not have a strong opinion on this subject. [Expert 3] mentioned the functionalities may be different for end-consumers when SaaS is adopted, as it is often a standard product. Further, existing systems may be impacted because of integration requirements [Experts 1]. The culture within the organization does not seem to be impacted by cloud computing, but cloud computing comes together with a culture of ‘work anywhere and everywhere’ [Expert 3] and it may lead to a more formal provider management [Expert 2]. It can be concluded the actual impact of cloud computing on the culture is neglectable. The same applies to the policies, which were addressed by the expert interviews. In normal public clouds, these seem to be restricted to security related ones, such as for privacy (data movement) and audits [Expert 3]. In a large educational community cloud, policies for procuring services will become critical [Expert 5]. The summary of this analysis is shown in Table 17. Aspect People IT department
People Out-side IT department
Structure
Processes
Literature view Less IT employees needed. New roles and responsibilities. Possible reduction of authority, as business can bypass IT. New possibilities for doing work and accounting department must get used to rent IT services. New roles and responsibilities.
Service & security management processes. Risk management process. Existing non-IT
Experts view Most impact. Less are needed and new roles and responsibilities; towards managing contracts and providers. Not much differences: cloud is a technical issue.
New roles and responsibilities. No new decision making structure, except when everything is centralized. ITIL-like processes must be implemented. Non-IT processes may be impacted because of
Synthesis Less IT employees needed. New roles and responsibilities. Possible reduction of authority, as business can bypass IT. New possibilities for doing work and accounting department must get used to rent IT services. New roles and responsibilities. No new decision making structure. Service & security management processes. Risk management process. Existing non-IT
63
processes may be impacted. -
standardized nature of SaaS. Culture Cloud comes with ‘work everywhere and anywhere’ and it may lead to a more formal provider management. Policies Not addressed. Are already in place; no new policies for cloud, except for security issues. In an educational community cloud policies are important. Other Systems may be impacted, because of standardized nature of SaaS. Table 17: summary synthesis organizational impact of cloud computing.
processes may be impacted. Insignificant.
Neglectable.
Systems may be impacted, because of standardized nature of SaaS.
6.3. Risks & Risk management Many literature was found on the risks of cloud computing and some on the management of them. Only one expert was really knowledgeable on this topic, but two others also provided input. The third research question will be answered. RQ3: What are the risks of moving to the cloud and how can they be managed? The risks aspect of cloud computing is extensively covered in scientific literature. Offpremise cloud computing brings additional security risks compared to traditional IT and public cloud computing is more risky than a private cloud (off- and on-premise). The risks can be grouped into the following categories: Confidentiality & Privacy, Data control, Availability of data and services, Data integrity, Data encryption, Logical access, Network security, Physical access and Compliance. Another, less technical, grouping is done by ENSIA (2009). According to them, cloud computing risks can be grouped into Organizational, Technical and Legal risks. Risk management is the process of identifying these risks and developing appropriate strategies to mitigate them. This is based on the assets in the cloud (processes and data) and the cloud model (delivery and deployment). For cloud computing an important part is to evaluate the provider and SLA according to risk-reducing requirements, such as data location and a third-party audit clausal. Further, internal security controls must be implemented, availability risk strategies must be established (e.g. exit-strategy) and certain aspects must be monitored, such as compliance logs of the provider. Further, an organization must establish a data classification scheme to identify appropriate applications to put in the cloud. [Expert 5] commented on the process of managing risks. The cloud provider and consumer both assess the risks of cloud computing and come up with risk management strategies. When the solution is operational, compliance logs are monitored. [Expert 1 and 3] also mentioned that auditing moves towards monitoring logs and certifications. This corresponds to the findings in literature and fits within the high level risk-reducing control ‘monitoring’. The summary of the analysis is shown in Table 18. 64
Aspect Risks
Risk management
Literature view Off-premise cloud computing brings additional risks. They can be grouped in Organizational, Technical and Legal risks. The process of identifying cloud risks and risks reducing controls. The risks are based on the assets in the cloud and the cloud model.
Risk reducing controls
Experts view Not addressed
Provider and consumer both assess risks and risks mitigation strategies.
Can be grouped into high Auditing moves towards level activities of setting monitoring logs and SLA and provider certifications. requirements, evaluating the SLA and provider, internal security, monitoring and a data classification scheme. Table 18: summary synthesis risks and risks management of cloud computing.
Synthesis Off-premise cloud computing brings additional risks. They can be grouped in Organizational, Technical and Legal risks. The process of identifying cloud risks and risks reducing controls, preferable performed together by provider and consumer. The risks are based on the assets in the cloud and the cloud model. Can be grouped into high level activities of setting SLA and provider requirements, evaluating the SLA and provider, internal security, monitoring and a data classification scheme.
6.4. Cloud governance While the previous elements were relevant in assisting managers evaluating cloud computing, a second aspect of this research is cloud governance. To define this concept, both literature and expert views were taken into account. This leads to the answering of the fourth research question. IV. How does governance apply to cloud computing? 4.1. What is governance? 4.2. Which perspectives on cloud governance can be identified? 4.3. Which view(s) on cloud governance is (are) the most relevant and therefore the most appropriate perspective(s) for the framework developed in this research? 4.4. What does the relevant perspective(s) on cloud governance entail? In literature, the concept of governance was addressed and researched. Governance means ‘to steer’. On a corporate level governance entail mechanisms which ensure management acts on behalf of the owners and include the board of directors and management incentives. IT governance is a more ambiguous term. The level of this ‘steering’ differs between perspectives. A common used definition describes IT governance as leadership, processes and structures. But the interpretation of these processes differ between authors. Some include only strategic decision making processes, others all processes to manage and control IT. Further, IT governance can be explained as an accountability framework and a process performed by directors, which implement and monitor these processes and structures. The latter view is 65
referred to as ‘Corporate Governance of IT’ by ISO/IEC 38500 (ISO/IEC, 2008) instead of ‘IT governance’. Cloud governance is also a concept which is viewed in multiple ways. One view is of it being similar to Service Oriented Architecture (SOA) governance. Another perspective is cloud governance being all about securing information and business processes. Lastly, it is seen as the processes and structures to manage cloud solutions. The experts were consent on that security is one of the most important aspect of cloud adoption and that SOA governance mechanisms (such as repositories) are overkill [Experts 1, 2, 3, and 5]. The view of cloud governance being an extension of IT Governance (processes and structures) is relevant for this research, as the goal is to approach the governance of cloud solutions in a broader way than solely security. Therefore in this research cloud governance is seen as the processes and structures which need to be implemented and the risk-reducing controls which should be applied to reduce risks. This leads to the following definition: “Cloud governance is the framework of processes, structures and risk-reducing controls for maximizing the cloud solutions’ value and minimizing its risks.” The input for cloud governance overlaps with that of the previous research questions. The risk-reducing controls were already identified, so were the processes and structures. In the organizational impact section it was concluded service, security and risks management processes must be implemented and no new decision making structure is needed. This definition refers to cloud governance as being a framework or system and not to the process of governing (Evaluate, Monitor & Direct), as Figure 18 (section 4.2.4) visualizes. Some literature findings and expert comments provided a process-oriented view of cloud governance. These actions fit within the ‘Evaluate’, ‘Direct’ and ‘Monitor’ activities and are shown in Table 19.
Evaluate: before governors direct the organization they evaluate stakeholder needs and the use of IT in the organization (ISO/IEC, 2008). As cloud processes aren’t implemented for no cause, it is therefore assumed top management first evaluates whether cloud computing is of value to the organization. [Expert 1, 3 and 5] commented on the governance activity of ensuring cloud solutions are aligned to business needs, including the readiness assessment and evaluating the business case [Expert 1]. Speed (2011) also argued developing and evaluating the business case is a top management governance activity. Direct: the direct phase entails providing management direction and implementing governance mechanisms through policies and plans (ISO/IEC, 2008). [Experts 1, 3 and 5] argued ensuring risks are managed is an important governance activity. Further, other cloud governance mechanisms are the processes which need to be implemented and an adoption project must be started to actually adopt cloud solutions and manage the risks. Monitor: the monitor activity of IT governance ensures the governance mechanisms are effective and performance corresponds to the plans (ISO/IEC, 2008). For cloud computing, top management governance activities are to monitor KPI’s, the SLA
66
(Chang et al., 2012; Shimba, 2011) and to ensure the business requirements are still fulfilled (Conway & Curry, 2012) [Expert 3].
Corporate Governance of IT Evaluate
Direct
Monitor
Description Before governors direct the organization they evaluate stakeholder needs and the use of IT in the organization (ISO/IEC, 2008)
The direct phase entails providing management direction and implementing governance mechanisms through policies and plans (ISO/IEC, 2008). The monitor activity of IT governance ensures the governance mechanisms are effective and performance corresponds to the plans (ISO/IEC, 2008).
Cloud governance activity
Readiness assessment [Expert 1] Organizational needs (business case, architecture) [Expert 1, 2 and 3] (Speed, 2011)
Ensure risks are managed and security is ensured [Expert 1, 3 and 5].
Description Cloud is evaluated according to organizational needs. This include a readiness assessment and the development and evaluation of a business case. Implement cloud governance (manage risks and implement processes) and adopt cloud.
Monitor the value and Monitor SLA performance of the [Expert 1] (Chang cloud solution. et al, 2012). Monitor whether solution fulfills business needs [Expert 1]. Monitor KPI’s (Chang et al., 2012); (Shimba, 2011). Table 19: literature and expert findings on ‘Corporate Governance of IT’ for cloud computing.
How cloud governance, as defined in this research, fits in IT governance and Corporate Governance of IT is shown in Figure 20. Cloud governance is seen as a subset of IT Governance (processes and structures). Both IT and cloud governance are ‘governed’ by directors through ‘Monitor’, ‘Evaluate’ and ‘Direct’ activities, as outlined by ISACA (2012) and ISO 38500 (ISO/IEC, 2008).
67
Corperate Governance of IT Directors (Board & Top management) Oversight of IT Evaluate: Evaluate cloud computing (Readiness & business case) Direct: Implement cloud governance (Processes and risk-reducing controls)
Monitor: Monitor value of cloud (SLA, KPI s, business requirements)
IT Governance Committees, Executives & Management Processes & Structures to manage IT Cloud governance Processes & Structures Risk-reducing controls Figure 20: the relation of cloud governance to other types of IT related governance.
The summary of the analysis regarding cloud governance is shown in Table 20. Aspect Cloud governance
Literature view Cloud governance: Security Processes and structures SOA governance Corporate governance of IT directs IT Governance.
Experts view Cloud governance Decision making framework Strategic alignment and risks reduction SOA governance mechanisms not needed Security most important aspect of cloud adoption. Some comments fit in the process of governing, including evaluating the business case and monitoring business requirements.
Synthesis Cloud governance is security (controls) + IT governance view (processes and structures) Cloud governance consist of service, security and risks management processes and the risk reducing controls which were identified in literature. Evaluate, Direct and Monitor activities govern cloud governance.
Table 20: summary synthesis cloud governance.
68
6.5. Conclusion In this chapter the four research questions were answered by synthesizing the findings in literature and the views of the experts. With regards to most aspects, the two views did not contradict, but were complementary. For the cloud business case, the literature review addressed the content of the business case, cost calculation methods and the benefits, whereas the interviews mostly conveyed the activities towards building the business case. General conclusions have been made on the content of the business case, calculating costs, the benefits and the process of building the business case. Both literature and the experts correspond on the finding that the biggest impact of cloud computing is on the IT department. The roles of IT employees shift towards managing contracts and providers, ITIL-like processes must be implemented which correspond to these roles, and as IT infrastructure is outsourced, less employees are needed. General conclusions have been made regarding the impact on processes, people, organizational structure, culture and policies. An interesting finding is that no new decision making structure is needed. The literature review addressed cloud security, privacy and compliance risks and the controls to manage them. The experts were not very knowledgeable on this topic, but their comments did not contradict literature: auditing moves towards monitoring certificates and compliance logs. General conclusions have been made regarding the risks, risk management (the process) and the controls to mitigate risks. Based on the perspectives identified in literature on cloud governance and the views of experts, ‘cloud governance’ was defined. One notable finding of the expert interviews was that SOA (Service Oriented Architecture) governance is not very relevant to cloud computing. Cloud governance as a framework consist out of security, service and risk management processes and the controls to mitigate risks. A different ‘layer’ of governance are the activities of top management directing the IT and cloud governance framework, through evaluation (adopt cloud?), directing (implement cloud governance) and monitoring (cloud solution successful?) activities. Based on the findings in this chapter, an initial cloud evaluation and governance framework is developed. The development of this framework is discussed in the next chapter.
69
7.
Development of the initial framework: version 1.0
Based on the synthesis between the findings in literature and expert interviews a framework was developed. Its aim is to assist higher management with the evaluation and governance of cloud computing. In this version of the artefact, the two research aspects of assisting higher management with the evaluation of cloud computing and providing them an overview on cloud governance, is combined in one framework, consisting out of a model and a corresponding table. This will be elaborated in the next section. Hereafter, the requirements and the development of the framework is discussed and finally the model and table are presented.
7.1. One integrated framework The two research aspects of cloud governance and cloud evaluation overlap. Based on the conclusions made in section 6.4, top management implement processes and manage risks through evaluating, directing and monitoring activities. In the first governance activity, they evaluate cloud computing. For this activity, the other research aspect comes into play. By providing assistance on the business case, organizational impact and risks, this top management activity can be supported. This is visualized by Figure 21. How these two research aspects are integrated into one framework, is discussed in the next section.
Cloud Governance aspect
Evaluation aspect
Top management Evaluate cloud activities: evaluate, computing direct & monitor
Evaluate & direct
Supported by
Information on the business case, organizational impact & risks
Monitor
Cloud governance: Risk-reducing controls & processes
Figure 21: the top management activity ‘Evaluate’ for governing cloud governance, is supported by the evaluation aspects.
70
7.2. Framework requirements The goal of the artifact is to assist higher management with the evaluation of cloud computing, by providing information on the business case, organizational impact and risks aspect of cloud computing and to provide insights into governance for cloud computing. To provide the context for cloud governance and to provide assistance to actually implement it, the corresponding top management activities need to be shown, which were discussed in section 6.4. This leads to the following requirements:
Integrate and provide information on the business case, organizational impact and risks aspects of cloud computing. It should provide insights into the necessary processes and risk-reducing controls through a high-level overview. To provide a context for cloud governance, top management / governance activities (Monitor, Evaluate and Direct) must be depicted.
The governance element of the framework is considered to be the most suitable for modeling; that is abstracting reality, to provide higher management an understandable, birds-eye view on something complex as cloud governance. The evaluation aspects (business case, organizational impact and risks) are considered to be more of information sources, which can be presented as plain text. The elements of the governance model, must be elaborated though. To prevent information-overload, a one-sheet table should do the trick in elaborating the governance elements and presenting information on the business case, organizational impact and risks. The management of risk are part of cloud governance, which can also be taken into account when evaluating the cloud solutions.
The high-level model should be complemented with a one-sheet table containing information about the governance elements of the model and, to assist the evaluation of cloud computing, on the organizational impact, business case and risks.
Literature pointed out that a private, on-premise cloud is often perceived by scholars as very similar to traditional IT. Many security controls do not apply to this model. Therefore, a governance framework like COBIT (ISACA, 2011) has scoped cloud computing by off-premise solutions. In this research the same scoping is applied, which leads to the following requirement:
The framework and model will focus on off-premise cloud computing and will therefore not take into account the differences in risks for on-premise cloud computing.
The goal of the framework is to foster cloud adoption; that is organizations starting a cloud initiative. The framework is therefore also scoped by a single cloud solution; enterprise-wide governance (multiple cloud computing initiatives) is not taken into account.
The framework will focus on one cloud initiative cloud computing and will therefore not take into account enterprise-wide governance.
71
Finally, a whole new framework is developed, as existing ones are not considered adequate to serves as a foundation or basis. The analysis of the existing frameworks, as discussed in section 3.4 (background chapter), can be found in Appendix L.
A whole new cloud governance and evaluation framework needs to be developed, as existing cloud evaluation and cloud governance frameworks are not considered to be an adequate basis.
How the elements of the framework relate to each other is shown in Figure 22. Research aspect
Artefact Table Providing information on the business case, organizational impact and risks
Evaluation Assist higher management with the evaluation of cloud
Cloud governance Provide higher management insights into governance for cloud computing
Cloud governance model Governance / top management activities implementing cloud governance
Elaborating cloud governance model elements
Figure 22: how the elements of the framework relate to each other.
7.3. Cloud governance model high-level design As was mentioned in the previous section, the ‘cloud governance’ aspect is modelled in a graphical overview. This section deals with the high-level overall design. Cloud governance in this research is seen as the processes which need to be implemented for managing cloud solutions and the risk-reducing controls which need to be applied (Section 6.4). Another layer of governance was also identified, which deals with the implementation of cloud governance. These top management activities of ‘Evaluate’, ‘Monitor’ and ‘Direct’ will be the focus of the model as they provide the context for implementing the processes and managing risks. The four top management activities are shown, as visualized by Figure 23.
72
Evaluate cloud computing
Monitor value / value assurance
Implement processes
Manage risks & adopt cloud
Figure 23: depicting the top management / governance activities. These top management activities are responsible for cloud governance: processes and riskreducing controls. The processes are implemented in the second activity and the management of risks are done through the third activity as oversight on the cloud project. To show how the risks are managed, the identified risk-reducing controls are shown in the middle. The controls have a red background, just like the third activity which is responsible for these controls. The adoption project is shown to clarify when the risk-reducing controls should be applied. The high-level design is shown in Figure 24.
73
Evaluate
Direct
Monitor
Figure 24: high-level design of the cloud governance model.
7.4. Cloud governance model detailed design The previous section presented the high-level design of the cloud governance model. The detailed content of these elements are based on the general conclusions which were made in chapter 6. The top management activities consist out of several sub-activities. When evaluating a cloud solution, a readiness assessment must be performed and the business case is developed and evaluated. When cloud solutions are considered to be valuable to the organization, the necessary service, security and risks management processes are implemented. Hereafter, a cloud adoption project must be implemented and cloud risks need to be managed. The management of risks consist out of four high level groupings of controls which each correspond to a certain phase of the cloud adoption project. Appendix A shows to which phase of the adoption project the controls apply. The phases are based on the ones identified by Conway and Curry (2012), who developed a cloud adoption framework (see section 3.4). Some 74
phases are adapted for a better fit to the controls or because of space issues of the model. In the ‘Planning’ phase, service and provider requirements (e.g. data center location, performance metrics, necessary security controls) are identified. Hereafter, when ‘Engaging’ with a provider, the service and provider are evaluated according to the requirements (e.g. data location) or the SLA is negotiated. When the organization ‘Implements’ the cloud solution, internal security should be addressed. This includes amongst others network security. Availability-risk reducing strategies need to be developed, some in conjunction with the provider. Controls which are part of this category are amongst others an exit strategy and a plan to deal with provider outages. These activities are performed when engaging with the provider, as some security management processes (e.g. incident management) and risk management strategies (e.g. strategy for outages) should be developed together with the provider (CSA, 2011). Finally, when the service is ‘Adopted’ or operational, several aspects must be monitored, including the SLA, compliance requirements and data movement. Further, a data classification must be implemented to ensure no privacy sensitive data is put in the cloud and to monitor data movement. This should be implemented before the adoption project is started, as the selection of the cloud candidate applications depends on this control. These high level groupings of controls are shown in the model. In the middle, the sub-controls of ‘Monitoring’ are depicted. These processes and risk-reducing controls together form ‘cloud governance’. When the service is adopted, a top management activity is to ensure the value of the solution is achieved. This includes monitoring whether the service still fulfills business requirements, whether the SLA is complied with and Key Performance Indicators (KPI’s), such as costs. Table 21 shows how the information described above is visualized in the model and the references to the corresponding sections in the thesis. The detailed design of the model is shown in Figure 25.
75
Model aspect Top management governance activities
Description /
Thesis section 6.4.
Responsible for cloud governance. Evaluate: evaluate cloud computing. Direct: implement processes. Direct: manage risks and adopt cloud solution. Monitor: monitor value of cloud governance and solution. Cloud Governance: Processes: service management, 6.2;6.3;6.4; processes and risk- risks management and security reducing controls management Risk-reducing controls: 6.3;6.4;7.3 Planning phase: determine SLA and vendor requirements. Engage phase: evaluate provider and SLA and negotiate SLA. Implement phase: implement internal security controls and develop availability plans. Adopted: when service is operational several aspects must be monitored. Table 21: elements of the model and references to thesis chapters.
Visualization in the model Four colored areas.
Part of ‘Implement processes and roles and responsibilities’ area (green) Part of ‘Adopt and manage risk’ area (red). The security controls (red controls in the middle) The adoption project is shown to make clear when the controls need to be applied.
76
Adopted Monitoring
Cloud governance
MonitorCloud value metrics MonitorGovernance service requirements
Figure 25: the cloud governance model.
The risk controls and processes are cloud governance, which need to be implemented through the governance/top management activities. The four colors represent four kind of governance activities. Top managers evaluate cloud computing, direct the organization through implementing processes and ensuring risk-reducing controls are applied during the adoption project and after adoption, the value of the cloud services must be monitored. The central adoption activities (plan, engage, implement and adopted) are not part of the governance, but are displayed to show when the risk-reducing controls should be applied. The next section present the corresponding table which is provided together with the model. It elaborates the elements of the model and it provides the information for the evaluation of cloud computing.
77
7.5. Corresponding table & cloud evaluation aspects A one-sheet table accompanies the graphical model to provide an explanation and elaboration on the elements. This table also includes the information for the evaluation of cloud computing (business case, organizational impact and risks). Table 21 lists the elements of the table and the corresponding sections/chapters in the thesis, while Table 22 shows the actual table as part of the framework. The elements are not elaborated in this section, to prevent redundancy. Elements
Description
Evaluate activity
The element which correspond to the ‘cloud evaluation’ governance activity Readiness assessment information. Business case information. Information for building and evaluating the business case The main organizational impact is mentioned to help build the business case. The categories of risks are listed. The categories of benefits are listed. The governance activity concerned with implementing the necessary processes. The governance activity concerned with assuring risks are managed. The risk controls are shown and mapped to adoption-phases. The governance activity concerned with monitoring the cloud’s value.
Readiness
Business case Additional information
Process of building business case
Organizational impact
Risks Benefits Implement processes activity
Manage risk activity
Risk responses
Value assurance (monitoring)
Thesis Section 6.4
6.1
6.1 6.1
6.2
6.3 6.1 6.4
6.4
6.3; 6.4; 7.3
6.4
Table 21: elements of the table and corresponding section/chapter thesis.
78
Governance aspect Evaluate Readiness Business case
Description of elements
Assess whether the processes, technology and capabilities are appropriate for cloud computing and the organizational alignment (i.e. implementing necessary processes) is feasible. For a specific scope of services (e.g. e-mail) a business case is built and evaluated and contains the risks, costs, benefits and cons of the cloud service. The impact on the total organization should be assessed for a holistic view. Cloud evaluation information Define scope of services (e.g. e-mail). The service scope is based on security policies & data classifications The process of (e.g. which data is allowed in the cloud?), organization’s network capabilities (which applications can deal building and with this performance?) and the organizations strategy, enterprise architecture and cloud vision (where are we evaluating the heading?). business case
Organizational impact Benefits Risks Processes Risk management Service management Security management
Define the cloud model for the service. The delivery model (e.g. SaaS) and deployment model (e.g. public) are in most cases predetermined by security policies (private is more save) or the IT strategy (infrastructure vs. app.), but multiply business cases can be developed and evaluated for comparing multiple models. Assess organizational impact, benefits, cons, costs and risks. The benefits should be based on organizational goals or drivers. A TCO approach can be used for assessing the costs, for which tools can be used. Built and evaluate the business case. The main impact of adopting a cloud solution is on the IT department. As infrastructure moves out of the organization, less IT employees are necessary and their roles will change. Also, processes need to be implemented, risks need to be managed and data needs to be migrated. Further, existing applications and processes may be impacted. The benefits of cloud computing relate to cost reduction and strategic and technical/security advantages. Because the services are delivered over the internet and data is stored on data centers on provider’s site, multiple risks occur. Examples are data loss because of hijacking attacks, unavailability because of network limitations and cloud-provider lock-in. Private clouds are less risky than public ones.
Ensure a risk management process is established, which identifies the risks when building a business case and provides the proper risk responses for the secure adoption of a cloud service. Ensure required ITIL-like service management processes are in place, such as Service Level, Supplier and Incident management. Some need to be established together with the provider. These processes come together with new roles and responsibilities. IT employees need to be educated and when hiring staff, this should be taken into account. The processes which need to be implemented for security reasons as internal controls when managing risks. Some service level processes may be referred to as security management, such as incident and access management Other security processes are amongst other key & data management. IaaS and PaaS require additional security processes compared to SaaS solutions, such as patch management.
Manage risks Set up adoption project & Apply risks controls
A cloud-adoption project should be established. Ensure the appropriate risk-reducing controls are applied during the adoption of the service (s) to manage the risks. The high level risk responses are shown below; the risk management process needs to determine the exact responses or risk-reducing controls. Description Cloud Description Risk responses Requirements of service and vendor
Vendor & SLA evaluation and negotiation Internal security & availability plans
Monitoring
Benchmark current applications for performance requirements Set up service requirements and metrics (e.g. response-time, QoS etc.) for the SLA Identify risk mitigation elements for the SLA, such as third party audit clauses. Identify relevant compliance requirements and the necessary security controls. The cloud providers needs to be evaluated, including its security controls according to compliance requirements. The cloud provider’s SLA need to be evaluated for the requirements or it should be negotiated. The internal security controls should be implemented, including network and application security, cryptography, key management and data management policies and proper security management processes (e.g. access control & incident management). Plan for mitigating availability risks, including fail-over strategy (i.e. cloud service fails), exit strategy (prevent CSP lock-in), mitigation strategies for VM’s (IaaS) and disaster recovery plans. The following needs to be monitored: The SLA metrics, such as performance The security controls and compliance of the CSP through compliance logs The internal controls, such as network security. Data movement in the cloud; sensitive data should not be put in public clouds and data needs to be encrypted.
adoption phase Architect
Planning of the process and requirements for the service are established.
Engage
Selection of provider.
Implement
The cloud service is implemented.
Adopted
Cloud service is operating and renewed.
79
Data classifications
Events that could lead to new cloud-related risks, including change in compliance requirements. Data classifications should be in place. For example, data is classified as privacy sensitive and privacy nonsensitive. Data classifications are not only require red for the monitoring of data in the cloud, but also when defining the cloud service (see business case).
Value assurance To assure the cloud service provides the required value, several aspects need to be monitored and evaluated. Key performance indicators, such as the ROI. Service requirements, whether the service still fits the business needs SLA, whether the service delivers the promised performance. Table 22: the additional table elaborating the model’s elements and includes the evaluation aspects.
80
8.
Expert feedback on the initial framework
The cloud evaluation and governance framework, as presented in the previous chapter, was evaluated by as well possible users, C-suite managers, as cloud computing experts. The possible users were interviewed to assess the usability and usefulness of the model, but they could also provide expert feedback on the presumed top management activities of the model. Because the cloud computing experts worked closely to C-level executives, they could also provide some insights into the usability of the model. This feedback round addressed four aspects:
Is it understandable? It is clear how to use and apply the model? Is it useful and is the information valuable? Does it contain the correct cloud governance/top management activities? Experts, is the model accurate? Is the provided information correct?
8.1. Approach Six interviews were held with six potential users (top managers) or cloud computing experts, as shown in Table 23. They were selected if they adhered to any of the two requirements:
The interviewee is a C-suite manager or works closely with C-suite managers. The interviewee is an expert on cloud computing.
Expert profession
CIO
CFO
CSO
CTO (also cloud expert)
Strategic IT advisor
Organization
University
Bank
University
Main role
Potential user
Potential user
Potential user
Software company Potential user / expert
Own company Potential user
User 4
User 5
ID User 1 User 2 User 3 Table 23: overview of the respondents in the feedback phase.
Security project manager (cloud expert) Insurance company Cloud Expert (but feedback was taken into account) Expert 6
The interviews were recorded by a mobile phone and transcripted afterwards. For the analysis, a qualitative content analysis method was applied (Zhang & Wildemuth, 2009). For each of the categories ‘understandability’, ‘usefulness, ‘correctness of governance activities’ and ‘information accuracy’ the main message of each interviewee was extracted. The results of the content analysis are shown in appendix G, while the interview transcripts are shown in appendix F.
8.2. Results The results of the validation interviews are discussed for each of the categories.
81
8.2.1. Understandability All of the interviewees, except one [User 3], did not perceive the model as easy to understand. The adoption project activities, which are displayed together with the risk-reducing controls, were thought to be the main element of the model by almost all interviewees [User 1, 2, 4 and 5; Expert 6]. Also, the lack of clear phases was considered to be a downside of the model [User 1 and 4; Expert 6]. [User 5] needed more time to take a look at the model. This was also considered as a cue that the model is not easy to understand. [User 3] had a different opinion though and thought the model was very clear. [User 1] mentioned the used terms were very confusing and would even be more difficult to understand by non-IT top managers which do not have an extensive knowledge on IT, such as ‘CSP’, which stands for cloud service provider. So the model would probably be better understandable by IT experts, than by business managers. Further, the table was according to the cloud expert too detailed and leads to informationoverload [Expert 6].
8.2.2. Usefulness Because most of the interviewees did not understand the model properly, they did not go into depth on its usefulness. However, [User 1 and 4] mentioned the topic of this research, governance and security of cloud computing, was very interesting. [User 1] said: “If you would make a better model which is usable by the board and put it on a website, I do not doubt that many would download it.” The other interviewees did not really commented on the usefulness aspect. [User 3] pointed out that nothing was missing, which could be seen as a cue that the model is useful, and one interviewee mentioned that the model is too broad [User 4]. The other ones pointed out that top management will not use this model [User 1] and that management already knows how to handle cloud adoption [User 2]. All the interviewees reflected solely on the model, not on the information provided in the table for the evaluation of cloud computing. When asked explicitly to one interviewee [Expert 6], he pointed out this is because there is too much information in the table.
8.2.3. Governance activities The governance or top management activities which were assumed to be responsible for cloud governance led to confusion by the interviewees. As was pointed out in literature, multiple perspectives can be distinguished on IT and cloud governance. This was also notable in this feedback phase. [User 3] pointed out these activities are correct. Top management and the board should evaluate cloud, direct management and monitor its value. But the risks controls are more relevant to middle management. [User 4] also agreed the activities were governance, but he had a very broad perspective of governance. When asked whether top management should be involved in these activities, he explained that it should be the case, but in practice it is not often done. The main aspect top 82
management should be involved in is the alignment of the cloud solutions to the business goals. They, and the board of directors, are mostly interested in the ‘Value assurance’ aspect of the model. [User 2] perceived the model as a management/adoption model. According to him, governance is about accountability, which is similar to the view of Ross and Weill (2004) (see section 4.4) on IT governance. According to this interviewee, management is about executing processes, governance on about who makes the decision within these processes and who is accountable. He perceived the activities as part of project management in combination with management oversight. However, he could understand the model is called ‘a cloud governance model’, as micro governance is included for the cloud management processes. These processes are too low level though, to be part of the corporate governance framework set out by the governing body. [User 1] thought the model is better usable for the IT manager. Governance is considered to be the framework how things run in an organization, according to this interviewee. But as this model is aimed at top management, he disagreed whether these are the correct governance activities. The board and executive management does not really bother with cloud solutions, as they are not disruptive technologies in his opinion. The model does fit within the level of IT Governance: setting up the IT organization. [User 5] and [Expert 6] thought the activities to be part of project management, for which top management could, ideally, provide some oversight in the steering committee. It depends on the policies and decision making structure whether top management or the CIO is involved or not. It is not that simple that the board or top management is responsible for these particular activities of the model, as many activities are delegated.
8.2.4. Information accuracy Besides evaluating the understandability and usefulness of the model, the information of the model and table was validated by two interviewees who had expert knowledge on cloud computing [User 4; Expert 6]. According to them, the information was correct. However, [User 6] pointed out the organizational impact is not limited to the IT department. He explained: when applications are replaced by cloud solutions, its functionality could also affect non-IT employees. This corresponds to the findings in this research, but this was not seen as an impact of cloud computing, as non-cloud solutions could also have this impact. Further, two non-experts mentioned the service management processes were only relevant when the cloud solution was operational, not during adoption [User 3 and User 5]. It was assumed service management processes could be relevant to the whole cloud lifecycle (see section 4.2).
8.2.5. Additional comments The interviewees provided some additional comments for the development of the final model:
Circle model implies a continuous set of actions, maybe use different format [Expert 6]. Too many stories are told; develop different models for different audiences [User 1] 83
An awareness model is useful for the board and non-IT top managers [User 1; User 3] Make a link to enterprise governance, including decision making structure, enterprise goals and policies [User 2].
8.3. Conclusion It can be concluded the model is not understandable and not very usable. The adoption project activities were misleading and often the center of attention. Also, the lack of clear phases and a beginning was confusing. The table was too detailed and caused information-overload. The provided information for the evaluation of cloud computing was therefore not really addressed by the interviewees; some did not even look at it. The supposed ‘governance / top management’ (Evaluate, Direct and Monitor), were at least disputable. They were applicable to cloud computing in one organization [User 3], but not in the others. It can therefore be concluded that it depends on the organizational structure of the organization whether top management or a governing body is involved with the governance / top management activities of the model. A positive aspect was the accuracy of the provided information. Most of the interviewees perceived the information as accurate, including the cloud computing experts [Expert 6; User 4]. The somewhat quantified results of this phase are shown in Table 24. The scoring is based on the opinions of the interviewees as perceived by the researcher. The analysis of this feedback, the implications for a revision of the initial framework and the development of the revised framework is discussed in the next chapter. Expert
CIO
CFO
CTO
CSO
Security project manager
Strategic IT advisor
Understandability
--
--
-
++
--
--
Usefulness
-/+
-
-
+
-
-
Governance Activities
--
--
+
++
--
--
Information accuracy
++
+
Table 24: results feedback potential users and experts (++ is most positive, - - is most negative, +/- is neutral).
84
9.
Development of the revised framework: version 2.0
The feedback of the potential users and the cloud computing experts was used to alter the initial framework and to develop a new version, which is closer aligned to the practices found in organizations and which is easier to understand. This chapter deals with the analysis of this feedback, the implications for a revised design and the presentation of the revised models.
9.1. Two separate frameworks In the initial cloud evaluation and governance framework, the governance aspect was modelled, whereas the cloud evaluation aspects (business case, organizational impact and risks) were presented as plain text in the corresponding table of the cloud governance model. According to [Expert 6] the table was too detailed. This clarifies why almost none of the interviewees commented on the evaluation aspects. Therefore two different models are developed. One cloud governance model and a separate cloud evaluation model, to ensure information-overload is prevented and to make the evaluation aspects more pronounced. The evaluation part of the framework may also be used at a different level (sourcing level) then the cloud governance aspect. While cloud governance is on the level of the project [User 2 and 5; Expert 6], evaluating cloud computing can be part of the sourcing strategy [User 1]. These findings are summarized in Table 26. Critique area / comment Table
Description Too detailed [Expert 6].
Implication The table of the initial framework is too detailed. Separated models for the evaluation and governance of cloud computing are therefore developed. This should also make the evaluation aspect more pronounced, as almost none of the interviewees looked at the information on the business case, organizational impact and risks. Table 25: the rationale behind the design choice of two separate models for the cloud evaluation and governance elements of this research.
The new framework therefore exists out of two different sub-frameworks (Table 26), each consisting out of a model and a corresponding table in which the elements of the model are elaborated. Together they form the cloud evaluation and governance framework. How the models and frameworks relate to each other is shown in Figure 26. Framework
Cloud governance framework: model and table
Cloud evaluation framework: model and table
Scope
Processes & risk-reducing controls for a secure and effective adoption and management of a cloud solution.
Assist in the decision of moving to the cloud.
Table 26: the models of the revised framework.
85
Cloud evaluation and governance framework
Cloud governance framework
Cloud evaluation framework
Model
Model
Corresponding Table
Corresponding Table
Figure 26: the elements of the revised cloud evaluation and governance framework.
9.2. Cloud governance framework Because the table of the initial cloud evaluation and governance framework was too detailed and none of the interviewees looked at the evaluation aspects (business case organizational impact and risks), two different models are developed to reduce information-overload and to make the evaluation aspects more pronounced. This section deals with the development of the cloud governance framework. Hereafter the cloud evaluation framework will be presented.
9.2.1. Cloud governance framework development The feedback on the initial cloud governance model was not very positive. The two most significant complaints are related to the supposed ‘governance activities’ (Evaluate, Direct and Monitor) and the adoption project. Most of the interviewees argued the activities of the model are not performed by general top management [User 1, 2, 4, 5 and 6] and should not be called ‘governance’ [User 1, 2 and 5; Expert 6]. While the CIO is responsible for cloud governance (setting up the organization) [User 1], it is not always responsible for the activities in the model. It depends on the organizational structure whether the business case is evaluated or project success is monitored by a top manager, as this responsibility could also be delegated to other members of the steering committee [Expert 6]. Because it is at least disputable whether the ‘Evaluate’, ‘Direct’ and ‘Monitor’ activities are in fact relevant to cloud computing, this perspective is omitted in the revised model. The focus is on cloud governance: processes and risk controls. This also leads to a revision of the 86
target group of the model. The new framework is targeted at the CIO and others who are involved with planning of the cloud project or strategy, as opposed to general top management. Another significant drawback was the adoption project, which was shown in the model next to the risk-reducing controls to point out when a certain group of controls needs to be applied. This led to confusion and most of the interviewees thought it was the central aspect of the governance model. In the revised model, the role of the project activities are more explicitly indicated. A comment of the cloud expert [Expert 6] was to omit the circle-design and go for a process oriented one. This is the design perspective of the revised model and is seen as a good solution to make the role of the adoption activities clearer. Further, comments were made about the level of granularity of the risks controls, service management processes, the data classification, risk management and the link to corporate governance. The main groups of critiques and its implications are shown in Table 27. Critique area / comment Governance /top management activities
Management oversight
Adoption project
Description
Implication
Not general top management or governance activities in most organizations [User 1, 2, 4, 5 and 6]. Top management mostly concerned with alignment to business needs in steering committee and monitoring value, not with managing risks or implementing processes [User 4]. CIO responsible for cloud governance [User 1], but not always all the activities in the model, as they could be delegated [Expert 6]. No clear begin or phases [User 1 and 4; expert 6]. Ensuring cloud solutions being aligned to business goals and the monitoring of the business case and KPIs can be seen as management oversight on the level of the steering committee [User 1 and 4; Expert 6]. It is important top management is involved in the project [User 4].
As it is as least disputable the ‘Monitor’, ‘Evaluate’ and ‘Direct’ activities also apply to cloud governance, this perspective is omitted and the focus is on cloud governance (processes & controls).
Controls
Confusing role in the model. Seems to be the central aspect [User 1, 2 and 4; Expert 6]. Omitting the circle-design is better suitable to distinguish the phases [Expert 6]. Too detailed [User 1].
Data classification
Unclear role [User 3].
Corporate and IT governance
A link should be made with corporate governance structure and implications, such as enterprise objectives and decision making model [User 3]. Top management not involved with (all of) these activities [User 1, 2, 3 and 4; Expert 6]. CIO is responsible for cloud governance [User 1] or others involved in the cloud project as steering committee members [Expert 6].
Target audience
Top management must however be involved in aligning cloud solutions to business need and monitoring its value. While not depicted as governance, the project activities are shown to be monitored by management oversight activities. The role of adoption project was not clear. A process-design is adopted in the revised model to make the role of the adoption project clearer. The ‘monitoring’ controls were too detailed. These controls are grouped in the new version. Unclear role of data classification. More clear role of this control in revised model. A link is shown with corporate and IT governance in the revised framework. General top managers, such as the CEO, is not involved with setting up the service management process and with managing risks. Audience of new cloud governance and evaluation model is the CIO and others involved with adopting cloud computing.
87
Service Management processes
Need to be implemented in the cloud adoption project, to manage the service when operational [User 3 and 5]. Additional experts were consulted and shown in Appendix H. This corresponded to the opinions of [User 3 and 5]. While depicted properly in the model, the table does not clarify the risks management process must be performed periodical [User 3].
Service management process are not applicable to the whole cloud adoption project. Service management processes are only applicable to the ‘Adopted’ phase. Risk management It was not mentioned the Risk management’ process should be performed on a regular basis. This is clarified in the description of ’Risk management’. Table 27: main points of critiques and implications for revised cloud governance framework.
As the ‘top management activities perspective’ (Evaluate, Direct and Monitor) is omitted, the revised cloud governance model is a radical change. The focus is solely on cloud governance: processes and risk-reducing controls. The high-level design is depicted in Figure 27.
Project activities
Processes
Risk-reducing controls
Figure 27: high level design, based on additional comments and critiques of interviewees.
9.2.2. The revised cloud governance model The revised governance model shows the processes which need to be implemented, the high level groupings of controls and the project activities to make clear when the risk-reducing controls should be applied. The content of the model and the links to the thesis sections is shown in Table 28, the actual model in Figure 28. Element Cloud governance: processes
Description Thesis section The management processes which 6.2; 6.4 need to be implemented for maximizing the value of the cloud solution and to minimize its risks. Cloud governance: riskThe high level grouping of risk6.2; 7.4 reducing controls reducing controls. Project activities The phases of cloud adoption in 7.4 order to show when the controls apply. Management oversight The involvement of top 9.2.1 management in the cloud project. Link to enterprise and IT The cloud solution is not adopted 8.2.5; 9.2.1 governance in isolation but is influenced by internal rules made by directors, such as policies and enterprise goals. Table 28: elements of the revised cloud governance model and links to thesis sections.
Visualization Light blue rectangles.
Dark blue rounded areas. Green arrows.
Green shade to project activities Grey rounded line.
88
The Cloud Governance Model: management processes & security controls for an effective and secure adoption of an off-premise cloud solution. Corperate & IT governance
Management oversight
Plan
Cloud Risks & Controls
SLA & Vendor requirements
Engage
Implement
Operate
SLA & Vendor negotiation and evaluation
Internal security & availability plans
Monitoring
Data classifications Risk management process Service management processes Security management processes
Project activities
Processes & roles and responsibilities
High-level, advised risk-reducing controls
Figure 28: the revised cloud governance model.
This model depicts cloud governance as a system or framework, not anymore as part of the ‘Corporate Governance of IT’ (Evaluate, Direct and Monitor). The model assists CIO’s and others involved with the adoption of cloud computing with depicting the processes needed for an appropriate management of the cloud solution and the high-level advised risk-reducing controls for reducing risks of the cloud solution(s). Risk management is of importance to the whole project, as it provides controls and it identifies the risk of the cloud solutions before adoption. Hereafter, at multiple times this should be redone, including periodic when the solution is operational. Service and security management processes should be implemented within the cloud adoption project and are needed when the solution is live. The cloud project is also dependent on the enterprise and IT governance of an organization, regardless of the exact meaning of this concept. Amongst others, security and outsource policies determine which solutions can be ‘cloud sourced’. Management oversight is also depicted, although strictly not part of cloud governance. It is necessary to assure the cloud solution’s value will be delivered. 89
9.2.3. The corresponding table of the cloud governance model The additional table is made less detailed and only provides the information on the riskreducing controls and the processes; the elements of cloud governance. The project activities are described to get an idea of when the controls are relevant. This should prevent information-overload, while providing an elaboration of the elements in the model. Table 29 shows the elements of the table and the links to the thesis sections. The table as part of the framework is shown in Figure 29. Element Project activities
Description Thesis section The project activities are described 7.4 on a high level to provide the context for when the controls should be applied. Processes Examples of the high level 6.2; 6.3; 6.4 management processes are given to give insights into how the management framework needs to be adapted. High level advised risk-reducing The high level groupings of the 6.2; 6.4; 7.4 controls controls are described and examples are provided to get an understanding of how the risks need to be managed. IT and enterprise governance The link to IT and enterprise 8.2.5; 9.2.1 governance is described. Table 29: the elements of the additional table and the links to the thesis sections.
90
Project activities Plan: The cloud initiative is evaluated and the project is planned.
Engage: Cloud provider is selected. Implement: Cloud solution is rolled out and integrated into the existing landscape. The required (service & security) processes and risk-reducing controls are implemented. Operate: Solution is operational and being, managed, monitored and possibly refreshed.
Management oversight: Senior management should oversee the project, monitor the business case and its KPI s, the SLA and whether the service still fulfills business needs. Processes Risk management: The identification of risks and risk-reducing controls. These should be taken into account when evaluating the cloud solution, when planning the project (risk management strategy) and periodical after adoption. The identification is based on business and compliance requirements, the assets in the cloud (data & processes), enterprise risk appetite and cloud model (delivery & deployment).
Service management: ITIL-like processes need to be implemented or adapted for the management of the cloud service, such as provider, financial and SLA management, to monitor and manage the contracts and providers. The employees must be trained to deal with these new roles. Security management: As part of internal security (see advised risk-reducing controls), processes need to be implemented to secure the service, such as key-management, incident management and access control. High level, advised risk-reducing controls SLA and Vendor requirements: Identifiy SLA risk mitigation requirements (e.g. data ownership), identify relevant compliance and privacy regulations and the corresponding security controls and vendor requirements(e.g. security processes and data center location) and benchmark applications for setting up service metrics (e.g. response time) for SLA. SLA and Vendor negotiation: Evaluation of Vendor and SLA according to requirements or the negotiation of the SLA when it is not fixed.
Internal security: Internal security controls, such as security management processes, network and application security, cryptography and data management policies Availability plans: To reduce availability risks, several plans or strategies need to be developed such as fail-over strategies (for outages) and exit-strategies (for provider lock-in). Monitoring: The SLA, compliance logs, internal security controls (e.g. network security), data movement (sensitive data, cryptogtaphy) and events which could lead to new risks, such as change in compliance regulations or provider and tenants actions.
Data classification: An data classification scheme should be put in place for the identification of the cloud solution and for monitoring data movement. Sensitive data should not be put in the cloud. Corperate governance The cloud solutions should be aligned to the corperate strategies and policies. IT/cloud Strategy and security policies determine which applications are appropiates to outsource and adoption policies determine who can start the cloud project and who should be inolved. Also, cloud solutions should be based on business drivers to support overall business strategy and risks are identified according to corperate risk appetite and business & compliance requirements.
Figure 29: additional table for the revised cloud governance model.
91
9.3. Cloud evaluation framework The information to assist higher management with the evaluation of cloud computing, whether it is valuable to move to the cloud, was included in the additional table of the initial cloud governance model. Most of the interviewees did not even look at it and a cloud expert argued this was caused by an information-overload of the table (see section 8.2.2). Therefore, an additional model is created which can be used by managers to evaluate cloud computing solutions as part of a sourcing strategy or cloud project. First the development of the framework is discussed. Hereafter the model and the corresponding table are presented.
9.3.1. Cloud evaluation framework development The separate cloud evaluation model is developed, to reduce the information-overload for the users and to make it more pronounced. There is no need to alter the information which was provided in the table. The high level design will follow the steps which were mentioned in the corresponding table of the initial cloud governance and evaluation framework, as shown in Figure 30.
Figure 30: cloud evaluation aspects in the corresponding table of the initial cloud governance model.
However, one step is added: the link to strategy. It was concluded (see section 6.1) the initiative for cloud solutions can come from two ways: a technology push or from business needs. In the first scenario organizations look at their strategy to assess how cloud computing can enhance their IT and business strategy. In the latter way, cloud computing is a possible solution to a problem. In the initial framework, the strategy step (technology push) was omitted, as it was expected the users would already see cloud computing as a viable option for their strategy or as a solution to the problem, as the model was about cloud governance. The revised model is expected to be (also) used by organization that want to do something with the ‘trend’ cloud computing as part of their sourcing strategy. The additional ‘strategy’ step provides some context to the model and a clear beginning. 92
The high level design is depicted in Figure 31; the revisions to the initial cloud evaluation artefact are shown in Table 30.
Pre business case activities Business case elements
Business case development
Figure 31: abstract version of the revised cloud evaluation model. Element Model/visualization
Business case development steps
Organizational impact
Initial cloud evaluation and governance framework Textual, as part of the corresponding table. Service definition Model selection Business case development
Short explanation of the organizational impact. Risks Short description of the risks of cloud computing. Benefits Short explanation of the benefit groups and the link to business drivers. Costs Short description of cost calculation method within the business case development process information. Table 30: changes made to the cloud evaluation artefact.
(Revised) Cloud evaluation framework As a graphical model and a corresponding table which elaborates the elements. Strategy Service definition model selection Business case development Same Same Same
Same
93
9.3.2. The cloud evaluation model The cloud evaluation framework consist out of a graphical presentation and a corresponding table. The model shows the steps for developing the cloud business case as a complete process and provides the content of the business case, including a short elaboration of the elements. The content of the model and the links to the thesis sections are shown in Table 31, the actual model in Figure 32. Element Strategy
Readiness
Service definition
Scope selection
Business case
Organizational impact
Benefits
Risks
Costs
Description Represent the strategic activity in the whole process. Represents the activity to assess the organizational readiness. Represents the phase in which the service is defined, including the restricting factors (strategy, network and security). Represents the activity in which the exact model is selected. Represents the activity in which the business case is built and evaluated. Short description of the main organizational impact. Short description of the categories of benefits and the necessary link to business goals. Short description of the categories of risks and the difference between a private and public cloud. Short description of the approach which need to be applied for calculating costs.
Thesis section 6.1
6.1
6.1
6.1
6.1
6.2
6.1
6.3
6.1
Table 31: elements of the cloud evaluation model.
94
Strategy
Need for off premise cloud initiative? Assess the possible fit of cloud computing in the IT and business strategy.
Should be based on business drivers. Cost reduction, strategic and technical benefits.
Benefits
Readiness
Ready? The organizational readiness is determined. E.g. IT processes
Use TCO approach. Compare current costs against cloud costs.
Costs
Service definition
What in the cloud? Service should comply to security, strategy and network restrictions. E.g. e-mail client
Risk can be grouped in technical, legal and organizational risks. Private clouds are less risky.
Risks
Cloud model
What kind of cloud? Often scoped by strategic intent and security restrictions. E.g. Private vs. Public
Less IT employees, new roles and processes: shifts to managing contracts and providers
Organizational impact
Business case
Adopt cloud? Assess the solution s organizational impact, risks, benefits, cons and costs
Figure 32: the cloud evaluation model.
The model consists out of 5 steps, which correspond to the steps identified through the expert interviews. The target audience of this model is the CIO or others involved with adoption of cloud computing. In the first phase cloud computing is evaluated in the light of the current IT and business strategy to assess whether there are opportunities to enable this strategy. For example, the strategic objectives of cost reductions of the IT department could be achieved by replacing current, on-premise solutions by off-premise cloud applications. In the next phase the readiness of the organization is researched. This includes the organization’s processes (IT processes), capabilities, people and culture. If the organization is suitable for off-premise cloud computing, the existing applications are researched according to three criteria: strategy, security and network restrictions. The cloud solution should fit in the strategy and enterprise architecture. For example, many SaaS solutions are standard packages. Therefore applications which are custom made to enable strategic processes, are not good candidates to be replaced. Further, the application should comply with security policies (is the data and the process allowed in the cloud?) and the network performance (internal and public internet speed) should be good enough for the required performance. Some applications may need a very fast response time which the network does not allow. An example application which is often replaced by organizations (according to the experts; see section 6.1) is the e-mail application: from outlook, to for example Google’s Gmail. While the cloud model is often scoped by security policies and strategic intent (see section 6.4), still multiple models could be chosen for the cloud solution. For example, an off-premise e-mail application can be hosted by a public cloud provider, at which the hardware is shared 95
amongst other customers or tenants, or by a private cloud provider, at which the hardware is separated through a firewall. When the service is defined and the model is selected, a business case is built. This contains the organizational impact, the benefits, costs, risks and cons (see section 6.1). The organizational impact should be assessed first, as it identifies amongst other the benefits (e.g. less IT employees). The model shows some information on the aspects of the business case. Summarized, the cloud evaluation model provides the CIO the context for evaluating cloud computing, in order to make a thorough decision on whether to adopt a cloud solution. It can be used together with the cloud governance model, in order to get insights into how risks need to be managed and what processes need to be implemented. The next section presents the corresponding table.
9.3.3. The corresponding table of the cloud evaluation model A table is provided by the cloud evaluation model to elaborate the elements and to provide some extra information on the elements, including the organizational impact. The elements in the table follow the structure of the model. Table 30, which shows the aspects of the model and the corresponding sections in the thesis, therefore also applies to this part of the framework. The table which is provided as part of the evaluation framework is shown in Table 32. Element
Description
Strategy
In an IT strategy project the strategic role of cloud computing is determined. This could lead to a cloud initiative. For example, assessing how applications can be replaced by SaaS applications to reduce costs.
Readiness
Assess whether the processes, culture technology and capabilities are appropriate for cloud computing. Select the services (applications, developing platforms or infrastructures) which could be replaced by cloud solutions.
Service definition
Relevant factors/elements
Description
Additional information
Online questionnaires can be used.
Security
The service should comply with security policies and data classifications.
Data classification provides insights into the sensitivity of the applications data. Security policies determine amongst other what can be outsourced and to what extend sensitive may be put in the public and private off-premise cloud.
96
Cloud model
Determine the cloud model, which consists of the delivery and deployment model.
Business case
Develop a business case, which justifies the decision to adopt a cloud solution, or cloud solutions, instead of traditional IT or other forms of outsourcing.
Strategy
The service should fit in the strategy of the organization. This includes the IT strategy, a possible cloud strategy and the Enterprise Architecture.
Network
The network capabilities should be adequate for the service.
Organizational impact
Assess the impact on the organizations processes, people, structure, culture and existing IT landscape.
Costs
Determine the difference in costs of the cloud solution, the traditional solution and possibly other sourcing alternatives, through a Total Cost of Ownership approach (TCO).
An important consideration is the level of standardization of SaaS applications. As they cannot be customized, they are mostly appropriate for non-strategic business processes. Benchmarking current applications can provide response time requirements. An off-premise cloud can be a community, private or a public cloud (delivery model). The private cloud usage a more secure network connection and hardware resources are within their own security parameter (firewall). The deployment model can be SaaS (complete application), PaaS (development environment) and IaaS (hardware).
As elements are outsourced, less IT employees are needed. Also, the role of IT employees change to managing providers and contract. Service, risk and security management processes must be implemented for managing providers and contract, risks and security.
97
Risks
Determine the risks of the cloud solution.
Benefits
Determine the benefits of the cloud solution. These need to be based on business drivers. A ROI or NPV can be used as a value estimation metric. Develop a business case, containing the benefits, risks, costs, cons and organizational impact.
Business case
Risks can be grouped into organizational, technical and legal risks. The identification is based on business and compliance requirements (i.e. regulations), assets in the cloud (processes & data), the cloud model (e.g. private cloud) and the corporate risk appetite. The benefits can be grouped into strategic, technical and costreductive benefits.
If positive, continue cloud initiative and develop cloud adoption strategy. If not, keep existing IT.
Table 32: corresponding cloud evaluation table.
9.4. Relation between the cloud evaluation and governance frameworks The two frameworks represent different activities regarding cloud adoption: one is focused on evaluating cloud computing (adopt cloud?) and the other on governing cloud solutions. Evaluating cloud solutions takes place within the plan-phase of the cloud adoption project, or even before the project has begun, as part of for example the cloud sourcing strategy. The data classification must be implemented though before the service is defined in the ‘Service definition’ activity, to identify the proper cloud candidate applications. The relationship between the two frameworks is visualized in Figure 33.
Cloud evaluation framework Service definition Plan
Data classification
Figure 33: relationship in time between cloud evaluation framework and the cloud governance framework.
98
10. Expert feedback on the revised framework The cloud evaluation and governance models, as presented in the previous chapter, were again evaluated by as well possible users, C-suite managers, as cloud computing experts, in order to develop a final framework. The cloud experts in this validation round did not work close to Clevel executives, so they were not asked to provide input on the understandability and usefulness of the model. This feedback round addressed three aspects:
Is it understandable? It is clear how to use and apply the model? Is it useful and is the information valuable? Experts, is the model accurate? Is the provided information correct?
10.1. Approach Five interviews were held with potential users (top managers) or cloud experts for feedback on the cloud governance model (see Table 33). Four interviewees commented on the cloud evaluation model. Two interviewees (User 7 and 8) were part of the previous feedback round, so they also commented on the improvements compared to the previous framework. Although the main audience for the framework are CIO’s, other C-suite members could be involved with the cloud project. Therefore, the Chief Security Officer was also considered to be a possible user of the cloud governance model. The interviewees were selected if they were:
A C-suite manager or worked closely with them. An expert on cloud computing.
Expert profession
CIO
CSO (Same as last round)
Strategic IT advisor (Same as last round)
Organization
Hospital
University
Own company
Role Framework
Potential user Potential user Potential user Governance + Governance Governance + Evaluation Evaluation ID User 6 User 7 User 8 Table 33: overview of the respondents in the second feedback phase.
Cloud infrastructure consultant (telephone interview) Consultancy company Expert Governance + Evaluation Expert 7
Information security program director University of applied science Expert Governance + Evaluation Expert 8
The interviews were recorded by a mobile phone and transcripted afterwards. For the analysis, a qualitative content analysis method was applied (Zhang & Wildemuth, 2009). For each of the categories ‘understandability, ‘usefulness, and ‘information accuracy’ the main message of each interviewee was extracted. The results of the content analysis are shown in Appendix J, while the transcripts are shown in Appendix I.
99
10.2. Results The results of the feedback interviews are discussed for each of the categories.
10.2.1.
Understandability
All of the respondents understood the cloud governance model. None of them questioned the elements of the model. [User 8] argued the previous model was way too detailed, this one is good and understandable. There were also no significant problems with the understandability of the cloud evaluation model, but [User 8] interpreted ‘Service definition’ differently, namely as the impact on the ‘service infrastructure’. He argued this is because he does not understand the concept of cloud computing very well. A better explanation of a cloud service would be beneficial. [User 6] did not have a clear opinion on the cloud evaluation model as it does not reflect the activities he is involved in.
10.2.2.
Usefulness
The three potential users all found the cloud governance model to be usable. [User 8] argued it is very interesting what to do when you lose control, [User 6] mentioned even experienced project managers struggle with this issue and [User 7] found the risk-reducing controls to be very beneficial for IT managers. The risk-reducing controls seem to be found more interesting than the processes that are depicted. [User 1] did not comment on the usefulness of the cloud evaluation model, as cloud adoption takes place on a lower level in his organization. [User 8] found the model very useful for structuring evaluation activities. However, he argued additional methods and tools could make the model also valuable when performing the activities.
10.2.3.
Information accuracy
Two experts were consulted to assess the accuracy of the two models. [Expert 7] did not have any comments on the accuracy of the cloud governance model, but argued a governance model should also depict the exact roles and responsibilities. [Expert 8] found the model overall accurate, but argued the internal security should be addressed upfront, the riskreducing controls are not consistent (activities vs. controls), security management is a better term then risk management, auditing is a process not just a control and security management processes are controls. The potential users did not have much criticism on the cloud governance model. [User 6] argued though that auditing is an activity which is performed together with the provider and risk management is a loop. He also mentioned a ‘governance process’ should monitor the solution as part of a portfolio. Later on, he noticed this is also covered in the model (management oversight).
100
The experts found the cloud evaluation model accurate. They did not have any comments. [User 6] did not found the model to be correct, as it does not reflect the activities he is involved in. He does not develop the business case for cloud solutions. Further, when choosing a solution to put in the cloud, integration issues should be taken into account [User 6].
10.3. Conclusion It can be concluded, the cloud evaluation and governance models are useful, understandable and relatively accurate. The revised cloud governance model is an improvement on the initial framework. [User 8] said the initial one is too detailed and this one is good and understandable. However, in the organization [User 6] is working for, the cloud evaluation model does not reflect the activities of higher management. This can be explained by the level of maturity of this particular organization. Their level of standardization and cloud adoption is very high. On an architectural level cloud adoption is already fostered; the CIO is not involved anymore in the adoption of cloud applications, as this is done by lower IT managers. With regards possible improvements, [Expert 8] commented on the accuracy of the cloud governance model (e.g. activities vs. controls) and [User 8] on the usefulness of the cloud evaluation model, by arguing methods and tools should be added. Further, [user 6] mentioned the choice of cloud applications is also restricted by integration requirements. The somewhat quantified results of this phase are shown in Table 34. The analysis of this feedback and the implications for the development of the final cloud evaluation and governance models are discussed in the next chapter. Cloud evaluation model Expert CIO
Own company
Cloud infrastructure consultant (expert) (telephone interview) Consultancy company
Information security program director (expert) University of applied science
Understandability ++ Usefulness +Information accuracy Cloud Governance model Expert CIO
++ + +-
++
++
Strategic IT advisor
CSO
Organization
Own company
University
Organization
Hospital
Hospital
Strategic IT advisor
Cloud infrastructure consultant (telephone interview) Consultancy company
Information security program director University of applied science
Understandability ++ ++ ++ Usefulness + + ++ Information accuracy + ++ ++ + Table 34: results second feedback round potential users and experts (++ is most positive, - - is most negative, +/- is neutral).
101
11. Development of the final framework: version 3.0 The feedback on the revised cloud evaluation and governance models was positive. According to some interviewees certain aspects could be improved. In this chapter the feedback on the models are analyzed, its implications for the final frameworks are discussed and the final cloud governance and evaluation frameworks are presented.
11.1. Final cloud governance framework This section describes the development of the final cloud governance framework by analyzing the feedback. Hereafter, the final model and table are presented.
11.1.1.
Final cloud governance framework development
With regards to the cloud governance model, most critiques or point of improvements were mentioned by [Expert 8]. He argued different level of abstractions were used for the riskreducing controls. While ‘SLA and Provider requirements’ and ‘SLA and Vendor evaluation and negotiation’ are activities, ‘Data classification’ is an artefact. He was also skeptic about the position of the data classification. As it should be implemented before a cloud solution is selected, it should be placed before the other controls. He also argued the ‘security management processes’ were more controls, than an adaption of the management framework, while ‘Monitoring audits’ was considered to be an important process. This is a complicated discussion: what exactly are the processes which need to be implemented to manage cloud solutions and what are risk-reducing controls. Too solve this issue, the processes which were not mentioned as risk-reducing controls are listed. These are the risk management process and the service management processes. The risk-reducing controls are the measures in order to mitigate the identified cloud risks. The service management processes are broader than addressing these cloud risks. For example, financial management ensures the cloud service is cost effective. Further, he mentioned ‘CIA’, confidentiality, integrity and availability (data security qualities), should be depicted in the model and the process ‘risk management’ should be changed to ‘security management’, as this is a more broad process which also takes into account the people. The notions of the security qualities ‘CIA’ will not be depicted, as this will make the model too detailed. With regards to the differences between security and risk management, not much additional literature was found. It seems the terms are used interchangeable. As all of the literature regarding managing cloud risks referred to ‘Risk management’, as opposed to ‘Security management’, this will not be changed. [User 6] commented on the risk management process. While it is noted the risk management process is a continuous process, there is no loop from ‘Monitoring’ to setting the requirements of the SLA and Vendor. When the environment changes, such as legal requirements, the requirements are outdated and new negotiations must begin, according to this interviewee. This is changed in the final model. The revisions to the previous cloud governance model depicts an evolutionary change. The perspective and high-level design remains unchanged. The groups of critiques on the cloud governance framework and its implications are shown in Table 35.
102
Critique area / comment Type of control
Description Data classification is an artefact, while others are more activities [Expert 8].
Implication All controls are listed and described as activities.
Data classification
Role of the data classification was still not clear [Expert 6].
Security management processes
These processes are risk-reducing controls [Expert 6]. They must be implemented, at least partially, before ‘implementation’ [Expert 6].
Ideally, the data classification should already be implemented before the other activities, as it is needed to select the cloud solution and thus determining the SLA and provider requirements. This is shown in the final model. Only the processes which are not listed as risk-reducing controls are shown.
Service management process.
Unclear role of the service management processes and when they must be implemented.
The implementation of service management processes is explicitly shown.
Risk management
Risk management is a continuous activity: after monitoring compliance requirements, new SLA and Vendor requirements can be identified [User 6].
Loop from ‘Monitoring’ to first control is depicted in the revised model.
Should be called security management [Expert 8]
CIA, Confidentiality, Integrity and availability
CIA, Confidentiality, Integrity and availability, should be added to the model [Expert 8].
‘Risk management’ will not be changed to ‘Security management’, as most literature referred to cloud ‘Risk management’ as the process to manage the risks. CIA is not added to the model, as this will make it too detailed.
Table 35: changes from revised cloud governance framework to final cloud governance framework.
11.1.2.
The final cloud governance model
As the changes to the previous version are not radical, most of the elements remain the same. The content of the final cloud governance model is shown in Table 36, the actual model is shown in Figure 36. Element Cloud governance: Processes
Description The management processes which need to be implemented for maximizing the value of the cloud solution and to minimize its risks.
Thesis section 6.2; 6.4
Visualization Light blue rectangles.
103
Cloud governance: security controls Project activities
The high level grouping 6.3; 7.4 of security controls. The phases of cloud 7.4 adoption in order to show when the controls apply. Management oversight The involvement of top 9.2.1 management in the cloud project. Link to enterprise and IT The cloud solution is not 8.2.5; 9.2.1 governance adopted in isolation but is influenced by internal rules made by directors, such as policies and enterprise goals. Table 36: elements of the final cloud governance model and links to thesis sections.
Dark blue rounded areas. Green arrows.
Green shade to project activities Grey rounded line.
The Cloud Governance Model: risk-reducing activities and management processess for an efective and secure adoption of a public cloud solution. Corperate & IT governance
Management oversight
Implement
Engage
Plan
Operate
Implement internal security Implement data classification
Determine SLA & Vendor requirements
Negotiate and evaluate Vendor & SLA
Develop availabilityrisk reducing strategies
Monitor
Cloud Risks & Controls Risk management process Service management processes
Implement
Project activities
Processes & roles and responsibilities
High-level, advised riskreducing activities
Figure 34: the final cloud governance model.
Just like the revised cloud governance model, this final version shows the processes which need to be implemented to manage the cloud service(s), the risk-reducing controls which must be applied and the project-activities, in order to show to what phase of the project or cloud life-cycle the controls apply. A notable difference is the position of the data classification control, ‘Implement data classification’. This is now placed before the other controls. The cloud solution, with corresponding risks and controls, is selected based on this data classification and should therefore be implemented before any other risk-reducing activity.
104
Also, the implementation of the service management process is explicitly shown, the controls are all approached as activities and an arrow from ‘monitoring’ to the other controls is depicted.
11.1.3.
The corresponding table of the final cloud governance model
The additional table has not changed much. Just like in the previous version, the table elaborates the elements of the model and describes the project activities to provide a context for the controls. The elements which are adapted in the cloud governance model are also changed in the table: the controls are changed to activities, security management processes are considered to be controls and it is mentioned there is a loop from the ‘Monitoring’ controls towards the ‘Determine SLA and Vendor requirements’ activity. Table 37 shows the elements of the table and the links to the thesis sections. The table as part of the framework is shown in Figure 35. Element Project activities
Description Thesis section The project activities are described 7.4 on a high level to provide the context for when the controls should be applied. Processes Examples of the high level 6.2; 6.4 management processes are given to give insights into how the management framework needs to be adapted. High level advises security The high level groupings of the 6.2; 6.4; 7.4 controls controls are described and examples are provided to get an understanding of how the risks need to be managed. IT and enterprise governance The link to IT and enterprise 8.2.5; 9.2.1 governance is described. Table 37: the elements of the additional table and the links to the thesis sections.
105
Project activities Plan: The cloud initiative is evaluated and the project is planned.
Engage: Cloud provider is selected. Implement: Cloud solution is rolled out and integrated into the existing landscape. Operate: Solution is operational and being, managed, monitored and possibly refreshed. Management oversight: Senior management should oversee the project, monitor the business case and its KPI s, the SLA and whether the service still fulfills business needs.
Processes Risk management: The identification of risks and risk-reducing controls. These should be taken into account when evaluating the cloud solution, when planning the project (risk management strategy) and periodical after adoption. The identification is based on the assets in the cloud (data & processes), enterprise risk appetite and cloud model (delivery & deployment). Service management: ITIL-like processes need to be implemented or adapted for the management of the cloud service, such as provider, financial and SLA management, to monitor and manage the contracts and providers. The employees must be trained to deal with these new roles. Some of the process can be implemented up front, but some need to be organized together with the provider, such as incident management. High level, advised risk-reducing controls Implement data classification: An data classification scheme should be put in place for the identification of the cloud solution and for monitoring data movement. Sensitive data should not be put in the cloud. Determine SLA and Vendor requirements: Identifiy SLA risk mitigation requirements (e.g. data ownership), identify relevant compliance and privacy regulations and the corresponding security controls and vendor requirements(e.g. security processes and data center location) and benchmark applications for setting up service metrics (e.g. response time) for SLA. Evaluate and negotiate SLA and Vendor : Evaluation of Vendor and SLA according to requirements or the negotiation of the SLA when it is not fixed.
Implement Internal security: Internal security controls, such as security management processes (e.g. acces control), network and application security, cryptography and data management policies must be implemented. This can be done during implementation, but it is advised most is done before implementing the service to reduce workload. Develop availability-risk reducing strategies: To reduce availability risks, several plans or strategies need to be developed such as fail-over strategies (for outages) and exit-strategies (for provider lock-in). Monitor: The SLA, compliance logs, internal security controls (e.g. network security), data movement (sensitive data, cryptogtaphy) and events which could lead to new risks, such as change in compliance regulations or provider and tenants actions. When new risk arise, the previous risk-reducing activities should be performed again. Corperate & IT governance The cloud solutions should be aligned to the corperate strategies and policies. IT/cloud Strategy and security policies determine which applications are appropiates to outsource and adoption policies determine who can start the cloud project and who should be involved. Also, cloud solutions should be based on business drivers to support overall business strategy and risks are identified according to corperate risk appetite and business & compliance requirements.
Figure 35: additional table for the final cloud governance model.
106
11.2. Final cloud evaluation framework This section described the development of the final cloud evaluation framework, consisting of a final model and table.
11.2.1.
Final cloud evaluation framework development
In the revised framework of this research, separate models have been developed for the governance and evaluation aspects. Based on the feedback, there is no need to change the high-level design of the cloud evaluation model. However, there were some aspects which could be made clearer and tools en methods should make the model more valuable. [User 6] argued cloud adoption does not start with ‘Strategy’, but as a solution to a problem as a sourcing alternative. To make it more explicit that cloud adoption could be triggered by as well a technology as a business push, the starting point of cloud computing ‘being a solution to a specific problem’ is added in the final model. Further, [User 6] pointed out the cloud solution should comply with integration requirements. Some applications cannot be put in the cloud because of integration issues. [User 8] would find the model better usable if the concept of ‘cloud service’ is defined: what is the different with a traditional service? Also, he argued, methods and tools should be provided in the table of the model to make it more practical. The concept of a cloud service is elaborated in the final table. Because the additional tools are not all scientific ones, they are not part of the cloud evaluation framework, but are discussed and presented in Appendix K. The groups of critiques on the cloud evaluation framework and its implications are shown in Table 38. Critique area / comment Strategy
Description Cloud adoption starts as a problem not with strategy [User 6].
Implication The model starts with cloud computing being as well a strategic enabler as a solution to a problem.
Service definition
The concept of cloud service could be made more clear [User 8]. Service should also be compatible with integration requirements [User 6].
The concept of a cloud service is elaborated in the table. The limitation for selecting cloud applications ‘integration’ is added to the model in the ‘Service definition’ step.
Tools and methods
Tools and methods should be added to make the model more practical [User 8].
Appendix K covers these tools and techniques, as they are not all scientific ones.
Table 38: groups of critiques on the cloud evaluation model.
107
11.2.2.
The final cloud evaluation model
Just like the previous version, the final cloud evaluation model consist of a graphical presentation and a corresponding table. The model shows the steps for developing the cloud business case as a complete process and provides the content of the business case, including a short elaboration of the elements. The content of the model and the links to the thesis sections is shown in Table 39, the actual model in Figure 36. Element Need for cloud solution
Readiness
Service definition
Scope selection
Business case
Organizational impact
Benefits
Risks
Costs
Description Represent the phase in which the need is determined for a cloud computing solution. Represents the activity to assess the organizational readiness. Represents the phase in which the service is defined, including the restricting factors (strategy, integration, network and security). Represents the activity in which the exact model is selected. Represents the activity in which the business case is built and evaluated. Short description of the main organizational impact. Short description of the categories of benefits and the necessary link to business goals. Short description of the categories of risks and the difference between a private and public cloud. Short description of the approach which need to be applied for calculating costs.
Thesis section 6.1
6.1
6.1
6.1
6.1
6.2
6.1
6.3
6.1
Table 39: elements of the cloud evaluation model.
108
Should be based on business drivers. Cost reduction, strategic and technical benefits.
Benefits
Need for cloud solution
Need for off premise cloud initiative? Cloud computing is a possible solution to a problem or a strategic enabler.
Readiness
Ready? The organizational readiness is determined. E.g. IT processes
Use TCO approach. Compare current costs against cloud costs.
Costs
Service definition
What in the cloud? Service should comply to security, integration, strategy and network restrictions. E.g. e-mail client
Risk can be grouped in technical, legal and organizational risks. Private clouds are less risky.
Risks
Cloud model
What kind of cloud? Often scoped by strategic intent and security restrictions. E.g. Private vs. Public
Less IT employees, new roles and processes: shifts to managing contracts and providers
Organizational impact
Business case
Adopt cloud? Assess the solution s organizational impact, risks, benefits, cons and costs
Figure 36: the final cloud evaluation model.
Like the revised model, the final model consist out of five steps. The target audience of this model is the CIO or others who want to do something with the technological trend ‘cloud computing’ as part of their sourcing strategy or who have determined cloud computing could be a solution to a problem. In the first phase it is determined cloud computing could be beneficial to the organization. As mentioned above, cloud computing may be actively researched whether it can enhance strategy or it is a possible solution to a problem. In the first case, for example, the strategic objectives of cost reductions of the IT department could be achieved by replacing current, onpremise solutions by off-premise cloud applications. Another option is that cloud computing comes forward as a solution to a problem. For example, the problem of a very expensive system may lead to an assessment whether cloud computing could lead to lower costs. In the next phase the readiness of the organization is researched. This includes the organization’s processes (IT processes), capabilities, people and culture. If the organization is suitable for off-premise cloud computing, the existing applications are researched according to four criteria. Based on the feedback on the revised cloud evaluation model, ‘Integration’ restrictions are added to the list of restrictions which need to be taken into account when selecting cloud candidate applications. Some applications require to be integrated with other systems. SaaS does often not provide this option. The cloud solution should also fit in the strategy and enterprise architecture. For example, many SaaS solutions are standard packages. Therefore applications which are custom made to enable strategic processes, are not good candidates to be replaced. Further, the application should comply with security policies (is the data and the process allowed in the cloud?) and the network performance (internal and public internet speed) should provide adequate performance for the applications. Some applications may need a very fast response time which the network does 109
not allow. An example application which are often replaced by organizations (according to the experts; see section 6.1) is the e-mail application: from outlook, to for example Google’s Gmail. While the cloud model is often scoped by security policies and strategic intent (see section 6.4), still multiple models could be chosen for the cloud solution. For example, an off-premise e-mail application can be hosted by a public cloud provider, in which the hardware is shared amongst other customers or tenants, or by a private cloud provider in which the hardware is separated through a firewall. When the service is defined and the model is selected, a business case is built. This contains the organizational impact, the benefits, costs, risks and cons (see section 6.1). The organizational impact should be assessed first, as it identifies amongst other the benefits (e.g. less IT employees). The model shows some information on the aspects of the business case. Summarized, the cloud evaluation model provides the CIO the context for evaluating cloud computing, in order to make a thorough decision on whether to adopt cloud or use traditional, on-premise IT solutions. It can be used together with the cloud governance model, in order to get insights into how risks need to be managed and what processes need to be implemented. The next section presents corresponding table of the final cloud evaluation model.
11.2.3.
The corresponding table of the final cloud evaluation model
The corresponding table describes the elements of the model and in this final version, some minor changes have been made. As the activities, ‘Cloud need’, and ‘Service definition’ were adjusted in the model, this is updated in the table. The final corresponding table is shown in Table 40. Element
Description
Cloud need
The need for a cloud solution can come from two ways. Cloud computing may be a solution to a specific problem (a strategic one or for a specific application). Second, it may be concluded cloud computing can enable strategy after actively researching its opportunities. Assess whether the processes, culture technology and capabilities are appropriate for cloud computing. Select the services (applications, developing platforms or infrastructures) which could be replaced by cloud solutions.
Readiness
Service definition
Relevant factors/elements
Description
Additional information
Online questionnaires can be used.
Cloud services are services provided over the internet and hosted by a third party organization. It can entail infrastructure/hardware
110
Cloud model
Determine the cloud model, which consists of the delivery and deployment model.
Business case
Develop a business case, which justifies the decision to adopt a cloud solution, or cloud solutions, instead of traditional IT or other forms of outsourcing.
Security
The service should comply with security policies and data classifications.
Strategy
The service should fit in the strategy of the organization. This includes the IT strategy, a possible cloud strategy and the Enterprise Architecture.
Network
The network capabilities should be adequate for the service.
Integration
The service should comply with integration requirements.
services (IaaS), platform services (PaaS) and application / software services (SaaS). Data classification provides insights into the sensitivity of the applications data. Security policies determine amongst other what can be outsourced and to what extend sensitive may be put in the public and private off-premise cloud. An important consideration is the level of standardization of SaaS applications. As they cannot be customized, they are mostly appropriate for non-strategic business processes. Benchmarking current applications can provide response time requirements. Some services need a complex integration with other systems, which may not be achievable with cloud solutions. An off-premise cloud can be a community, private or a public cloud (delivery model). The private cloud usage a more secure network connection and hardware resources are within their own security parameter (firewall). The deployment model can be SaaS (complete application), PaaS (development environment) and IaaS (hardware).
111
Organizational impact
Assess the impact on the organizations processes, people, structure, culture and existing IT landscape.
Costs
Determine the difference in costs of the cloud solution, the traditional solution and possibly other sourcing alternatives, through a Total Cost of Ownership approach (TCO). Determine the risks of the cloud solution.
Risks
Benefits
Business case
Determine the benefits of the cloud solution. These need to be based on business drivers. A ROI or NPV can be used as a value estimation metric. Develop a business case, containing the benefits, risks and costs.
As elements are outsourced, less IT employees are needed. Also, the role of IT employees change to managing providers and contract. Service, risk and security management processes must be implemented for managing providers and contract, risks and security.
Risks can be grouped into organizational, technical and legal risks. The identification is based on business and compliance requirements (i.e. regulations), assets in the cloud (processes & data), the cloud model (e.g. private cloud) and the corporate risk appetite. The benefits can be grouped into strategic, technical and costreductive benefits.
If positive, continue cloud initiative and develop cloud adoption strategy. If not, keep existing IT.
Table 40: corresponding table to the cloud evaluation model.
11.3. Relation between the cloud governance and evaluation frameworks The relationship between the two frameworks has not changed (Figure 37). First cloud computing is evaluated, hereafter it is governed. The data classification must be implemented though to select the correct services.
112
Cloud evaluation framework Service definition Plan Implement data classification
Figure 37: relationship between the two frameworks.
113
12. Conclusion & Summary In this research two concerns for top management are addressed which are not yet covered in literature. The first element is an integrative approach to the aspects of cloud computing which are considered to be important for the evaluation of cloud computing, namely the risks, business case and organizational impact. Second, cloud governance was researched. The goal of this research was to assist higher management evaluating and governing cloud solutions through an artifact. Eventually, the research is scoped by off-premise cloud computing, as onpremise solutions are almost like traditional IT to manage. In order to develop the framework, literature was reviewed in conjunction with additional interviews with six cloud computing experts. This resulted in an initial framework, on which feedback was provided by six potential users and cloud experts. Based on these results, a revised framework was developed, consisting out of two separate models for the evaluation and governance of cloud solutions. After a second round of feedback, a final framework was developed. The research questions can be answered accordingly: I.
How can a business case be developed for cloud computing?
In practice, costs are the most decisive factor in the business case. Less quantifiable aspects are strategic benefits and risks. A cloud computing initiative is triggered by two types of drivers: technology and business drivers. In the first case, organizations actively research the benefits of cloud computing for the organization. In the latter case, cloud computing comes forward as a solution to an operational, tactical or strategic problem. Based on certain business drivers or the IT strategy there may be a need to move to the cloud. The benefits included in the business case should therefore be based on these drivers, such a reducing costs, in order to ensure the cloud solution add value to the organization. It is important the application amongst others comply with security policies, it can cope with the network capabilities and it fits in the IT strategy and architecture. The enterprise architecture is an important tool to identify the applications which are appropriate to ‘cloud source’. Upfront this process, it should be assessed whether the organization is ‘ready’ to replace applications by cloud solutions. II. What is the impact of cloud computing on the organization? The biggest impact is on the IT department. As infrastructure is outsourced by off-premise cloud computing, less maintenance is needed. This may lead to a reduction of IT employees. Their roles will also change. Instead of managing applications and data centers, they manage services and providers. The appropriate processes must therefore be implemented. ITIL-like processes need to be adapted or implemented, such as SLA and provider management. There is not a big impact on culture. However, the authority of the IT department may be reduced, as business can bypass IT employees in procuring services. Further, there is no need for a new decision making structure and there is not much impact on the employees outside the IT department. Instead of having to deal with new kinds of functionalities of the cloud service, they can make use of the new possibilities cloud solutions provide and the accounting 114
department must get used to renting services. III. What are the risks of moving to the cloud and how can they be managed? The risks aspect of cloud computing is extensively covered in scientific literature. Off-premise cloud computing brings additional security risks compared to traditional IT and public cloud computing is more risky than a private cloud (off- and on-premise). The risks can be grouped into the following categories: Confidentiality & Privacy, Data control, Availability of data and services, Data integrity, Data encryption, Logical access, Network security, Physical access and Compliance. Risk management is the process of identifying these risks and developing appropriate strategies to mitigate them. For cloud computing an important part is to evaluate the provider and SLA according to risk-reducing requirements, such as data location and a thirdparty audit clausal in the SLA. Further, internal security controls must be implemented, availability risk strategies must be established (e.g. exit-strategy) and certain aspects must be monitored, such as compliance logs of the provider. Further, an organization must establish a data classification scheme to identify appropriate applications to put in the cloud. IV. How does governance apply to cloud computing? 4.1. What is governance? 4.2. Which perspectives on cloud governance can be identified? 4.3. Which view(s) on cloud governance is (are) the most relevant and therefore the most appropriate perspective(s) for the framework developed in this research? 4.4. What does the relevant perspective(s) on cloud governance entail? Governance means ‘to steer’. On a corporate level, governance entail mechanisms which ensure management acts on behalf of the owners, and include the board of directors and management incentives. IT governance is a more ambiguous term. The level of this ‘steering’ differs between perspectives. A common used definition describes IT governance as leadership, processes and structures. But references are made to different types of processes. Some include only strategic decision making processes, others all processes needed to manage and control IT, as are included in for example the ITIL framework. Further, IT governance can be explained as and accountability framework and as a process performed by directors, which implement and monitor these processes and structures. Cloud governance is also a concept which is viewed in multiple ways. One view is of it being similar to SOA governance. Another perspective is cloud governance being all about securing information and business processes. Lastly, it is seen as the processes and structures to manage cloud solutions. In this research the latter two views are combined into the following definition: “Cloud governance is the framework of processes, structures and risk-reducing controls for maximizing the cloud solution’s value and minimizing its risks.” This refers to cloud governance being a framework, a management structure ensuring risks are being minimized and value is maximized. It consist out of service and risk management
115
processes. Security management processes must be implemented to reduce security issues and several risk-reducing activities must be performed, as explained above. Initially it was thought the activities of directors, which consist of evaluating, directing and monitoring activities, are responsible for cloud governance. However, most C-suite executives do not consider the activities of implementing cloud governance as activities of directors. ‘Governance’ of the management structure is more related to the high level processes and structures, such as the overall decision making structure and processes for prioritizing IT initiatives. Cloud computing does not need an adaption of the IT decision making structure. How can a framework or model be designed that assist higher management in their evaluation and governance of cloud computing? The main research question addressed the development of a framework which include the answers to the research questions above. In the initial framework, the governance aspect was modelled according to the perspective of governance / top management activities (Evaluate, Direct and Monitor). The evaluation aspects were included in the corresponding table, in which also the elements of the model were elaborated. The feedback on this framework was not very positive. It was not clear what the phases were, where the model started, how the adoption project related to the other activities and the table contained too much information. Also, most of the interviewees viewed the supposed ‘governance activities’ as cloud project activities, in combination with management oversight. In their opinion, top management who act on a board level, are evaluating and governing cloud computing on a higher level, for which an awareness model would probably be more useful. The revised framework consisted out of two models: one for addressing the evaluation of cloud computing and one for the governance of cloud computing. This was done to make the evaluation aspects more pronounced and to reduce information-overload of the corresponding table of the cloud governance model. The revised cloud governance model depicts the processes and risk-reducing controls for the CIO and others which are involved in planning the cloud project. The cloud evaluation model includes the whole process towards building the cloud computing business case. According to cloud experts and potential users, the two models were overall accurate and they could be very valuable to CIO’s to evaluate and govern cloud solutions. Based on the feedback on the revised two models, a final framework was developed. Only relatively small changes had to be made: the perspective and overall content remained.
116
13. Discussion, Limitations & Future research To achieve a proper validity, the models developed in this research were as well based on literature as interview with experts and potential users. However, still some aspects of this research can be considered as a concern to the validity of the results. Grey literature is used together with scientific literature. Whitepapers from ISACA, the IT Governance Institute and some consulting companies were used as input to the models. These organizations could have been sponsored by commercial companies, which affects the credibility of their whitepapers. However, most of the whitepapers were from respective organizations (e.g. ISACA, CSA etc.) and are also used by many other scholars. Also, a limited amount of interviewees took part in each interview round (at most six interviewees). Because of this small amount of participants, the results may not be generalizable. Applying a ‘Delphi’ method in which a large amount of experts provide their opinion on the subjects in distinct rounds, would have probably lead to more valid results. Because of difficulties in acquiring expert participants for the interviews, the ‘Delphi’ method was not considered to be feasible. A case study to validate the framework would therefore be a good future research opportunity. With regards to the developed frameworks, a limitation may be the lack of depth of the cloud evaluation framework and the extent to which the cloud governance objective is achieved. The evaluation part of the research addressed the business case, organizational impact and risks of cloud computing. As the business case for cloud computing turned out to be pretty similar to that of traditional IT investments, the final artefact focused more on the preceding steps towards building the business case, than the business case self. These activities came up during the expert interviews, but were not part of the literature review. This include for amongst others the readiness assessment and the selection of cloud applications. The additional tools are provided to fill in this gap, but these are not all scientific ones. So while the framework will be beneficial in structuring the activities which need to be performed to evaluate cloud computing, it may not be very helpful when performing the activities. Another limitation is the extent to which the cloud governance research objective is achieved. The goal was to approach cloud governance in a broader way than security, as this was lacking in literature. This is just partly achieved. An important part of the final cloud governance artefact is about risks, namely the risk-reducing activities which must be performed. Based on the interviews, this is valuable. The main concern regarding cloud adoption still seems to be security and the high-level overview on cloud risks management is unique and therefore of scientific and practical relevance. However, a larger focus on other aspects than the risks, such as the service management processes, would probably have led to a better achievement of the research objective. With regards to the theoretical concepts discussed in this research, a point of discussion is the concept ‘Governance’, especially in the context of IT. A difficult aspect of this research was to get a grasp on what IT and Cloud governance entails. As was already noted in the section on corporate, IT and cloud governance, multiple perspectives exists. This makes it very hard determining what an author is referring to when governance is discussed. In scientific literature some refer to a decision making model, others to a system of processes or the 117
actions of the board. In whitepapers this concept is described in numerous other ways, including as management oversight or internal rules, such as enterprise goals. In more specific domains of for example Service Oriented Architecture, governance refers to operational aspects such as service policies or the usage of a repository. So which rules apply to call something governance, as opposed to control or management? In the most recent version of the COBIT framework (ISACA, 2012), ISACA tried to make a clear distinction between governance and management, based on the actors involved. On a board and executive level, governance actions are performed and include ‘Evaluate’, ‘Direct’ and ‘Monitor’ activities. Even with this distinction, it is still a complex concept. Executive management have governance responsibilities, but also plain management ones (that’s why they are called executive management). This made it difficult in this research to determine which activities are ‘governance’ and should therefore be part of the framework. In the first feedback phase on the framework, the CFO of a large Dutch bank, mentioned he is involved with selecting cloud providers. This is typically not seen as a governance activity. So even if ‘governance’ is scoped by the board and executive management, ambiguities arise. This discussion is alive and well on websites about IT Governance, such as IT Skeptic (“A review of”, 2013). Also, Haes et al., well-known publicists on the topic of IT Governance, have raised question marks (and future research opportunities) in their recent publication (Haes et al., 2013) regarding the role of the board and executive management in IT investments. A new set of terminologies would solve many of these problems. Why not call the decision making view on IT governance, an ‘IT decision making model’? And refer to the strategic management of security as what it entails, the strategic management of security? This would provide clarity in publications and on the responsibilities of different stakeholders in an organization. Other future research can be done on three aspects regarding cloud computing; security, organizational impact and governance. According to Rebollo et al. (2011), some security related concerns are not addressed yet. These are outlined in their paper. Not a lot of research was found on the organizational impact of cloud computing outside the IT department. This is could be due cloud computing being a relatively new technological and economic model. A case study spanning multiple years is probably needed to identify changes on people, culture and processes. On the topic of cloud governance, several aspects can and should be researched. First of all, the final cloud governance model in this research is based on a specific view on cloud governance and solely focused on the governance of a single solution. The ‘Evaluate, Direct and Monitor’ perspective was omitted after the first feedback round, as it was not applicable to all of the organizations of the interviewees. Still, this perspective of cloud governance
118
needs more research. For example, what is the role of executive management in enterprisewide cloud computing adoption? Second, the cloud governance model can be used as input for future research. This research addressed the processes which need to be implemented on a high-level. It would be beneficial to organizations to research the exact (service management) processes, including the division of responsibilities between providers and consumers. Not many papers were found researching the processes needed for cloud computing. A research such as performed by De Jong (2009) on the processes and responsibilities for outsourcing could be applied to offpremise cloud computing. Also, this cloud governance model can serve as input to compare the governance of cloud computing to that of outsourcing.
119
References A review of governance of IT. [Web log message]. (2013, December 12). Retrieved from http://www.itskeptic.org/content/review-governance-it A Guide to Implementing Cloud Services. (2012). Retrieved from AGIMO website: http://www.finance.gov.au/files/2012/09/a-guide-to-implementing-cloud-services.pdf Ahmad, R., & Janczewski, L. (2011). Governance Life Cycle Framework for Managing Security in Public Cloud: From User Perspective. In 2011 IEEE International Conference on Cloud Computing (CLOUD) (pp. 372–379). doi:10.1109/CLOUD.2011.117 Aljabre A, (2012). Cloud Computing for Increased Business Value. International Journal of Business and Social Science vol. 3. Almorsy, M., Grundy, J., & Ibrahim, A. S. (2011). Collaboration-Based Cloud Computing Security Management Framework. In 2011 IEEE International Conference on Cloud Computing (CLOUD) (pp. 364–371). Presented by 2011 IEEE International Conference on Cloud Computing (CLOUD). doi:10.1109/CLOUD.2011.9 Arlotta, CJ. (2013). CIOs Say Cost Reduction Potential Drives Cloud Adoption. Retrieved on March, 2013 on http://mspmentor.net/cloud-computing/cios-say-cost-reductionpotential-drives-cloud-adoption Asay, M. (2013, December 31). Cloud computing: Not nearly hyped enough.TechRepublic. Retrieved January 24, 2014, from http://www.techrepublic.com/blog/the-enterprisecloud/cloud-computing-not-nearly-hyped-enough/ Baars, T., & Spruit, M. (2012). Designing a Secure Cloud Architecture: The SeCA Model. International Journal of Information Security and Privacy, 6(1), 14–32. doi:10.4018/jisp.2012010102 Babcock, C. (2012, February 02). Cloud success stories. Retrieved from http://www.informationweek.com/cloud-success-stories/d/d-id/1102626 Babić, V. (2010). Corporate Governance in Transition Economies. Теме, 34, pp. 555-568. Badger, L., Grance, T., Patt-Corner, R., & Voas, J. (2011). DRAFT Cloud Computing Synopsis and Recommendations. U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Patrick D. Gallagher, Director. Retrieved from http://csrc.nist.gov/publications/drafts/800-146/Draft-NISTSP800-146.pdf Baliga, J., Ayre, R. W. A., Hinton, K., & Tucker, R. S. (2011). Green Cloud Computing: Balancing Energy in Processing, Storage, and Transport. Proceedings of the IEEE, 99(1), 149 –167. doi:10.1109/JPROC.2010.2060451 Bamiah, M. (z.d.). Challenges and Benefits for Adopting the Paradigm of Cloud Computing. Retrieved 23 januari 2014, van 120
http://www.academia.edu/1383792/Challenges_and_Benefits_for_Adopting_the_Para digm_of_Cloud_Computing Behl, A., & Behl, K. (2012). An analysis of cloud computing security issues. In 2012 World Congress on Information and Communication Technologies (WICT) (pp. 109–114). Presented by 2012 World Congress on Information and Communication Technologies (WICT). doi:10.1109/WICT.2012.6409059 Benson, V., & Morgan, S. (2013). Student Experience and Ubiquitous Learning in Higher Education: Impact of Wireless and Cloud Applications. Creative Education, 04(08), 1–5. doi:10.4236/ce.2013.48A001 Beserra, P. V., Camara, A., Ximenes, R., Albuquerque, A. B., & Mendonca, N. C. (Sept.). Cloudstep: A step-by-step decision process to support legacy application migration to the cloud. In Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA), 2012 IEEE 6th International Workshop on the (pp. 7–16). Presented by Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA), 2012 IEEE 6th International Workshop on the. doi:10.1109/MESOCA.2012.6392602 Bhadauria, R., Chaki, R., Chaki, N., & Sanyal, S. (2011). A Survey on Security Issues in Cloud Computing. arXiv:1109.5388. Retrieved from http://arxiv.org/abs/1109.5388 Bhardwaj, S., Jain, L., & Jain, S. (2010). An Approach for Investigating Perspective of Cloud Software-as-a-Service (SaaS). International Journal of Computer Applications, 10(2), 44–47. doi:10.5120/1450-1962 Bird, F. (2001). Good Governance: A Philosophical Discussion of the Responsibilities and Practices of Organizational Governors. Canadian Journal of Administrative Sciences / Revue Canadienne Des Sciences de l’Administration, 18(4), 298–312. doi:10.1111/j.1936-4490.2001.tb00265.x Birla, A., & Sinha, R. (2011). Cloud computing and its impact on itsm adoption. Infosys Labs Briefings, 9(5), Retrieved from http://www.infosys.com/infosyslabs/publications/Documents/infrastructure-management/cloud-computing.pdf Bisong, A., Syed, & Rahman, M. (2011). An Overview of the Security Concerns in Enterprise Cloud Computing. arXiv:1101.5613. doi:10.5121/ijnsa.2011.3103 Böhm, M., Leimeister, S., Riedl, C., & Krcmar, H. (2011). Cloud Computing – Outsourcing 2.0 or a new Business Model for IT Provisioning? In F. Keuper, C. Oecking, & A. Degenhardt (Red.), Application Management (pp. 31–56). Gabler. Retrieved from http://link.springer.com.proxy.library.uu.nl/chapter/10.1007/978-3-8349-6492-2_2 Bradshaw, S., Millard, C., & Walden, I. (2011). Contracts for Clouds: Comparison and Analysis of the Terms and Conditions of Cloud Computing Services (SSRN Scholarly Paper No. ID 1662374). Rochester, NY: Social Science Research Network. Retrieved from http://papers.ssrn.com/abstract=1662374 Brodkin, J. (2008, July 02). Gartner: Seven cloud-computing security risks. Retrieved from http://www.networkworld.com/news/2008/070208-cloud.html 121
Brohi, S.N. & Bamiah, M.A. (2011). Challenges and Benefits for Adoption the Paradigm of Cloud Bruszewski, R. (2011). Capturing the cloud, defining the business case. Retrieved from: http://www.nacubo.org/Documents/Business_Topics/Business_Case_Final.pdf Carroll, M., Van der Merwe, A., & Kotze, P. (2011). Secure cloud computing: Benefits, risks and controls. In Information Security South Africa (ISSA), 2011 (pp. 1 –9). Presented by Information Security South Africa (ISSA), 2011. doi:10.1109/ISSA.2011.6027519 Chang, W., Leung, E., Pili, H. (2012). Enterprise risk management for cloud computing. Retrieved from http://www.coso.org/documents/Cloud%20Computing%20Thought%20Paper.pdf Chaput, S. R., & Ringwood, K. (2010). Cloud Compliance: A Framework for Using Cloud Computing in a Regulated World. In N. Antonopoulos & L. Gillam (Red.), Cloud Computing (pp. 241–255). Springer London. Retrieved from http://link.springer.com.proxy.library.uu.nl/chapter/10.1007/978-1-84996-241-4_14 Chen, Z., & Yoon, J. (2010). IT Auditing to Assure a Secure Cloud Computing. In Proceedings of the 2010 6th World Congress on Services (pp. 253–259). Washington, DC, USA: IEEE Computer Society. doi:10.1109/SERVICES.2010.118 Cloud Security Alliance. (2011). Security Guidance for critiqueal areas of focus in Cloud Computing V2. 1. CSA (Cloud Security Alliance), USA. Online: http://www. cloudsecurityalliance. org/guidance/csaguide. v2, 1. Computing. International Journal of Advanced Engineering Sciences and Technology, 8(2), pp. 286/290 Conway, G. & Curry, E. (2012). Managing cloud computing: a life cycle approach. In Proc. 2nd International Conference on Cloud Computing and Services Science. Porto D'Addario, J. (2013, July 09). What cfos don't know: Top cloud myths . Retrieved from http://businessfinancemag.com/technology/what-cfos-dont-know-top-cloudmyths?page=3 Dahbur, K., Mohammad, B., & Tarakji, A. B. (2011). A survey of risks, threats and vulnerabilities in cloud computing. In Proceedings of the 2011 International Conference on Intelligent Semantic Web-Services and Applications (pp. 12:1–12:6). New York, NY, USA: ACM. doi:10.1145/1980822.1980834 De business case voor cloud computing. (n.d.). Retrieved from website: http://www.kennisnet.nl/fileadmin/contentelementen/kennisnet/Dossier_Cloud/cloudcomputing-businesscase-weloverwogen.pdf De Haes, S., & Van Grembergen, W. (2005). IT Governance Structures, Processes and Relational Mechanisms: Achieving IT/Business Alignment in a Major Belgian Financial Group. In Proceedings of the 38th Annual Hawaii International Conference on System Sciences, 2005. HICSS ’05 (p. 237b–237b). doi:10.1109/HICSS.2005.362
122
De Haes, S., Van Grembergen, W., & Debreceny, R. S. (2013). COBIT 5 and Enterprise Governance of Information Technology: Building Blocks and Research Opportunities. Journal of Information Systems, 27(1), 307–324. doi:10.2308/isys-50422 De Jong, F. (2009) The Right Governance Framework for Managing an Offshore IT Outsourcing Relationship: the Shell Case. Universiteit Twente retrieved on 18 september 2013 from http://essay.utwente.nl/58708/1/floor_de_jong_shell_thesis_v41.pdf Dhar, S. (2011). From outsourcing to Cloud computing: Evolution of IT services. In Technology Management Conference (ITMC), 2011 IEEE International (pp. 434– 438). doi:10.1109/ITMC.2011.5996009 Dibra, R. (2012). Corporate Governance In Transition Economies- Comparative Analysis Of Contemporary Corporate Governance Issues In Selected Of This Economies In SouthEastern Europe. The Albanian Case. European Journal of Business and Economics, 7(0). doi:10.12955/ejbe.v7i0.130 Dikaiakos, M. D., Katsaros, D., Mehra, P., Pallis, G., & Vakali, A. (2009). Cloud Computing: Distributed Internet Computing for IT and Scientific Research. IEEE Internet Computing, 13(5), 10–13. doi:10.1109/MIC.2009.103 EMC Readiness. (n.d.). EMC Readiness. Retrieved January 24, 2014, from http://cloudflightcheck.com/ ENISA. (2009, december 28). Cloud Computing - Benefits, risks and recommendations for information security. Http://www.enisa.europa.eu. Retrieved februari 5, 2013, van http://www.anacom.pt/render.jsp?contentId=1000130 Erbes, J., Motahari Nezhad, H. R., & Graupner, S. (2012). The Future of Enterprise IT in the Cloud. Computer, 45(5), 66–72. doi:10.1109/MC.2012.73 Fan, C. K., Chiang, C.-M. F., & Kao, T. L. (2012). Risk Management Strategies for the Use of Cloud Computing. International Journal of Computer Network and Information Security(IJCNIS), 4(12), 50. Firdhous, M., Ghazali, O., & Hassan, S. (2012). A Memoryless Trust Computing Mechanism for Cloud Computing. In R. Benlamri (Red.), Networked Digital Technologies (pp. 174–185). Springer Berlin Heidelberg. Retrieved from http://link.springer.com.proxy.library.uu.nl/chapter/10.1007/978-3-642-30507-8_16 Géczy, P., Izumi, N., & Hasida, K. (2011). Cloudsourcing: Managing Cloud Adoption (SSRN Scholarly Paper No. ID 1945858). Rochester, NY: Social Science Research Network. Retrieved from http://papers.ssrn.com/abstract=1945858 Gillan, S. L., & Starks, L. T. (2000). Corporate governance proposals and shareholder activism: the role of institutional investors. Journal of Financial Economics, 57(2), 275–305. doi:10.1016/S0304-405X(00)00058-1
123
Gomes, R., & Ribeiro, J. (2009). THE MAIN BENEFITS OF COBIT IN A HIGH PUBLIC EDUCATIONAL INSTITUTION - A CASE STUDY. PACIS 2009 Proceedings. Retrieved from http://aisel.aisnet.org/pacis2009/88 Grembergen, W. V., & Haes, S. D. (2004). IT governance mechanismen: Cobit en de balanced scorecard. Kluwer. Guo, Z., Song, M., & Song, J. (2010). A Governance Model for Cloud Computing. In 2010 International Conference on Management and Service Science (MASS) (pp. 1–6). doi:10.1109/ICMSS.2010.5576281 Guo, Z., Song, M., & Song, J. (Aug.). A Governance Model for Cloud Computing. In 2010 International Conference on Management and Service Science (MASS) (pp. 1–6). Presented by 2010 International Conference on Management and Service Science (MASS). doi:10.1109/ICMSS.2010.5576281 Halpert, B. (2011). Auditing Cloud Computing: A Security and Privacy Guide. John Wiley & Sons. He, Y. (2011). The lifecycle process model for cloud governance. info:eurepo/semantics/masterThesis. Retrieved 23 januari 2014, van http://essay.utwente.nl/61131/ Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. MIS Q., 28(1), 75–105. Hon, W. K., Millard, C., & Walden, I. (2012). Negotiating Cloud Contracts - Looking at Clouds from Both Sides Now (SSRN Scholarly Paper No. ID 2055199). Rochester, NY: Social Science Research Network. Retrieved from http://papers.ssrn.com/abstract=2055199 Huang, C.-C., & Hsieh, C.-C. (2011). Does Cloud Computing Matter? Networking IT and Services Value in Organizations (pp. 75–80). Presented by ICN 2011, The Tenth International Conference on Networks. Retrieved from http://www.thinkmind.org/index.php?view=article&articleid=icn_2011_4_20_10230 ISACA. (2011) IT Control Objectives for Cloud Computing. ISACA. Retrieved from http://www.isaca.org/KnowledgeCenter/Research/Documents/ITCO_Cloud_SAMPLE_E-book_20July2011.pdf ISACA. (2012).COBIT 5: A Business Framework for the Governance and Management of Enterprise IT. Rolling Meadows, IL: ISACA. ISO/IEC. (2008). ISO/IEC 38500 Corporate Governance of Information Technology. Geneva, Switzerland: International Organization for Standardization/International Electrotechnical Commission. ITGIT. (2006). Board briefing on IT governance. Retrieved from http://www.isaca.org/Knowledge-
124
Center/Research/ResearchDeliverables/Pages/Board-Briefing-on-IT-Governance-2ndEdition.aspx ITGIT. (2008). Enterprise Value: Governance of IT Investments, The Val IT Framework. The IT Governance Institute. Jansen, M. (2011). What Does It Service Management Look Like in the: An ITIL Based Approach. In Proceedings of the 2011 International Conference on Applied, Numerical and Computational Mathematics, and Proceedings of the 2011 International Conference on Computers, Digital Communications and Computing (pp. 87–92). Stevens Point, Wisconsin, USA: World Scientific and Engineering Academy and Society (WSEAS). Retrieved from http://dl.acm.org/citation.cfm?id=2047950.2047964 Jericho Forum. (2009). Cloud Cube Model: Selecting Cloud Formations for Secure Collaboration. Jericho Forum. Retrieved from http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf Jin, H., Ibrahim, S., Bell, T., Gao, W., Huang, D., & Wu, S. (2010). Cloud Types and Services. In B. Furht & A. Escalante (Red.), Handbook of Cloud Computing (pp. 335– 355). Springer US. Retrieved from http://link.springer.com.proxy.library.uu.nl/chapter/10.1007/978-1-4419-6524-0_14 John, K., & Senbet, L. W. (1998). Corporate governance and board effectiveness. Journal of Banking & Finance, 22(4), 371–403. doi:10.1016/S0378-4266(98)00005-3 Julisch, K., & Hall, M. (2010). Security and Control in the Cloud. Information Security Journal: A Global Perspective, 19(6), 299–309. doi:10.1080/19393555.2010.514654 Kaliski,Jr., B. S., & Pauley, W. (2010). Toward risk assessment as a service in cloud environments. In Proceedings of the 2nd USENIX conference on Hot topics in cloud computing (pp. 13–13). Berkeley, CA, USA: USENIX Association. Retrieved from http://dl.acm.org/citation.cfm?id=1863103.1863116 Khajeh-Hosseini, A., Greenwood, D., & Sommerville, I. (2010). Cloud Migration: A Case Study of Migrating an Enterprise IT System to IaaS. arXiv:1002.3492 [cs]. Retrieved from http://arxiv.org/abs/1002.3492 Khajeh-Hosseini, A., Sommerville, I., Bogaerts, J., & Teregowda, P. (2011). Decision Support Tools for Cloud Migration in the Enterprise. In 2011 IEEE International Conference on Cloud Computing (CLOUD) (pp. 541 –548). Presented by 2011 IEEE International Conference on Cloud Computing (CLOUD). doi:10.1109/CLOUD.2011.59 Khajeh-Hosseini, Ali, Greenwood, D., Smith, J. W., & Sommerville, I. (2012). The Cloud Adoption Toolkit: supporting cloud adoption decisions in the enterprise. Software: Practice and Experience, 42(4), 447–465. doi:10.1002/spe.1072 Khajeh-Hosseini, Ali, Sommerville, I., & Sriram, I. (2010). Research Challenges for Enterprise Cloud Computing. arXiv:1001.3257. Retrieved from http://arxiv.org/abs/1001.3257 125
Klems, M., Nimis, J., & Tai, S. (2009). Do Clouds Compute? A Framework for Estimating the Value of Cloud Computing. In C. Weinhardt, S. Luckner, & J. Stößer (red.), Designing E-Business Systems. Markets, Services, and Networks (pp. 110–123). Springer Berlin Heidelberg. Retrieved from http://link.springer.com.proxy.library.uu.nl/chapter/10.1007/978-3-642-01256-3_10 Kornevs, M., Minkevica, V., & Holm, M. (2012). Cloud Computing Evaluation Based on Financial Metrics. Information Technology and Management Science, 15(1), 87–92. Lew, D. (2013). COBIT 5: A globally accepted business framework for the governance and management of enterprise IT [PRESENTATION]. Retrieved from: http://isacadenver.org/Chapter-Resources/ISACADenverCOBIT5Overview.pdf Li, X., Li, Y., Liu, T., Qiu, J., & Wang, F. (2009). The Method and Tool of Cost Analysis for Cloud Computing. In IEEE International Conference on Cloud Computing, 2009. CLOUD ’09 (pp. 93 –100). Presented by IEEE International Conference on Cloud Computing, 2009. CLOUD ’09. doi:10.1109/CLOUD.2009.84 Linthicum, D. S. (2009). Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide. Pearson Education. Loebbecke, C., Thomas, B., & Ullrich, T. (2011). Assessing Cloud Readiness: Introducing the Magic Matrices Method Used by Continental AG. In M. Nüttgens, A. Gadatsch, K. Kautz, I. Schirmer, & N. Blinn (Red.), Governance and Sustainability in Information Systems. Managing the Transfer and Diffusion of IT (pp. 270–281). Springer Berlin Heidelberg. Retrieved from http://link.springer.com.proxy.library.uu.nl/chapter/10.1007/978-3-642-24148-2_18 Luna Garcia, J., Langenberg, R., & Suri, N. (2012). Benchmarking cloud security level agreements using quantitative policy trees. In Proceedings of the 2012 ACM Workshop on Cloud computing security workshop (pp. 103–112). New York, NY, USA: ACM. doi:10.1145/2381913.2381932 M.Ezzat, E., S. Elzanfaly, D., & A. Mostafa, M. (2012). Fly Over the Clouds or Drive Through the Crowd: A Cloud Adoption Framework in Action. International Journal of Computer Applications, 56(4), 1–8. doi:10.5120/8876-2856 Maches, B. (2010, January 25). The impact of cloud computing on corporate it governance. Retrieved from http://archive.hpcwire.com/hpcwire/2010-0125/the_impact_of_cloud_computing_on_corporate_it_governance.html Marston, S., Li, Z., Bandyopadhyay, S., Zhang, J., & Ghalsasi, A. (2011). Cloud computing — The business perspective. Decision Support Systems, 51(1), 176–189. doi:10.1016/j.dss.2010.12.006 Martens, B., Walterbusch, M., & Teuteberg, F. (2012). Costing of Cloud Computing Services: A Total Cost of Ownership Approach. In 2012 45th Hawaii International Conference on System Science (HICSS) (pp. 1563 –1572). Presented by 2012 45th Hawaii International Conference on System Science (HICSS). doi:10.1109/HICSS.2012.186
126
Martens, Benedikt, & Teuteberg, F. (2011). Risk and Compliance Management for Cloud Computing Services: Designing a Reference Model. AMCIS 2011 Proceedings - All Submissions. Retrieved from http://aisel.aisnet.org/amcis2011_submissions/228 Martens, Benedikt, & Teuteberg, F. (2012). Decision-making in cloud computing environments: A cost and risk based approach. Information Systems Frontiers, 14(4), 871–893. doi:10.1007/s10796-011-9317-x Mather, T., Kumaraswamy, S., & Latif, S. (2009). Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance. O’Reilly Media, Inc. Maurya, B. K. (2010, mei 11). Cloud Computing: Exploring the scope. Report. Retrieved februari 25, 2013, van http://eprints.rclis.org/14562/ Meckendrik, J. (2013). 10 Quotes on Cloud Computing That Really Say it All. Retrieved on 5 October 2013 from http://www.forbes.com/sites/joemckendrick/2013/03/24/10quotes-on-cloud-computing-that-really-say-it-all/ Mell, P. & Grance, T. (2011). The NIST Definition of Cloud Computing (800-145). National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) . Misra, S. C., & Mondal, A. (2011). Identification of a company’s suitability for the adoption of cloud computing and modelling its corresponding Return on Investment. Mathematical and Computer Modelling, 53(3–4), 504–521. doi:10.1016/j.mcm.2010.03.037 Morgan, L., & Conboy, K. (2013). Factors affecting the adoption of cloud computing: an exploratory study. Retrieved from http://ulir.ul.ie/handle/10344/3209 Moyle, E. (2012). Information security, compliance and the cloud [Whitepaper]. Retrieved from http://docs.media.bitpipe.com/io_10x/io_108495/item_644882/Risk%20Management %20for%20Cloud%20Computing_hb_final.pdf Paquette, S., Jaeger, P. T., & Wilson, S. C. (2010). Identifying the security risks associated with governmental use of cloud computing. Government Information Quarterly, 27(3), 245–253. doi:10.1016/j.giq.2010.01.002 Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, 24(3), 45–77. doi:10.2753/MIS0742-1222240302 PwC. (2013, July 09). Security is just one of several barriers to cloud adoption. Retrieved from http://www.pwc.com/gx/en/technology/cloud-computing/index.jhtml Rabai, L. B. A., Jouini, M., Aissa, A. B., & Mili, A. (2013). A cybersecurity model in cloud computing environments. Journal of King Saud University - Computer and Information Sciences, 25(1), 63–75. doi:10.1016/j.jksuci.2012.06.002
127
Racz, N., Weippl, E., & Seufert, A. (2011). Integrating IT Governance, Risk, and Compliance Management Processes. In Proceedings of the 2011 conference on Databases and Information Systems VI: Selected Papers from the Ninth International Baltic Conference, DB&IS 2010 (pp. 325–338). Amsterdam, The Netherlands, The Netherlands: IOS Press. Retrieved from http://dl.acm.org/citation.cfm?id=1940590.1940621 Raines, G., & Pizette, L. (2010). A Decision Process for Applying Cloud Computing in Federal Environments. Retrieved from: http://www.mitre.org/sites/default/files/pdf/cloud_federal_environments.pdf Rashmi, Mehfuz, S. & Sahoo, G. (2012). A five phased approach for the cloud migration. International Journal of Emerging Technology and Advanced Engineering (IJETAE), Rashmi. , Mehfuz, S., & Sahoo, G. (2012). A five-phased approach for the cloud migration. The International Journal of Emerging Technology and Advanced Engineering, 2(4), Retrieved from http://www.ijetae.com/files/Volume2Issue4/IJETAE_0412_48.pdf Rebollo, O., Mellado, D., & Fernández-Medina, E. (2012). A Systematic Review of Information Security Governance Frameworks in the Cloud Computing Environment. J. UCS, 18(6), 798–815. Rebollo, O., Sánchez, Daniel Mellado, L. E., & Fernández-Medina, E. (2011). Comparative Analysis of Information Security Governance Frameworks: A Public Sector Approach. In The Proceedings of the 11th European Conference on eGovernment (pp. 482–490). Remenyi, D., & Sherwood-Smith, M. (2012). IT Investment: Making a Business Case. Routledge. Remmé, M. (2010). Governance and the cloud [Whitepaper]. Retrieved from http://www2.getronics.nl/orchestrate/tl_files/Getronics_whitepaper_Governance_and_ the_Cloud_UK.pdf Ribeiro, R. (2013, April 17). The NYSE community cloud success story points to another cloud model. Retrieved from http://www.biztechmagazine.com/article/2013/04/nysecommunity-cloud-success-story-points-another-cloud-model Rings, T., Caryer, G., Gallop, J., Grabowski, J., Kovacikova, T., Schulz, S., & Stokes-Rees, I. (2009). Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network. Journal of Grid Computing, 7(3), 375–393. doi:10.1007/s10723009-9132-5 Ross, J. W., & Weill, P. (2005). A matrixed approach to designind it governance. MIT Sloan management review, 46(2), 26–34. Sahibudin, S., Sharifi, M., & Ayat, M. (2008). Combining ITIL, COBIT and ISO/IEC 27002 in Order to Design a Comprehensive IT Framework in Organizations. In Second Asia International Conference on Modeling Simulation, 2008. AICMS 08 (pp. 749–753). doi:10.1109/AMS.2008.145 128
Salleras, G. (2013). The impact of Cloud Computing adoption on IT Service Accounting approaches – A Customer Perspective on IaaS Pricing Models. Retrieved from http://upcommons.upc.edu/pfc/handle/2099.1/18068 Saripalli, P., & Walters, B. (2010). QUIRC: A Quantitative Impact and Risk Assessment Framework for Cloud Security. In 2010 IEEE 3rd International Conference on Cloud Computing (CLOUD) (pp. 280–288). Presented by 2010 IEEE 3rd International Conference on Cloud Computing (CLOUD). doi:10.1109/CLOUD.2010.22 Sarkar, P., & Young, L. (2011). SAILING THE CLOUD: A CASE STUDY OF PERCEPTIONS AND CHANGING ROLES IN AN AUSTRALIAN UNIVERSITY. ECIS 2011 Proceedings. Retrieved from http://aisel.aisnet.org/ecis2011/124 Savvas, A. (2011). Cloud deployments blocked by execs over privacy concerns. Retrieved 18 oktober 2013, van http://www.computerworlduk.com/news/cloudcomputing/3257521/cloud-deployments-blocked-by-execs-over-privacy-concerns/ Schepers, T. (2007). A Lifecycle Method for Service Oriented Architecture Governance. University of Twente, Enschede. Sengupta, S., Kaulgud, V., & Sharma, V. S. (2011). Cloud Computing Security–Trends and Research Directions. In 2011 IEEE World Congress on Services (SERVICES) (pp. 524 –531). Presented by 2011 IEEE World Congress on Services (SERVICES). doi:10.1109/SERVICES.2011.20 Shaikh, F. B., & Haider, S. (Dec.). Security threats in cloud computing. In Internet Technology and Secured Transactions (ICITST), 2011 International Conference for (pp. 214–219). Presented by Internet Technology and Secured Transactions (ICITST), 2011 International Conference for. Shimba, F. (2010). Cloud Computing:Strategies for Cloud Computing Adoption. Dissertations. Retrieved from http://arrow.dit.ie/scschcomdis/29 Simonsson, M., & Johnson, P. (2006). Defining IT governance-a consolidation of literature. In 18th Conference on Advanced Information Systems Engineering (CAISE). Speed, R. (2011). It governance and the cloud: Principles and practice for governing adoption of cloud computing. ISACA Journal, 5(2011), Retrieved from http://www.isaca.org/Journal/Past-Issues/2011/Volume-5/Pages/IT-Governance-andthe-Cloud-Principles-and-Practice-for-Governing-Adoption-of-Cloud-Computing.aspx Srinivasan, M. K., Sarukesi, K., Rodrigues, P., Manoj, M. S., & Revathy, P. (2012). State-ofthe-art cloud computing security taxonomies: a classification of security challenges in the present cloud computing environment. In Proceedings of the International Conference on Advances in Computing, Communications and Informatics (pp. 470– 476). New York, NY, USA: ACM. doi:10.1145/2345396.2345474 Subashini, S., & Kavitha, V. (2011). A survey on security issues in service delivery models of cloud computing. Journal of Network and Computer Applications, 34(1), 1–11. doi:10.1016/j.jnca.2010.07.006
129
Sultan, N., & Van de Bunt-Kokhuis, S. (2012). Organisational culture and cloud computing: coping with a disruptive innovation. Technology Analysis & Strategic Management, 24(2), 167–179. doi:10.1080/09537325.2012.647644 Talukder, A. K., Zimmerman, L., & A, P. H. (2010). Cloud Economics: Principles, Costs, and Benefits. In N. Antonopoulos & L. Gillam (Red.), Cloud Computing (pp. 343–360). Springer London. Retrieved from http://link.springer.com.proxy.library.uu.nl/chapter/10.1007/978-1-84996-241-4_20 Tanimoto, S., Hiramoto, M., Iwashita, M., Sato, H., & Kanai, A. (2011). Risk Management on the Security Problem in Cloud Computing. In 2011 First ACIS/JNU International Conference on Computers, Networks, Systems and Industrial Engineering (CNSI) (pp. 147 –152). Presented by 2011 First ACIS/JNU International Conference on Computers, Networks, Systems and Industrial Engineering (CNSI). doi:10.1109/CNSI.2011.82 Troshani, I., Rampersad, G., & Wickramasinghe, N. (2011). Cloud Nine? An Integrative Risk Management Framework for Cloud Computing. BLED 2011 Proceedings. Retrieved from http://aisel.aisnet.org/bled2011/38 Vaquero, L. M., Rodero-Merino, L., Caceres, J., & Lindner, M. (2008). A break in the clouds: towards a cloud definition. SIGCOMM Comput. Commun. Rev., 39(1), 50–55. doi:10.1145/1496091.1496100 Wahlgren, G., & Kowalski, S. (2013). IT Security Risk Management Model for Cloud Computing: A Need for a New Escalation Approach (pp. 56–68). Presented by The International Conference on Digital Information Processing, E-Business and Cloud Computing (DIPECC2013), The Society of Digital Information and Wireless Communication. Retrieved from http://sdiwc.net/digital-library/it-security-riskmanagement-model-for-cloud-computing-a-need-for-a-new-escalation-approach Wang, C., Ren, K., & Wang, J. (2011). Secure and practical outsourcing of linear programming in cloud computing. In 2011 Proceedings IEEE INFOCOM (pp. 820– 828). doi:10.1109/INFCOM.2011.5935305 Webb, P., Pollard, C., & Ridley, G. (2006). Attempting to Define IT Governance: Wisdom or Folly? In Proceedings of the 39th Annual Hawaii International Conference on System Sciences - Volume 08 (p. 194.1–). Washington, DC, USA: IEEE Computer Society. doi:10.1109/HICSS.2006.68 Webster, J., & Watson, R. T. (2002). Analyzing the Past to Prepare for the Future: Writing a Literature Review. MIS Q., 26(2), xiii–xxiii. Weill, P., & Ross, J. W. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business Press. Wijers, G., & Verhoef, D. et al. (2009). IT Outsourcing Part 1: Contracting the Partner A Management Guide. Van Haren Publishing. Willcocks, L., Venters, W., & Whitley, E. (2012). Cloud Sourcing: Implications for Managing the IT Function. In J. Kotlarsky, I. Oshri, & L. P. Willcocks (Red.), The Dynamics of 130
Global Sourcing. Perspectives and Practices (pp. 142–163). Springer Berlin Heidelberg. Retrieved from http://link.springer.com.proxy.library.uu.nl/chapter/10.1007/978-3-642-33920-2_9 Wittenberger, M. (2013, July 13). Why are very small businesses leaders in cloud adoption?. Retrieved from http://smallbiz.carbonite.com/articles/bid/316748/Why-Are-VerySmall-Businesses-Leaders-In-Cloud-Adoption Wu, Z., & Gan, A. (2011). Qualitative and Quantitative Analysis the Value of Cloud Computing. In 2011 International Conference on Information Management, Innovation Management and Industrial Engineering (ICIII) (Vol. 2, pp. 518 –521). Presented by 2011 International Conference on Information Management, Innovation Management and Industrial Engineering (ICIII). doi:10.1109/ICIII.2011.270 Xie, Z. (2011). Economic Perspectives of Cloud Computing. In Proceedings of the 2011 Fourth IEEE International Conference on Utility and Cloud Computing (pp. 312– 319). Washington, DC, USA: IEEE Computer Society. doi:10.1109/UCC.2011.50 Yam, C.-Y., Baldwin, A., Shiu, S., & Ioannidis, C. (2011). Migration to Cloud as Real Option: Investment Decision under Uncertainty. In 2011 IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom) (pp. 940 –949). Presented by 2011 IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). doi:10.1109/TrustCom.2011.130 Yang, J., & Chen, Z. (Dec.). Cloud Computing Research and Security Issues. In 2010 International Conference on Computational Intelligence and Software Engineering (CiSE) (pp. 1–3). Presented by 2010 International Conference on Computational Intelligence and Software Engineering (CiSE). doi:10.1109/CISE.2010.5677076 Yanosky, R. (2008). From Users to Choosers: The Cloud and the Changing Shape of Enterprise Authority. In R. N. Katz (Red.), The Tower and The Cloud (pp. 126–136). Campanile, University of California, Berkeley: Educause E-Book. Retrieved from http://net.educause.edu/ir/library/pdf/PUB7202m.pdf You, P., Peng, Y., Liu, W., & Xue, S. (June). Security Issues and Solutions in Cloud Computing. In 2012 32nd International Conference on Distributed Computing Systems Workshops (ICDCSW) (pp. 573–577). Presented by 2012 32nd International Conference on Distributed Computing Systems Workshops (ICDCSW). doi:10.1109/ICDCSW.2012.20 Zabalza, J., Rio-Belver, R., Cilleruelo, E., Garechana, G., & Gavilanes, J. (2012). Benefits Related to Cloud Computing in the SMEs. 6th International Conference on Industrial Engineering and Industrial Management, 637–644. Zhang, Q., Cheng, L., & Boutaba, R. (2010). Cloud computing: state-of-the-art and research challenges. Journal of Internet Services and Applications, 1(1), 7–18. doi:10.1007/s13174-010-0007-6 Zhang, Y., & Wildemuth, B. M. (2009). Qualitative analysis of content. Applications of social research methods to questions in information and library science, 308–319. 131
Zissis, D., & Lekkas, D. (2012). Addressing cloud computing security issues. Future Generation Computer Systems, 28(3), 583–592. doi:10.1016/j.future.2010.12.006
132
Appendix A: risk-reducing controls Category SlA and provider requirements
Adoption phase
Plan /Architect (Conway and Curry, 2012)
Risk control Effective privacy controls(Carroll et al., 2011) Obey to local privacy requirements and processing (Chang et al., 2012). Location of data and compliance (Chang et al., 2012). Are transparent about security controls (Carroll et al., 2011) and data operations (Badger et al., 2011). The level of these controls should fit with the risk appetite of the consuming organization (Chang et al., 2012). The employees of provider should have adequate skills for managing security breaches (Carroll et al., 2011). The provider should inform about people who manage and access the organizations data and who hires administrators and how (Brodkin, 2008). Security control responsibilities might be shared and should be made clear in the SLA with regards to patching, control and access over encryption, standards and key management (Carroll et al., 2011) and other issues with regards to implementation, technology operations and user access administration (Chang et al., 2012). Agreement should be made about the reporting structure of incidents and its control mechanisms all the way to the CIO and CEO (Chen & Yoon, 2010). SLA agreement should clearly state the data is owned by the consuming organization (Chen & Yoon, 2010). SLA should state the cloud provider is obligated to provide auditable records of changes made to cloud data or should provide prove that no unauthorized changes occurred (Carroll et al., 2011). A mechanism should also be offered for reliably deleting subscriber data on request as well as providing evidence that the data was deleted (Badger et al., 2011). The provider should be willing to be subjected to external audits and security certifications (Badger et al., 2011). The cloud provider support adequate interoperability standards (Carroll et al., 2011) Data will remain available when they go out of business (Brodkin, 2008).
133
SLA and provider evaluation & negotiation
Engage (Conway and Curry,2 012)
network limitations of the organization should be determined before moving to the cloud (Carroll et al., 2011). The current applications should be benchmarked and key performance score requirements should be established before deploying the applications in the cloud (Chang et al., 2012). The desired performance and availability of the application should be stated in the SLA (Badger et al., 2011). Cloud service provider is open to external audits and security certifications and that logs ensuring compliance are available (Carrol, 2011). Providers should prove that the data is only stored in the geographic locations specified in the SLA or another contract (Carroll et al., 2011). Data protection law compliance will be achieved by storing data in this location (Chang et al., 2012). The providers adhere to requirements specific to the data location, comply with regional laws and regulations and that the laws and regulations are formally incorporated and documented in governance policies (Carroll et al., 2011). The SLA or other contracts should define the providers responsibilities regarding adhering to compliance and regulatory requirements on behalf of the organization (Chang et al., 2012). The continuity plan should support availability goals (Badger et al., 2011). Provider offers redundancy (placement of data in multiple data centers) (Badger et al., 2011) Evaluation provider and evaluate and negotiate SLA according to the states requirements. Also: Research which regulations and laws apply (e.g. patriot acts) to the stored data that can lead to data surrender, what information in this situation will be surrendered and about the options to avoid such surrenders (Chen & Yoon, 2010). The continuity plan should be evaluated whether the availability goals are supported (Badger et al., 2011).
134
Internal controls
Implement / Operational roll-out phase (Conway and Curry, 2012)
Availability plans
Implement / Operational roll-out phase (Conway and Curry, 2012)
Monitoring
Adopted / Manage supply Chain + refresh (Conway and Curry, 2012)
Data classifications
All
Policies
Governance project
outside
The appropriate security controls the consumer is responsible for should be implemented, including encrypting data hosted on cloud solutions to overcome cyber-attacks (Chang et al., 2012) and securing mobile devices that are connected to the services (Carroll et al., 2011). Insure against data leakage (Tanimoto et al., 2011). Security management process must be implemented, including acces control, incident response and monitoring of system use and acces (Mather, 2009). An exit strategy or contingency plan should be developed (Chang et al., 2012). When using a IaaS service, a strategy for the migration of Virtual Machines and their associated storage among alternative cloud providers should be formulated (Badger et al., 2011). A fail-over strategy should be developed. Another providers service solution or an internal solution should be used when services are not available (Chang et al., 2012). An insurance can be closed for a provider going out of business or the unavailability of services (Tanimoto et al., 2011). Security controls of the provider should be periodically verified for its effectiveness (Chang et al., 2012). Third party should check whether the SLA content is filled (Tanimoto et al., 2011) and should be requested to surveillance the movement of data when the provider is asked to remove the data (Tanimoto et al., 2011). System availability and performance should be monitored (Chang et al., 2012). Regulatory changes that would affect the consumers and the providers operations should be monitored (Chang et al., 2012). Data classification policies and processes should be in place to determine which data is appropriate to put in the cloud (Chang et al., 2012). Implement policies that clarifies the business process and data that is appropriate to be supported by cloud solutions, who procures cloud solutions and how to manage the relationship with
135
cloud providers (Chang et al., 2012)
136
Appendix B: interview protocol (development phase) In this research a framework, which can be called a governance framework, is developed which aims to assist top managed with the decisions and governance regarding cloud computing. Both security as other IT governance topics (strategic alignment, performance management etc) will be taken into account. The focus is on these three challenges:
The business case: how can it be developed for cloud computing? The organizational impact: what happens to the organization when cloud computing is adopted? Risks: what are the cloud related risks and how can they be managed? Cloud governance: what does entail?
Question 1) What is your function or what kind of work do you in relation to cloud computing? Question 2) Do you have experience with the three aspects that were mentioned? Question 3) How can a business case, according to you, be developed for cloud computing and what does it contain? Question 4) Is it developed for each specific service or application, or more in general as a ‘cloud computing program’ as can be seen with SOA projects? Question 5) Are the specific deployment and delivery models selected before building the base case? If not, are multiple business cases developed for each ‘cloud formation’? Question 6) What is the role of enterprise architecture when building a business case? Question 7) How can a solid IT strategy be supported when building the business case. Is a cloud road map developed before building the business case in order to select a cloud deployment, the delivery model and the service that will be moved onto the cloud? Question 9) What is the impact of cloud computing on the organization? Question 10) What are the effects on the corporate culture and the users and stakeholders of cloud computing? Question 11) Does the governance or organizational structure change? If so, is this dependent on the maturity of cloud computing or of the specific cloud models?
137
Question 11) And what about the processes policies. Which processes and policies need to be implemented to effective govern cloud computing? Is this dependent on the cloud maturity or cloud models? Question 15) What roles and responsibilities are important for cloud computing? Question 14) What are the main risks and how do they differ between the deployment and delivery models? Question 15) How can these risk be managed during and after adoption? How is risk and compliance management different with cloud computing? How can the risk management process be integrated into existing risk management frameworks? Question 16) How would you describe cloud governance and what is needed for an affective governance of cloud computing? Question 17) How is cloud computing related to SOA and how are SOA and cloud governance related? Question 18) Is it necessary or recommended to adopt SOA governance tools for cloud computing? Question 19) What should be included in a ‘Cloud governance framework’ to assist top management in governing cloud computing?
138
Appendix C: interview transcripts (development phase) Cloud infrastructure consultant [Expert 3] [Functie?] Ik werk binnen technologie advisory en wij houden ons bezig technische vraagstukken die de klant heeft ik zit bij It advisory binnen de cloud competentie groepje en houden ons bezig met ontwikkelen van cloud diensten en heb mijn scriptie binnen geschreven over cloud computing binnen hetzelfde team. Onze klanten zijn grote bedrijven zoals banken en overheidsinstellingen. Je zag al dat kleine bedrijven gemakkelijk de overstap maken naar cloud computing, grote bedrijven deden dat nog niet zoals security en compliance. We zien nu dat meer grote bedrijven de overstap maken. Maar waar moeten we beginnen, wat moeten we doen? Daar helpen we ze mee. Natuurlijk lijkt cloud computing goedkoper omdat je IT afneemt van een derde partij. De kosten zijn het eerste aspect. Cloud computing is vorm van outsourcing. Mensen en processen zijn andere belangrijke aspecten. Cloud computing is een andere, flexibelere en gestandaardiseerde manier van outsourcen. Deel blijft in organisatie dat verantwoordelijk is voor de governance van cloud computing. Hoeveel mensen zijn er nodig om de contracten en relaties te managen? De processen moeten hier ook voor ingericht worden. Hoeveel mensen moeten er op geleid zijn om de cloud contracten te beheren en de processen moeten daarvoor ingericht worden. Migratie is ander belangrijk aspect. Legacy systemen kunnen niet zomaar worden overgezet. De processen moeten worden aangepast voor deze migratie, manier van werken en manier van data opslag. Al die veranderingen die nemen we mee in de business case. De zachte kosten zijn moeilijk hard te maken. De kosten zijn gemakkelijk te bepalen, maar de veranderingen voor mensen en de processen die aangepast moeten worden en de migratie er naartoe zijn moeilijker te bepalen. [Definieer je eerst de service of ga je voor ene globaal programma.?] We beginnen met ene cloud readiness assessment dat bepaald welke delen geschikt is voor de cloud. Een inventarisatie van de applicatie landschap is benodigd om te kijken welke wet en regelgeving er aan vast zit en wie en wat het gebruikt. Sommige bedrijven zijn niet klaar voor de cloud. Een e-mail applicatie is bijvoorbeeld gemakkelijk te naar de cloud te verplaatsen, maar applicaties die de primaire business proces ondersteunt is niet geschikt. Welke applicaties heb je, welke zijn geschikt, welke zijn gestandaardiseerd. De business case kan zowel voor een groep van applicaties als een specifieke applicatie gemaakt worden. Meerdere applicaties te gelijk heb je minder migratiekosten, maar bedrijven willen graag stap voor stap. Eerst e-mail, dan crm etc. De randvoorwaarden die je van te voren stelt bepaald als eerst je deployment model. Ga ik eerst alleen mijn infrastructuur outsourcen of een complete softwarepakket? Dat doe je van te voren en niet achteraf. Eerst bepaal je dat en dan de specifieke kosten. Wij kijken ook naar alle mogelijkheden en kijken naar de randvoorwaarden, welke wet en regelgeving heb je etc. en dan pas naar de specifieke business case en de exacte kosten. De vraagstukken omtrent cloud past binnen een globale IT strategie. Klanten komen bij ons met bepaalde vraag, zoals we willen over 5 jaar kosten besparen. Daarna kijken we hoe cloud computing daar binnen past. We beginnen met de strategie en visie en kijken naar wet en regelgeving en dan kijk je hoe cloud hierbinnen past. Ik zie de business case als het sluitstuk van al die stappen er voor, waarmee je kan aantonen dat het werkelijk financieel efficiënt is. Het ligt eraan je definitie van de business case of je de stappen ervoor ook meeneemt, maar wij zien het voornamelijk als de werkelijke kosten vergelijking. 139
Eerst begin je met strategie en visie daarna cloud readdiness. Strategie en visie is een aparte dienst maar hoort niet echt ij business case ontwikkelen. Dat doen wij als aparte dienst. Het kan dus zijn dat cloud erbij past. De cloud readiness assessment is een soort van quick scan. Het is een vragenlijst over de IT infrastructuur en processen om te kijken of de bedrijven wel echt klaar zijn voor de cloud. We zien dat de eindgebruikers de aanjagers zijn van dit soort ontwikkelingen. Die nemen eigen tablets mee en gebruiken dropbox enzo terwijl dat niet mag. Of een manager die cloud diensten gebruikt en die dat ook wil. De iT organisatie is een enorme verandering. Je hebt andere governance, andere verantwoordelijkheden, IT department wordt kleiner, wordt vooral contractmanagement de focus. Cultuur omslag door flexwerken en overal en altijd willen werken. Hangt niet sterk samen met cloud, maar wel trend die tegelijk opgaan. Bedrijven die meer 9 tot 5 mentaliteit hebben zie je minder cloud ontwikkelingen, Dit geldt dan vooral voor eind gebruikers diensten, SaaS. Bij IaaS zie je meer impact op de IT departement en eind gebruikers merken er weinig van. [Wat veranderd er aan governance zoals je eerder noemde?] Dat heeft echt te maken dat je voor de dienst afneemt goede afspraken maakt. Contract van te voren goed opzetten, service levels, hoelang mag het duren voordat ik gebruiker kan aangemaakt worden, wanneer is dienst beschikbaar etc. De besturing van het contract en monitoren van dit contract. Het is een standaard dienst bij SaaS dus je kan eigenlijk niet zoveel afspraken maken, tenzij je echt groot bedrijf bent. Het is heel belangrijk dat je monitored van het contract en dat de dienst aansluit bij wat je als bedrijf wilt. Het is ook makkelijker te switchen tussen providers. Ik zit nu wel aan mijn huidige provider en is dit wel de moeite waard om niet naar ander te gaan. [Welke processen zijn er nodig of welke veranderen er?] Belangrijk is dat je data niet meer op je IT staat. Het staat op een andere partij waar je geen invloed op hebt. Processen moeten afgesproken worden wat er gebeurd als bv provider failliet gaat. Je bent veel meer afhankelijk van je cloud provider. Waar mijn scriptie over ging en wat heel belangrijk is, dat je weet waar je data staat. Je ziet dat er heel strikte afspraken gemaakt moeten worden van waar staat je data en wie kan erbij. [Veranderen bv demand management processen?] Bij cloud zie je dat er meerdere providers zijn in contract tot traditionele IT. De sturing van het contract met meerdere partijen zijn belangrijke nieuwe processen. 1 persoon is bv verantwoordelijk voor beheer van contract en iemand die erboven staat die verantwoordelijk is voor het beheer van alle contracten. [En qua roles en repsonsibilties?] Dat is afhankelijk van waar je organisatie vandaan komt. Als je al gebruik maakt van geoutsourcde partijen dan veranderd er niet veel, behalve dat je nu meerdere providers hebt. Het ligt er dus aan waar je vandaan komt in hoeverre de rollen en verantwoordelijkheden veranderen. [Risico’s en risk management.] Binnen KPMG zijn er risk management consultants, dus ik weet niet echt veel van risk management. De inhoudelijke risico’s hebben we al benoemd. Ik zie binnen organisaties niet echt een volwassenheid van beheer van cloud risico’s. Interne audit diensten verifiëren hoe je interne IT in elkaar zit. Dat is moeilijk als je dat hebt uitbesteed aan een andere partij. Als je contract hebt met 140
outsource kan je specifieke afspraken maken bij cloud dienst heb je standaard dienst en kan je niet zomaar zeggen ik wil audits uitvoeren op IT infrastructuur van de provider. Wat we daar zien is dat er gewerkt wordt met certificaten en assurance verklaren van bedrijven zoals KPMG, zoals ISO certificaten. Wat je nu ziet is dat er een recente ontwikkeling is in de financiële sector. De Nederlandse bank laat ook cloud diensten toe in financieel sector maar specifieke afspraken worden gemaakt met bv Microsoft om het recht om audits uit te voeren, Dat was voorheen niet mogelijk, maar Nederlandse bank heeft afspraken gemaakt. Ik weet alleen niet of Nederlandse bank of de financiële instellingen audits mogen uitvoeren. Zo’n certificaat houdt zich strikt op het normenkader. Het kan best zijn dat fysieke toegangscontrole bijvoorbeeld niet wordt aangevinkt en wordt dan niet gecontroleerd. Een certificaat zegt niet meteen dat een alle aspecten zijn uitgevoerd. Risk management of interne audits worstelen wel met dat je enkel afhankelijk bent van certificaten. Dat is lastig want kan zelf geen audits uitvoeren. Het gaat heen richting certificaten monitoren en je moet vertrouwen dat dat voldoende is. [Hoe zie jij cloud governance? Wat is er nodig voor cloud governance? ] De business case zou je bij cloud governance kunnen bedenken. Readiness assessment, wat is de echte business case? Daarna opstellen van contract is heel belangrijk. En dan beheren van contract, testen of wij en provider voldoen aan het contract. Checken of het aansluit bij de wensen van de business. Het zorgen van security controls in sla en monitoren van de risico’s, zoals als cloud provider failliet gaan. Mensen besturen en managen de contracten. Dat gebeurd niet geautomatiseerd. [SOA?] Ik zie bij de klanten dat SLA management niet geautomatiseerd is. De klanten die wij hebben ligt er misschien aan. Misschien bij kleine en middelgrote zouden wellicht automatisch Sla’s kunnen monitoren, maar dat weet ik niet. [En cloud team of excellence?] Ik zie dat meestal binnen bestaande structuur gebeuren en externe expertise. Ik ken geen organisatie waarvoor specifiek voor cloud een center of cloud governance wordt ingesteld. Cloud blijft gestandaardiseerde dienst, zoals e-mail en dat soort dingen, en dan houdt het toch best snel op. Dat houdt in dat het gestandaardiseerd is en niet erg geschikt is voor primaire processen. We zien niet gebeuren dat IaaS wordt afgenomen. Die ontwikkeling komt op gang. SaaS is lekker gemakkelijk. Ik ben heel erg geneigd bij cloud te denken aan SaaS. Bij IaaS is het heel ander soort contract, je neemt Vmétjes af en is niet zo heel erg spannend. Dan veranderd er minder. Infrastructuur is toch al uit besteed.
IT strategists [Expert 1] [Business case?] Een Cloud business case is denk ik niet heel veel anders dan een traditionele outsourcing business case. Je kijkt gewoon naar welke kosten je nu maakt. Alleen zijn nu in-house veel kosten opgebouwd, je hebt gebouwen, mensen moeten het beheren etc. Hoeveel kost het me nu en hoeveel kost het me nu minder als ik het buiten de deur doe en komt er dan een positief rendement uit. En bij outsourcing is dat hetzelfde. Daarin neem je mee in hoeverre je het aanstuurt. Het idee van Cloud is dat je standaardiseert. Het idee van standaard is dat het nog sneller kosten verlagend werk. Bij cloud zullen je initiële investering minder zijn. [Wanneer bepaal je deployment?] Is het niet soms dat direct al duidelijk was dat data binnen organisatie moet blijven?
141
Security en koppelingen zijn erg belangrijk. Wat erg belangrijk is ook de impact op de business. In het geval van SaaS neem je standaard oplossing. Dat is vaak een moeilijkere keuze, waardoor het vaak niet doorgaat. Sommige applicaties, zoals CRM etc. kunnen gemakkelijk SaaS afgenomen worden. Bijvoorbeeld een ITIL monitoring tool ook. Maar voor veel applicaties zijn geen standaard oplossingen voor. Dit is een probleem. Je moet dus tegen sommige business units zeggen we gaan standaard oplossingen gebruiken. Dat is dezelfde reden dat je bepaalde dingen niet outsourcet. Omdat je bepaalde applicatie needs in je organisatie wilt houden. Sommige bedrijven nemen enkel infrastructuur af. De standaard mainframe laag wordt dan afgenomen, de applicatie blijven ze zelf doen. [Meerdere business cases?] Voor sommige oplossingen worden aan meerdere leveranciers gevraagd hoeveel het kost. Voor de pure cloud zijn de risico’s een belangrijk aspect, bij private cloud niet. Daar speelt security minder. Bij business case is aan deze eisen moet het doen en dan wordt gevraagd aan leveranciers voor hoeveel geld ze het kunnen doen. Er kunnen zeker wel meerdere business cases gemaakt. Dat ondanks kwalitatieve redenen een optie minder lijkt, kan er alsnog een overweging worden gemaakt voor een andere optie als het gewoon heel erg verschilt. De business case is de som van wat je er voor doet. Als het erg positief is kan de business nog steeds overwegen om dat te doen. [IaaS en SaaS overwegingen?] Het is moeilijker. Het is makkelijker, stel je hebt 300 applicaties en draaien op zelfde technologie, dan kan je makkelijker zeggen ik ga onderop die laag outsourcen dan 300 maat applicaties of SaaS applicaties afnemen. Voor sommige applicaties heb je geen SaaS applicaties. Voor standaard ITIL tooling zoals incidenten heb je wel SaaS. Zo zie je dat Salesforce CRM oplossingen wel zijn. Je zal naar soort categorieën applicaties moeten kijken. Voor welke soort is het wel aantrekkelijk om cloud te nemen. De business case voor Mail applicatie bij universiteit Utrecht was simpel. Allemaal servers met licenties voor Microsoft was veel duurder dan google diensten van tientje per jaar. Ja, business case is dan snel gemaakt als er zon grote verschillen zijn. Voor individuele applicaties kan je richting SaaS gaan. De business case is dus gewoon traditioneel. Welke kosten maak ik nu, mensen operaties apparatuur etc. en wat gaat het me kosten in de geoutsourcet situatie, je hebt ook mensen nodig voor het aansturen enzo. Het is belangrijk de kosten niet te onderschatten, Bv salesforce lijkt goedkoop, maar om het te configureren zoals Sap kost het veel tijd te configureren. Veel organisaties zitten met hun oude systemen. Ben je een start-up dan kan je gemakkelijk direct gebruik maken van cloud diensten. Heb je allemaal bestaande systemen waarin ze geïntegreerd moeten worden, dan is dat een stuk lastiger. Voor standalone applicaties die weinig integratie nodig hebben zal de adoptie veel groter zijn. Maar de business case is volgens mij ongeveer hetzelfde als outsourcen. Ik zie geen bijzondere dingen. Je ziet nu ook veel dat er nu tussen oplossingen zijn, voordat organisaties zijn echte overschakelen op echte cloud. [Impact op organisatie?] -opleiding, niet iedereen kan er mee omgaan. 142
-Inrichtingen van de applicaties -Migratie van gegevens -Bepaalde aspecten vallen weg als je iets outsourcet. Maar heb wel bepaalde mensen nodig die kijken of er aan de afspraken worden gehouden. Je hebt mensen nodig die de leveranciers aansturen. Het zou zo maar kunnen dat je vier man nodig hebben. En je gebouwkosten en servers die afschrijvingen moeten ook worden meegenomen. Het kan zijn dat degen naar wie je toe gaat dat zij die mensen meenemen, maar als zij dat niet doen, dan raak je ze of niet kwijt of het duurt langer. Je kosten gaan niet zomaar naar 0. Dus eerst bijvoorbeeld heb je vier man erbij nodig en dan je gebouw kwijtraken. Het is dus erg belangrijk wat je werkelijke kosten zijn. Je hebt ook projectkosten om naar 0 te gaan. Je hebt nog steeds het gebouw en de mensen in dienst. Andere aspecten dan kwantitatief: Sommige kunnen het vervelend vinden dat sommige dingen van hun werkzaamheden verdwijnen of collega’s verdwijnen, je bent in sommige gevallen niet meer een allround IT organisatie. Wat zijn de kwalitatieve baten en lasten worden ook meegenomen ja. [Governance structuur?] Die veranderingen, zoals strakkere sturing, worden toch vaak financieel uitgedrukt. Het kost dan gewoon extra geld. Bij management gaat het toch vaak om de financiën, tenzij er onacceptabele risico’s aanzitten zoals niet voldoen aan wetgeving. [Team of excellence? Structuur aanpassing?} Het past redelijk binnen bestaande organisatie structuur, maar je hebt vaardigheden nodig. Vaardigheden zoals het aansturen van externe leveranciers. Dat zijn andere vaardigheden dan interne IT bedrijf. Maar ook daar geld is het een soort van outsourcing of meer SaaS verhaal als je die extreem doortrekt. Heb je alleen SaaS dan hoef je niet iemand te hebben die kijkt naar requirements, dan krijg je veel meer regie functie die kijken naar alle SaaS applicaties die beschikbaar zijn in de markt en dat soort dingen. Applicatiebeheer enzo heb je dan niet meer. [Meer inkoopmanagement?] Ik zal je een plaatje laten zien van een SaaS omgeving in 2015, die ik gemaakt had in 2009. In het oude verhaal heb je een IT service center die heel veel dingen zelf doen en een aantal dingen inkoopt bij derde partijen, zoals de infralaag. Veel ITIL support. In de SaaS situatie bouwt een beheer je bijna niks meer, je wordt regie partners. Je hebt nog maar klein clubje nodig. Je bent alleen nog maar bezig met aansturen van derde partijen, zoals contract management, finance, service level management, vendor management en je helpdesk. Je kern wordt ook anders. Je moet snappen hoe IT markt en hoe cloud markt in elkaar zit en weten wat de business nodig heeft om de juiste cloud dienst bij te zoeken. Je wordt een advies club richting de business van welke cloud dienst bij de business past. Je krijgt een service catalogus onder je arm en gaat naar de business deze diensten hebben we. Je adviseert in de cloud diensten, sommige diensten zijn beter andere duurder. Dan wordt het een heel ander type IT sturing. [Organisatiestructuur?] Dat verscheelt per bedrijf. Sommige diensten de beslaan heel een organisatie, andere alleen enkele units. Het hangt er van af waar de IT diensten voor worden gebruikt. Bijvoorbeeld als je knopje binnen OSIRIS veranderd, dan 143
moet je wel weten wie het precies gebruikt om te overleggen over de verandering. Bij standaard applicaties heb je die discussies weer niet. Als het echt alleen maar cloud hebt, heb je dus echt wel anders besturingsmodel. [Risico’s? Ander risk management framework?] Je hebt gewoon risico eisen. Zoals banken hebben er heel veel. Je moet dan kijken of de cloud diensten er dan aan voldoen, zoals bij andere outsource dingen. Kan een cloud provider die security eisen waarmaken. Wat anders is dat je niet naar je eigen IT afdeling gaat vragen over de aan de leveranciers of je langs mag komen om wat eisen te bekijken. Bij office 365 hadden ze bijvoorbeeld gedonder dat data in Amerika stond en dus niet gebruikt kon worden bij bepaalde bank. [Apart framework?] Er worden geen apart risico framework gebruikt, misschien alleen dat omdat buiten je eigen organisatie is bepaalde dingen een hogere risico zijn dan bij intern het geval was. Kijk wanneer Google eruit gaat en je eigen server. Maar aan de andere kant, als google er uit valt kan je niks doen. Je hebt een aantal cruciale risico factoren, die ze nu aan het oplossen voor. Maar om nou te zeggen dat er vanuit bedrijven speciale dingen voor worden opgesteld Misschien dat er aan speciale richtlijnen een paar extra regels worden toegevoegd, of dat er ander gerate wordt, in plaats van groen, geel, wordt oranje maar geen speciaal iets om dat te managen. [Soa en cloud?] Het zal rijpen er naartoe. Dat je anders de dingen bestuurt. De problemen met connectiviteit is nog niet opgelost. Voor grote systemen is de adoptie erg laag. Dat soort SOA systemen nog niet gezien. [Cloud governance?] Ik weet niet of je iets nieuws nodig hebt. Ik vind wel dat als je het doortrekt dat je andere vaardigheden nodig hebt een andere type sturingsorganisatie, maar dan moet je wel ver zijn. Op dit moment is het vooral of de standaard applicatie voldoet en kan je de connectiviteit en risico’s en zijn die acceptabel. Maar je gaat niet heel anders je bedrijf nu sturen. Ik kan me voorstellen dat als je de trend doortrend dan krijgt de IT een heel andere rol, maar dat is pas in 2020. Risk speelt grote rol, zoals connectiviteit, en strategie, past het binnen organisatie en is het financieel interessant. Dat zijn de vier belangrijkste drivers. De beslissingen zijn het zelfde, dus qua governance structuur minder belangrijk. Kijk ook naar outsourcen want die hebben ook veel van dit soort risico’s. Maar wat echt anders is, is dat SaaS gestandaardiseerd is. En heb je wel of niet invloed op de risico’s. Eigenlijk moet je ook kijken naar traditioneel outsourcen in je business case. Normale outsourcing of cloud oplossing. Cloud zijn eigenlijk oude dilemma’s in nieuw jasje. SaaS is wel vergaandere, gestandaardiseerde manier van outsourcen. Niet meer dan dat.
IT strategist [Expert 2] [Functie?] 144
Ik werk als IT strategie adviseur voor verschillende klanten. Dat kan variëren van IT beleid tot aan projecten waarin implementaties worden voorbereid, meestal op IT strategie en architectuur gebied. Cloud computing speelt hierin een rol. Wanneer het wel of niet kan. [Ervaring?] Bij een IT strategie traject komt cloud computing naar voren, soms als oplossing van problemen die er nu zijn, zoals de onbeheersbaarheid van de IT kosten. Tegelijkertijd spelen bepaalde risico’s naar voren en dat komt ook naar voren in de IT strategy traject. De business case is de tweede fase. Eerst krijg je de strategische ontwerpfase, waarin je bedenkt welke kant je heen gaat en daar kan je moeilijk een business case van te maken. Cloud computing wordt in de architectuur opgenomen als optie als bv streving naar standaardisering. In een later stadium in de project portfolio management waarin projecten naar voren geschoven worden wordt een business case van belang. Bijvoorbeeld een business case maak je of je kiest voor een standaard CRM systeem of een cloud oplossing. Een business case is niet alleen een kwantitatieve verhaal, ook kwalitatieve, zoals security, betrouwbaarheid etc. of de bijdrage aan strategische uitgangspunten. Het is vaak een variant van andere alternatieven. Sommige business cases zijn heel kwantitatief, maar dat doe ik vaak niet. [Kunt u het traject uitleggen van business case ontwikkeling?] We kunnen het gesimplificeerd voorstellen dat er op een gegeven moment een strategisch alternatief is om na te gaan in welke mate cloud computing van belang kan zijn voor de organisatie. Dan zouden ze op dat moment het moeten gaan onderzoeken. Eerst bedenk je op strategisch niveau wat het is en welke vormen er zijn. Infrastructuur dingen zijn natuurlijk heel anders dan een SaaS applicatie. Zelfde geld tussen private en publieke clouds. Eerst gaat de discussie over welke vormen er zijn en dus hoe ze van toepassing zijn op de organisatie. Het is een wisselwerking tussen IT strategy en Business demands. Een school zou bv kunnen zeggen ik heb mijn administratie niet op orde dus ik wil iets anders, strategische veranderingen doorvoeren met een noodzaak voor bv een cloud system. Een andere kant is ik zie de mogelijkheden van cloud computing langskomen. Wat in je omgeving gebeurd zet je af tegen je problematiek en wensen. De cloud computing zou op een gegeven moment een oplossing kunnen zijn voor een probleem. Je neemt bv cloud mee in een beslissing om nieuw administratief systeem aan te schaffen of je kijkt vanuit de mogelijkheden van cloud naar je strategie. Cloud is dan een uitgangspunt, we willen niks doen meer zelf in de organisatie. Maar meestal zien ze het als een alternatief. Het is bijna een sourcing vraagstuk. De strategie hebben we eerst; dit moeten we allemaal veranderen de komende jaren. En dan is het vers 2 of je het allemaal in huis gaat doen of je gaat in meer of mindere mate een clouddienst daar voor gebruiken. Je maakt dus eerder business cases voor verschillende realisatie alternatieven.
[Wanneer vorm bepalen, allemaal verschillende business cases?] Ik denk dat per probleemgebied is het de vraag of alle vormen van cloud strategische optie zijn. PaaS en IaaS is natuurlijk totaal iets anders dan SaaS. Het is een heel ander strategische keuze om een bepaalde PaaS optie te onderzoeken dan een SaaS optie, omdat het meerdere applicaties beslaat. Ik kan me voorstellen dat het verschillende discussies zijn. Wat je ook ziet gebeuren dat organisaties opeens besluiten om hun hardware uit te deur te doen. Voor de eind gebruikers gebeurd er dan niks. De punt is je strategie bepalen je uitgangspunt van je business case. De infrastructuur outsourcen is andere discussie dan een SaaS optie. PaaS en IaaS zijn denk ik generiekere beslissingen. Eerst wat wil je, dan hoe. [Wat zit er in de business case?] 145
Je moet zelf ook hele andere dingen gaan doen. Als je een eigen IT afdeling hebt die moeten andere dingen kunnen doen dan IT dienstverlener die het beheer doet. Daar heb je veel formelere afspraken mee. De consequenties daarvan zijn formelere afspraken. En dat je volwassen moet zijn en dat je behoorlijk aan flexibiliteit moet inleveren. Het is maar net wat je afweegt in een business case wat je meeneemt. In wezen kan je van alle strategische beslissingen een business case maken. In de praktijk zie je weleens als een apart vraagstuk als een echte sourcing vraagstuk wordt gezien. Is wordt bepaald willen we het of willen we het niet een applicatie. Daarna doen we het zelf of besteden we het uit. [Je hebt dus eigenlijk eerst service definition en dan outsourcing?] Ja, het is ook in de tijd heel erg ontkoppeld. Je kan al lang een systeem hebben en beslissing nemen om het anders te gaan sourcen. [Hoe gebruik je enterprise architecture? Is ea belangrijk geweest?] EA is een soort een ontwerp dat uiteenloopt van de business kant tot technische implementatie. Dus als je het zo bekijkt, als iemand zegt ik wil cloud computing, dan kun je afvragen hoe het past binnen de enterprise architecture, wat is de compliance met de EA. Het zou ook iets kunnen zeggen zoals dat bepaalde aspecten in eigen beheer wordt gehouden, zoals een verzekering graag wilt zien. Een overheidsorganisatie ook bv omdat de Amerikaanse wetgeving er is en wij vinden dat de Nederlandse overheid is voor de privacy bescherming van onze gegevens is dat wij in het enterprise architectuur opgenomen is om bepaalde data op eigen servers te houden. Het geeft ook inzicht om te kijken of een applicatie privacy gevoelige gegevens heeft. De EA geeft dus een sturende rol om cloud computing te nemen. Dit was een voorbeeld, zo iets kan ik me voorstellen. Nog belangrijker is dat je op enig moment je EA zo erg aanpast dat je de introductie van cloud gemakkelijk maakt. Zo gebruik je het voor een IT strategie die gebruik kan maken van cloud diensten. [Bij soa is het een heel programma, maak je business case voor programma of applicatie? Soa is uiteraard veel breder. Soa is echt een paradigma, het gaat veel meer dan integreren van cloud diensten. Cloud past wel makkelijk binnen een service oriented architecture. [Wanneer kies je deployment model?] Ik denk dat al vroeg in het proces kan bepalen welke opties relevant zijn door middel van enterprise architecture principles. Bij privacy gevoelige gegevens is public cloud bijvoorbeeld geen optie, dan onderzoeken we dit ook niet. Ik denk dat het terreinen zijn waar een bepaalde model erg voor de hand ligt. Wanneer je kantoorautomatiseirngsfuncties hebt is de Office 365 of intern een voor de hand liggende optie, maar voor een CRM pakket ga je eerder naar een specifieke aanbieder, wat toch vaak als een private cloud is ingedeeld. Vaak ligt de deployment model al vaak vast voordat je business case maakt. [Wat veranderd er binnen de organisatie?] Voor de eindgebruikers of de business veranderd er niet veel. Het maakt niet uit waar het draait, het gaat om de eindfunctionaliteit. Het kan wel zo zijn dat er verschillen zijn in functionaliteiten tussen bv Office 365 en normale office, maar laten we veronderstellen dat je exacte functionaliteiten hebt. Dan lijkt mij het grootste probleem hoe ga je dit beheren. Hoe werken je beheerprocessen, technische beheer, functioneel beheer, helpdesk, service management. Wat gebeurd er als je iets veranderd wilt hebben. Hoe ga je dat organiseren. Het is niet meer zo dat je zelf een project kunt starten. Je zult een uitvraag moeten doen naar de leverancier. Soms kan dat helemaal niet, aangezien het vaak een standaard dienst is. Wat doe je met bugs en problemen, kan je een helpdesk bellen en wie helpt je dan. En functioneel beheernmoet je dat zelf beheren. Je beheerprocessen, zegmaar je ITIL processen die zijn ingericht worden anders. In plaats van je dat je met je eigen collega’s en je eigen afdeling die je processen kunnen indelen zoals je wilt, heb je een klant-leverencier relatie met degen die de cloud 146
dienst levert. En dat is wat er veranderd. Het grootste probleem is dat organisaties daar vaak niet erg volwassen zijn. Organisaties zijn vaak heel informeel en heel weinig governance op hun eigen IT processen. Bij de koffietafel bespreken ze gewoon dat er een extra persoon nodig is als er 1 ontbreekt. Organisaties die business units hebben met een shared en managed service center is het heel anders. Die bieden in feite een soort SaaS constructie van de IT afdeling naar de organisatie. De stap om te outsourcen is dan klein, ze geven dan de SLA gewoon naar de provider. Maar vaak zijn die er niet. De provider stuurt je een SLA op en dan realiseren ze niet dat ze zich daar aan moeten houden en wat de implicaties daar van zijn. [Cultuur?] Ik denk dat de cultuur formeler wordt. Je moet explicieter moeten besluiten over je IT en de veranderingen die je wilt. Je moet professioneler zijn in je change management en je portfolio management. Het wordt geformaliseerd. Dat is vaak de consequentie van cloud, in de relatie tussen organisatie en provider. [Governance structuur?] In principe denk ik dat je de relatie met je IT moet verzaken. Ben je een heel erg innovatief bedrijf met highly skilled people die snel nieuwe producten op de markt brengt dan doe je veel dingen zelf. Dan outsource je niet, dan gebruik je geen cloud diensten. Degen met een goed idee voert het uit. Jezelf kan het beter dan anderen. Het moet dus ook wel binnen je cultuur passen. Dingen die beschouwd worden als commodity, waarvan je niet onderscheid met concurrenten die kan je outsourcen. Dat zie je ook met office 365. Hebben liefst het office beheer uit de organisatie. [Rollen en verantwoordelijkheden?] Ik ben geen ITIL expert, maar er zijn wel volgens mij specifieke processen rondom supplier management zijn. Je hebt een zakelijke relatie tussen demand en supply, waarvan je leverancier management er wel bij krijgt stel ik me zo voor. Dat is zwaarder als het specifieke software is, in plaats van standaard pakketten. Voor Gmail bv hoef je weinig te doet lijkt me, dat is zo generiek. De dienst is zoals het is. Dan vallen veel beheerprocessen af. Dat kan ook een consequentie zijn van cloud computing. SLA management wordt belangrijk en is formeler dan bij managed service center en heeft grotere financiële implicaties. Elke wijziging kost handling kosten. Daarvoor is governance nodig dat je dat niet teveel doet. [Processen en policies?] Wat me bij me opkomt, zijn de ITIL processen. Andere processen weet ik niet echt. Waar ik nog aan denk is dat functioneel beheer anders gaat werken. In plaats van het idee dat je zelf kunt bepalen hoe de functionaliteiten zich moeten ontwikkelen ben je afhankelijk van de leverancier, maar dat is natuurlijk ook zo als je standaard office pakket hebt. Ik heb er niet zon beeld bij, sorry. [Policies? Verschillen met shared service?] De policies die heb je gewoon. Sommige bedrijven hebben hoge eisen aan security en sommige niet. Die zijn bepalend of cloud dienst van slagen is. Die hoeven niet zo zeer geïmplementeerd worden, maar ze zijn er. Maar als je uit besteed zouden wel bv privacy policies nodig kunnen zijn, zoals audits en dergelijke. De policies voor gebruik van bv dropbox is iets anders, omdat dat nodig is ook al kies je niet voor cloud. Dat overkomt organisaties gewoon. Cloud computing komt organisatie binnen waaien, net als BYOD. [Risico management? Extra framework nodig?] Hier heb ik geen idee van. Geen praktische ervaring mee. Risico management methodieken hebben we, om ze in kaart te brengen en maatregelen te definiëren. Maar dan zit ik snel te fantaseren. Het is 147
echt een thema. Van cloud computing wordt wel vaak gezegd dat risico management erg belangrijk is, maar hoe dat precies zit weet ik niet. [Governance?] Governance is hoe neem je besluiten. Ik denk dat er twee vormen van kunnen zijn. Hoe werkt het strategisch traject om te kiezen voor cloud. En het traject als je het eenmaal hebt welke besluitingvorming zit daar dan om heen. Bij governance denk ik heel vaak aan, hoe besluit ik tot het doen van IT projecten en al dan niet doorvoeren van veranderingen. Dat werkt anders bij cloud diensten dan bij andere diensten. Ik heb daar niet zo’n goed beeld van. Ik denk dan snel aan ITIL waarbij je in geheel over het totale IT portfolio in samenhang beslissingen neemt, zodat je niet kleine lokale beslissingen neemt die onttrokken zijn aan het overzicht en dat je wel kleine beslissingen en grote projecten, project portfolio, in samenhang neemt. Dat is voor mij governance, hoe je dat doet. Governance gaat over de beslissingen binnen processen. Wie beslist wat. Het zijn deelverzameling processen van besluitvormingsprocessen. Maar of er echt iets is als cloud governance, dat vind ik ingewikkeld. Het is in essentie gewoon een manier van sourcen. [SOA?] Het ligt voor de hand om SOA principes toe te passen op cloud, omdat cloud wel goed past binnen een SOA architectuur. Het maakt in principe onderdeel uit van cloud. SOA is de grote beweging en cloud heeft daar een rol in, maar niet omgekeerd.
Cloud program manager [Expert 5] [Functie?] We zijn een publieke partij vanuit het ministerie van onderwijs, eerst was het een afdeling van onderwijs, nu is het een aparte stichting, maar het is in feite een publieke organisatie om zo goed mogelijk alle partijen bij elkaar te zetten om makkelijker dingen te implementeren in het onderwijs, waar cloud een van die dingen. Wat willen de partijen nu in het onderwijs, hoe kunnen we dat bereiken, wat is daarvoor nodig en met alle partijen samen willen dat realiseren. Het idee is om een Mbo cloud te krijgen waarin de meest belangrijke functionaliteiten en content die studenten en docenten nodig hebben. We willen dat als je na de zomer begint dat je dan dit als student dit wil ik doen en dat de content direct beschikbaar is. [Ervaring met cloud?] Een van de programma’s die ik doe is cloud computing in het onderwijs, we bepalen samen met de instellingen en het mbo raad de thema’s of issues die we oppakken in de jaarplanning. Cloud computing staat al een tijd op de agenda. Ik ben daar bij betrokken als facilitator van het proces en als expert om dingen uit te zoeken dan wel kennis bij te dragen aan het traject. Het programma wordt samen gedaan met Sambo, zij zijn onze partner organisatie in de ICT thema’s in het onderwijs en is een onderdeel van het MBO raad. Ik ben daar als programmamanager bij betrokken. De innovatieafdeling van kennisnet bekijkt welke innovaties het onderwijs eigenlijk echt moet doen. Ik als informatiemanager die koppelt de vraag vanuit het onderwijs en de ICT innovaties. Toevallig hebben we alle drie de aspecten behandeld in dit programma. Eerste vraag is vanuit de behoefte kan je een business case opzetten, kijken wat het voordeel is. We gaan een professionele, met een bepaalde methodiek, een business case opstellen. Dat je een goed onderbouwde kwantitatieve en kwalitatieve verhaal hebt waarom je cloud gaat doen. Bij ons heb je twee redenen waarom het positief zal uitvallen. Cloud computing is er gewoon, het komt er, het wordt al overal gebruikt, het is geen kwestie van wel of niet, maar eerder hoe. Het is wel dusdanig complex dat je het als school alleen niet kan tackelen, de hele problematiek van cloud computing en dat het vanuit samenwerking aangepakt moet worden. De 148
gezamenlijke MBO cloud kan die content bieden die de instellingen nodig hebt. Als je het samen doet kan het echt wat opleveren. De business case zal als tweede opleveren dat je veel flexibel kan werken, anytime anywhere je leerfaciliteiten kan opleveren. Dat is wat je wel ziet in samenwerking met het bedrijfsleven, dat het Mbo erg nodig heeft, men weel heel graag op de werkplek leren, bij stages. Daarnaast heb je ook dat mensen werken en 1 dag per week naar school gaan. Dat wordt veel flexibeler ingericht. Het biedt mogelijkheden om het onderwijs aan de huidige tijd beter aan te passen. De business case moet helder maken wat de voordelen zijn. En in het onderwijs zitten veel partijen heel erg klem. Scholen hebben met veel krimp te maken waardoor ze financieel in de knoop komen. Ook financieel gezien is het van belang om dingen anders te organiseren en kan het niet anders dat je dat met ICT en Cloud oplossingen moet doen. Daar zit ook een heel belangrijk aspect in dat je dat financieel goedkoper moet regelen. [Gelijk aan outsourcing?] Traditionele outsourcing is een apart verhaal. Dan kijk je bv naar het outsourcen van werkplekken wat minder scholen weleens gebeurd. Dat is een apart traject met een aparte traject. We kijken voornamelijk naar de mogelijkheden die cloud computing als vorm van outsourcing biedt met name op het SaaS gebied, dat is het belangrijkste gebied, maar ook het IaaS en PaaS zijn onderdelen die spelen. Maar IaaS is toch maar tijdelijk, want steeds meer SaaS applicaties zijn beschikbaar. Van belang is toch vooral wat er op het gebied van SaaS beschikbaar is. Het is deels een vorm van outsourcing, maar ook deels een vorm van samenwerking. Docenten kunnen zelf hun onderwijs content maken en delen en ophalen en kijken wat de andere docenten gebruiken. Cloud biedt wel unieke mogelijkheden op samenwerking. Via de cloud kan je makkelijk aan dingen komen. Dan wordt er een link gemaakt naar de uitgevers die zich ook in de cloud gaan beginnen. IN de cloud ontstaan allemaal nieuwe mogelijkheden die je ervoor niet had. [Proces van business case?] Dit gaat om een breder geheel. We hebben een methodiek ontwikkeld om business case toe te passen in het onderwijs, dat gericht is op een bepaalde oplossing en om te kijken of die oplossing de voordeling biedt die je wenst, zowel kwantitatieve en kwalitatief. Dat is onze rol om complexe methodieken eenvoudiger te maken zodat ze in het onderwijs toepasselijker zijn te maken. Die methodiek laat je los op verschillende vormen van cloud oplossingen. We gaan nu zelf kijken voor de totale MBO cloud business case op welke wijze we die gaan ontwikkelen. Ik heb nog geen idee hoe die we gaan opzetten. Meerdere cloud modellen en scenario’s worden met elkaar vergeleken. IN eerste instantie kijken we naar het ontsluiten van leermateriaal. Ook daar heb je een aantal scenario’s mogelijk afhankelijk die een school ziet bij het beschikbaar stellen van leermiddelen. Het kan zijn dat ze zeggen we leveren alles zelf, dan heb je scenario1 en kan ook dat leerlingen zelf verantwoordelijk zijn voor de scenario’s. Vanuit dat soort scenario’s kijken we naar de business cases. Bij zo’n scenario hoort ook hoe zon systeem hoort te werken. Als 1 functie of langer termijn: als het idee van cloud computing binnen komt, kijk je dan naar 1 functie op groter geheel. We proberen het in de breedte te bekijken, naar het grotere geheel. [Scope van business case?] Ja, dat is de vraag of dat gaat lukken en of je business case niet te erg uitwaait. Het is dan de vraag of de business case dan nog wel helder is. Het is nog maar afwachten of dat gaat lukken. Als je alle functionaliteiten meeneemt dan wordt het weer zo complex, daarom beginnen we eerst met leermateriaal in de cloud. [Wanneer technische specificaties?] 149
Bij cloud komen extra moeilijkheden, zoals nieuwe afspraken in de keten tussen partijen en daarnaar kijken we welke requirements zijn er nodig om de scenario’s vorm te geven. In de praktijk lopen dingen door elkaar. Het is ene heel lang traject, waarin partijen verschillende belangen hebben en niet altijd mee werken. Het zijn hele complexe trajecten waarin business cases veel bij helpen, maar vooral het samenwerken om tot nieuwe scenario’s komen is lastig. Het loopt in elkaar over. In theorie is het leuk, in praktijk is het anders. [Verschillende deployment?] Er wordt gekeken naar publieke, private, community cloud. Voor de avans hogeschool hebben veel leerlingen mooie dingen gemaakt om alles in te delen. De hoge school heeft een project Educloud ingezet om een cloudmodel te ontwikkelen voor educloud en gedefinieerd in een whitepaper waarin ze kijken naar de verschillende opties. [Methodiek business case?] Er zit niet eens een TCO model in. Een simpel vereenvoudigd spreadsheet om toepasbaar te maken in onderwijs. Enerzijds waarin je de baten kunt zichtbaar maken die je omzet in kwantitatieve opbrengsten. We denken dat we voor cloud een complexere methode te ontwikkelde. Dan moet je ook goed de risico’s in beeld krijgen. Het onderwijs is niet zo van de risico’s, daar wordt vaak overheen gekeken. Beschikbaarheid, continuïteit enzo moeten wel meegenomen worden. [Enteprise architecture?] Er worden een aantal dingen in beeld gebracht. We hebben een overzicht plaatje hoe nou het cloud model er uit zal moeten of kunnen zien. Er zijn drie lagen, de functionele laag, wat zijn de stappen totaal de mensen die aan de gang gaan. Welke processen zitten daaronder. We hebben alle processen van de Mbo instellingen, inclusief de primaire en ondersteunde processen, hebben we procesmodellen gemaakt. Gezamenlijk zijn die een referentie architectuur. Dat is wel een enorm boekwerk geworden. Maar daar verwijzen we wel naar zodat het erop aansluit. Je kan ook kijken welke gemeenschappelijke voorzieningen heb je samen nodig en wat de markt niet direct biedt of moeten bieden en je dus gezamenlijk zou moeten doen zoals de authenticatie en autorisatie architectuur. Dat wil je niet door commerciële partijen laten regelen. We hebben dus een aantal gemeenschappelijke voorzieningen. Dat zijn dingen die spelen bij licenties afsluiten van marktpartijen die ook de licenties monitoren of er aan de afspraken wordt gehouden. We zijn bezig geweest om standaard Sla’s op te stellen voor elkaar wat je er in moet opnemen. Dat kan je scholen niet zelf laten doen. In de markt zit educatieve software waarin resultaten van studenten wordt bijgehouden. Die staan bij de uitgever en die moeten ook in de registratiesystemen van de scholen. Hoe krijg je die gegevens. Afspraken moeten er gemaakt worden over welke resultaten en op welke manier er gecommuniceerd gaat worden. Afsprakenkaders wordt dit binnen de architectuur de koppeling tussen de systemen wordt gedaan. Die zijn nodig om de cloud een goede plek te geven binnen het onderwijs. [Impact op de organisatie?] Dit is een onderwerp wat nu sinds een half jaar op de agenda staat. De cloud kan opeens hard gaan en dan heb je opeens een IT afdeling met mensen waarvan je denkt wat moet ik er nu mee. Hier kunnen grote problemen mee ontstaan. De cao voor de IT mensen zijn zelfde als de cao’s van de docenten. Dit onderwerp staat nu op de agenda en ons is gevraagd om dit punt te adresseren. We hebben hiervoor een conferentie gestart met een discussie groep om dit eens te adresseren en te kijken hoe mensen er tegenaan kijken. Iedereen zit ngo met grote ogen te kijken van huh hoe bedoel je, dit moet echt nog een plek krijgen dat dit een enorme consequenties heeft voor de IT afdeling binnen school organisaties. Ik heb geen beeld van hoe dit gaat ontwikkelen, maar dat het belangrijke issue is waar me veel aandacht is wel duidelijk. Vorige week hadden we een netwerk georganiseerd van 150
informatiemanager s binnen MBO instellingen die hadden het ook besproken. Daar was de conclusie dat we snel deze issue moeten bespreken. We kunnen de IT werknemers niet zomaar ontslaan maar hoe gaan we er dan mee om. De instellingen hebben nu grote IT afdelingen die alles regelen. Dan zal heel anders ingedeeld worden. Een beetje Mbo heeft 30 servers draaien met allemaal applicaties die eruit gaan. Hoe dit allemaal zal moeten, daar staan we aan het begin van. Dit begint langzaam door te dringen. We hebben wel ICT opleidingen binnen de instellingen. Er zit wel een zekere schuifmogelijkheden in de ICT opleidingen en diensten. Daar zit een deel van de oplossing in. [Governance structuur?] Er zal wel een centrale organisatie ontstaan. Een sterke centralisatie om cloud goed te faciliteren. Als je dat goed regelt en goede afspraken en standaarden dan kan je binnen de instellingen de toepassingen kunnen bepalen. Het idee is om de docent zo zijn app kan ophalen en direct aan de slag te kunnen en s middags up and running zijn. Dat zou idealiter het plaatje zijn. En dus dat betekent dat je op decentralisatie niveau veel keuzemogelijkheden hebt. Centraal wordt besloten welke diensten aangeboden zullen worden. OP instelling niveau kunnen specifieke applicatie gekozen worden. Als het gaat lukken om een Mbo cloud te implementeren dan lijkt het me wel dat je een soort cloud board krijgt die de standaarden bewaakt en d inhoud van de Mbo cloud bepaalt, wat wel en wat niet en de kaders aangeven. Ik denk dat dat zeker zal gaan bestaan. Vervolgens maken d einstellingen keuzes. Ik denk wel dat er veel centraal geregeld gaat worden. Er hoort een goede centrale sturing te komen van jongens dit wel en dit niet. [Processen?] Als je dit soort dingen met elkaar gaat doen dan krijg je dat je rond cloud computing hele nieuwe processen komen te ontstaan. Welke afspraken maak je met je leveranciers en welke Sla’s maak je. Nou, dat zijn zingen die je anders moet gaan organiseren rond security, rond beschikbaarheid, rond waar staat wat in de cloud. Dus daar heel veel komt kijken om dat goed te organiseren. Vooral in de samenwerking moet er veel gebeuren wat voor scholen is dat vaak een brug te veel. Sommige hebben mensen rondlopen die wat kunnen, maar sommige scholen totaal niet. [Policies?] Een mooi voorbeeld is je moet veel scherper zicht krijgen over wat je nu uit de cloud wilt hebben. Als docententeam moet je vrij snel definiëren wat je nodig hebt. Dus je interne processen moe je goed op orde hebben. [Risico van clouds?] Qua risico’s zitten we in de beginfase om ze goed in beeld te brengen. Privacy komt bij ons als een van de grootste risico’s. Je werkt met veel persoonlijke gegevens. Daar zit een heel groot risico in. Daar zijn we ons nauwelijks van bewust. Wat we zien is en grote toename van juridische aspecten van het gebruik van ICT. Ik ben dagelijks bezig om te kijken hoe we afhankelijk zijn van juridische aspecten. Een ander risico is denken wij dat als een school teveel zelf moeten uitzoeken in dit gebied is dat ze erin verzuimen. Er liggen daarom ook financiële risico’s in dit vlak. Een goede samenwerking is daarom wel noodzakelijk. Scholen zijn niet zo geneigd om samen te werken. Bij de providers en de andere partners zit je constant aan tafel. Gezamenlijk moet je met de risico’s en in afspraken kaders met de aanbieders bespreken. [Risicomanagement framework?]
151
Dit zijn we met surfmarket aan het oppakken. Die maken afspraken met de aanbieders. De bedoeling is om een framework te verkrijgen zodat dit gezamenlijk beschikbaar komt in het onderwijs. Wel moet ik je eerlijk zeggen dat clouddiensten vaak een verbetering is ten opzichte van traditionele servers. Hoe vaak ligt Google eruit vergeleken met outlook op de servers binnen scholen. Ik denk dat heel veel cloud leveranciers betrouwbaarder zijn. [Soa governance technieken?] Op dit moment is het een zeer onvolwassen fase in het onderwijs. We streven we wel na dat we het soa model realiseren. De scope is wel dat we binnen 4 a 5 jaar dit hebben staan. De systemen hangen samen en wisselen uit. Heel veel van die systemen, zoals inschrijven planning systeem, roostersysteem, beschikbaarheid van je content, verantwoording naar je overheid, communicatie van studenten met ouders zijn zelfde informatiestromen en je moet afsprakenkaders hebben voor een goede uitwisseling. Er wordt wel gebruik van gemaakt om repsotories. De repositierie voor het uitwisselen van leermaterialen, die zelf ontwikkelde spullen die door andere gebruik gemaakt kunnen worden. [Ik bedoel echt service repository] Nee, nee daar zijn we nog echt niet aan toe. Dat is ver weg. Er kijken met een schuin oog naar het educloud. Om daar van te leren en daar achter aan te lopen. Dit soort dingen moeten daar eerst gebeuren voordat we er naar kijken. De geheel regie functie wordt belangrijk. Maar we zijn nu in het begin van het traject. [Cloud governance?] Ik denk dat je moet beginnen vanuit de behoefte. Het moet heel duidelijk gericht zijn naar de vraag vanuit het onderwijs. Vervolgens moet je denk ik heel erg goed monitoren van afsprakenkaders en de standaarden die je hebt gemaakt en dat die worden toegepast. Dat is denk ik wel een belangrijke rol. Veel verder zijn we daar nog niet mee gekomen. Wie gaat die regie functie op zich nemen weten we nog niet. Het is nog niet gezegd dat wij dit als kennis met dit gaan doen, Samba zou het kunnen doen. Er zijn nog wel wat opties, wie zich hierop gaat storten. Dat hebben we op voorhand nog niet gedaan. Binnen onderwijs leeft security heel erg beperkt. De tijd is nog niet zo lang geleden dat als er iets een week uit lag dat je een week van niemand hoorde. We worden wel steeds meer afhankelijk van ICT en cloud diensten en komt er dus steeds meer druk op dat je op aantal aspecten goed aanpakt. Ik zie wel een aantal aspecten die ik al ben tegengekomen.
Risk manager [Expert 4] [Risks?] We zijn er nu mee bezig om de risico’s gestructureerd in kaart te brengen. Waar wij naar kijken is enerzijds de security beheerders vanuit de cloud omgeving, van de infrastructuur en applicatiestructuur. En dan zal je zien dat die verenigd zijn in een aantal organisaties waar zij gebruik van maken, zoals ENISA en CSA en van andere kanten zie je dat je van audit organisaties het een en andere verenigd zijn. Wij hebben die gecombineerd en wat wij doen als een cloud dienst gecombineerd wordt houden wij allemaal stakeholders erbij en dan doen wij een risico assessment. Sommige van de risico’s die zie je gewoon niet en die liggen bij de klant waar je wel rekening mee moet houden. Een voorbeeld is in een rationele afweging is dat je niet zomaar een service kan installeren. Bij cloud service kan je zo je eigen systeem afnemen. Dat soort specifieke risico’s liggen aan gebruikers kant. Die stop je bij elkaar. Je gaat de belangrijkste bedreigingen langs die in d lijsten staan van Enisa en CSA etc. die loop je door die behoren bij aantal kwaliteit aspecten. Vanuit audit kijk je vooral naar information integrity enzo maar er zijn ook andere aspecten die van belang kunnen 152
zijn. Op een gegeven moment kom je op een risico matrix en daarop kan je elk risico model op los laten. We deden dit ook bij outsourcing. Voor ons is niks anders dan volgende model van outsourcing. Je weet alleen niet of je data wel veilig is in je shared omgeving, de organisatie lock-in effect, Dat zijn specifieke risico’s. De voordelen van cloud die IT strategists noemen is niet altijd waar. De transitie van Capex naar Opex is zo een. Ook bij traditionele IT kan je ervoor kiezen infrastructuur te leasen. Dus een hele boel dingen zijn bestaande dingen en wienig nieuw. Outsourcing 2.0. In eerste instantie bij interne service management met sales mensen die klanten vertegenwoordigen, want een klant nodig je niet uit voor een service die nog niet afgenomen is. Dat is wat we intern doen. Wat we extern doen is als strategie consultants zijn geweest bij sales en klanten en we willen er wat mee en helpen dan met hun risico assement te maken. We zitten heel veel in financiële markten. Volgens Nederlandse bank is verplicht om aan risico assessment te doen als je aan outsourcen bent en omdat wij dat vaker hebben gedaan kunnen wij de klant vergelijken en houden we de belemmeringen weg om de goedkoopste oplossing te kiezen en dat is vaak cloud computing. [Nieuwe risico framework?] Een bestaande risico management framework wordt gebruikt. J hebt een aantal nieuwe bedreigingen, maar de bestaande methodieken kan je gewoon gebruiken. Maar alleen risico identificatie is van belang. En compliance risico is bv dat outsourcen dat de Nederlandse bank geen onderzoek daar mag doen. [Audits?] Wat je ziet op veel website zie je gewoon we zijn ISO certificering compliant. Wat ze bedoelen is dat de generieke controls en wat extra’s certificaties die hun hebben gecertificeerd. Het is heel moeilijk welke er precies inzitten. Je hebt ook niet zoiets als cloud compliant certificatie, maar dat komt wel. Begin volgend jaar is dat er waarschijnlijk wel. Als je je risico model hebt heb je inherent risico als je nucleaire installatie hebt ga je anders met je risico op. Je audit risico is je inherente risico, welke organisatie heb ik hier + interne control risico. Welke omgeving. En interne control risico, hoe goed is bv interne controls volgens bv COSO ingericht zowel bij de klant en de provider, zit daar een match is, is er een goede SLA afgesloten, zijn die systemen met elkaar verbonden. En als laatste een taxie risico. In het eerste en tweede stuk ben je cloud en cloud provider afhankelijk. De klant bepaald de inherente risico en de cloud provider, de een is beter gestructureerd dan de andere. En de taxie risico moet je opvangen omdat sommige providers apps beginnen op te leveren waarop je logs krijgt. Je klant bepaald inherente risico en de Een audit risico Je hebt natuurlijk als je een risicomodel hebt [Recording was gestopt]
153
Appendix D: summary expert interviews (development phase) Interviewee
ID Business case
Content
Process
Cloud infrastructure consultant Expert 3 Costs, but also the impact on people and processes. Costs for training, adaptions on processes and migration costs are often overseen.
IT strategist
IT strategists
Expert 2 Quantitative aspects and Qualitative aspects, such as security and reliability, strategic business benefits and the change in processes and IT department. The exact content depends on what you want to take into account.
Expert 1 A cloud business case is not very different than other sourcing decisions. The difference in cost of a cloud solution to the existing solution is the most important. The costs of the organizational impact should be included. As a sourcing alternative, traditional outsourcing should also be included.
First strategy and vision, then evaluation how cloud fits in the strategy. A cloud readiness assessments has to be performed to see whether the organization is ready for moving to the cloud. Through an application architecture the applications can be identified which are candidates to be replaced by cloud solutions, taken into account legal and standardization issues
The initiative could come from a certain application need or from the awareness of the cloud computing trend. In most times it is seen as a possible implementation alternative for a service. It is basically a sourcing decision. Business cases are developed for multiple alternatives.
The development of a cloud business case is not different than other sourcing decisions. It is the sum of the activities before. Based on a certain application, you will compare the costs for traditional IT to a cloud solution.
Cloud project/program manager Expert 5 The business case contains qualitative as quantitative aspects. It must be a clear story why cloud computing is beneficial to the organization. We use a method to quantify the benefits, but we need also take into account the risks. In our case it is about costs and to allow students and teachers to work anywhere and everywhere. For our business needs traditional outsourcing was not an alternative. The business case should come out of a specific need. We now look at a need for a more flexible way to deliver educational services. Based on this service we build business cases according to a standard methodology for multiple alternative. Because more and more SaaS applications are available IaaS becomes less important. There are no clear steps. Looking at the risks, technical requirements, models and business cases are intertwined.
Risk manager Expert 4 Cloud computing is nothing new. It is just a new way of outsourcing. The most important aspect are the costs reductions, as it is in most cases the cheapest option.
154
Scope of applications
A business case can be developed for 1 or multiple applications.
This depends. It can be made for one service or a whole set of applications, dependent on the strategic driver.
It can both be developed for one applications or a set of applications.
Deployment and service model
The principles and policies determine deployment and service model before business case is build.
The exact model is in most situations al decided because of security policies and the need of the business. IaaS fulfills different needs than a SaaS application.
It is clear for certain applications than data needs to stay inhouse. But multiple business cases can be developed. When it is very strong for a solution although for some qualitative reasons is seems as a less appropriate option it could still be chosen. For some applications no standard SaaS applications exists, than IaaS is the only option or when you want to outsource a very large amount of applications IaaS could be a better choice. For one application you probably look at SaaS.
Enterprise architecture
An enterprise architecture is not always available. but an application landscape is developed to see which applications are appropriate to move onto the
The standardized cloud solution (SaaS) should fit in and comply with the principles of an enterprise architecture. Some applications are
This is a difficult aspect. The strategy involves multiple applications, but we start with a specific service otherwise it becomes too complex. We compare different deployment models and service models when building business cases, but there are no clear steps.
We have mapped our processes and we assess the impact on them with the cloud solutions. It is also used to identify the services we should not outsource to the
155
cloud or to see how cloud fits in or can form the IT strategy.
Impact on organization
People
Big impact on IT department, which will be downsized.
Processes
Managing the SLA or contract and managing multiple contracts wilt multiple providers are important processes. Security processes has to be implemented such as when a provider goes out of business.
not good candidates to be outsourced and standardized, because of strategic or security reasons. Also the EA can be developed around cloud computing as a strategic direction. For the end-users not much will change, only a change in applications.
The ITIL service management processes will be impacted such as technical and functional management, helpdesk and service management. Companies with shared service centered are more prepared for this, they give their SLA to the cloud provider.
market and how the cloud solution should be integrated in the information architecture.
People need to be educated. Parts of IT department will be unnecessary, which can be cause annoyance and you won’t be an all-round IT organization anymore. New processes and roles. The configuration of the applications and the migration of the data to the cloud applications are important and need to be taken into account in the business case as costs. Further suppliers need to be steered and contracts need to be monitored. Processes in a SaaS organization will be vendor management, finance, service level management, and the helpdesk. IT roles will shift towards
This is something that will be a major issue. The IT department will be downsized but we don’t know how to tackle this. Maybe they can be retrained.
Which agreements do you make with the supplier, what is the content of the SLA and other security and availability issues will be important.
156
monitoring the application market instead of requirements engineering. In fulfilling business needs. IT will become advisors to the business. Roles and responsibilities
Structure
It depends on where the organization comes from how roles and responsibilities change (e.g. SLA management). Cloud is often implemented within existing organization structure. Cloud center of excellence not seen yet.
Policies
Culture
Risk management
Different kind of culture of flexworking comes together with cloud computing, but is not caused by the cloud solutions. It is strongly connected to cloud implementation.
Not very familiar with risk
Service management will be an important role. Other ITIL supplier management roles could also be applicable.
The new roles should fit the new processes.
No cloud center of excellence.
Cloud is integrated in same organizational structure at the moment.
Because this is also a centralization project, there will be a central board which defines the policies. For us it will be important how the needs of the teachers will be translated to SaaS applications.
No unique risk management
We have a lot of privacy sensitive
Policies are already available in the organization such as QoS or security. They don’t need to be implemented for cloud computing, except for specific privacy policies, like audits. The culture of managing services will be more formal. The organization needs to professionalize the change management and portfolio management because of the client-provider relationship. They say it is important for
An existing risk
157
Cloud governance
management, cause it is another department within this company. But internal audit teams struggle with the fact that they have to depend on external audits. It moves towards certification monitoring which need to be trusted. Not known whether all controls are checked within these certifications.
cloud computing, but I don’t have any experience with it.
framework. Maybe higher impact for certain aspects than traditional computing. But security is very important. You have to evaluate whether the provider fulfills the security needs.
data. We sit together with the providers to discuss the risks. Also there are financial risks if the project won’t succeed. With the providers we are discussing a risk management framework, but in my opinion it is often saver than on-premise computing.
Cloud governance includes the business case, the readiness assessment, composing the contract, managing and monitoring the contract, evaluating whether the provider and the organization meet the contract and whether the service still fit the needs of the organization. Further ensuring the proper security controls in the SLA and monitoring of the risks.
Governance is the strategic path and how decisions are made. I don’t think a new kind of governance is necessary for cloud computing. It is basically a sourcing decision.
Maybe when an organization is a total SaaS organization things fill be governed differently. At this moment is about whether the standard application fulfill business needs and if the connectivity and security risks are acceptable.
The cloud solution must be strictly aligned to the needs of in our case the schools. Further, whether the agreements and the standards that are defined are complied to should be monitored.
management framework will be used. With customers, when they want our service, we will go through the risks identified by the CSA and ENISA etc. together with the provider. Customers are mostly dependent on certificates, but it is not sure what is audited. Cloud certifications will come. As audits done by the customer is expensive, they rely on certificates and logs, made by for example ClaudAudit.
158
SOA Governance / tools
It did not came across automatic monitoring of SLA’s.
SOA is the big movement and cloud can fit in a SOA, but not the other way around. However, it does seem logical to apply SOA kind of tools to cloud computing.
It will move towards such tools, but not on this moment, It is very premature.
We are moving towards a SOA. But there are no plans yet for SOA tools, that is far away. We look at the other similar projects what they do.
159
Appendix E: interview protocol (first feedback round) Research In my research for the Master Business Informatics at the University of Utrecht I, Steven Jol, am developing a ‘Cloud governance model’.
The cloud governance model Governance in this research is considered to be the involvement of top management in an IT investment; they have to evaluate the investment and assure the organization is set-up to ensure risks are being managed and the value is maximized. This model tries to assist topmanagement (probably CIO) with the governance of an off-premise cloud solution. What does top management need to do when adopting an off-premise (outside organization) cloud solution? They have to evaluate the cloud solution, implement processes, manage the risks, through ensuring risks controls are applied during adoption, and assure its value to the organization. A one-sheet table elaborated these elements and also some information is provided on the organizational impact, the risks and the business case of cloud computing to support the evaluation of cloud computing.
The interview The goal of the interview is to get feedback on the model. The questions involve three aspects:
Is it understandable? It is clear how to use and apply the model? Is it useful and is the information valuable? Does it contain the correct cloud governance/top management activities? Experts, is the information correct?
160
Appendix F: interview transcripts (first feedback round) CSO [User 3] Maak je onderscheid tussen public cloud en private off-premise? Outsourcing is dat eigenlijk. [Public & private] [Uitleg model & tabel & onderzoek] Voor mij is het hele begrijpelijk ja, ik vind het wel een mooie visualisatie van wat er allemaal bij komt kijken. Je kan er over twisten of bepaalde dingen iets later of iets eerder in het proces moet plaatsvinden. Zo’n data classificatie moet je al klaar hebben voordat je überhaupt kan nadenken over cloud. [Uitleg controls & adoptieproject] Verder vind ik het een heel duidelijk model. Het spreekt bijna voor zich. [Nuttig?] Dan zou ik het even moeten lezen. De business case is belangrijk natuurlijk. [Uitleg verschil adoptie project en governance en activiteiten] Precies, want dat wordt nog veel te weinig gedaan. Iedereen roept van ja we moeten naar de cloud. Dat wordt dan geroepen aan de bestuurstafel, maar met welk doel komt vaak pas later in het proces, waarom doen we het eigenlijk. Ook de begripsverwarring aan de bestuurstafel van als we cloud gaan doen wordt het goedkoper, nou dat hoeft helemaal niet. Zoals jij al aangaf, wat doe je met de mensen, wat heel belangrijk is. Zonder dat ik het heel gedetailleerd kan lezen, daar heb ik iets meer tijd voor nodig. Bij risks zie ik dingen als wetgeving. Om gedetaileerd te lezen heb ik tijd nodig, als ik meer tijd heb wil ik dat graag doen, zo op het eerste gezicht, hier mis ik niks aan. [Uitleg adoptie & bestuurlijke activiteiten] En in de bestuurskamer moet ook vastgesteld worden met welk doel, dat moet heel duidelijk zijn. Vooraf maak je een business case, op bestuursniveau moet je een duidelijk doel hebben, welk doel wil je bereiken, gaan de processen beter, ga je minder geld besteden loop ik minder risico’s. Dat zijn dingen die op moet op bestuurlijk niveau vastgesteld moeten worden en adoptie komt pas we gaan wel of we gaan niet. Je moet van te voren een doel hebben waarom ga je ergens naar kijken en dat is de start van je business case. Als je zegt ik wil op personeel besparen omdat ik die A niet kan krijgen en B omdat die zijn duur en C continuiteitsrisico’s dan kan je zeggen ik ga naar cloud of outsourcing. Dat zijn vind ik business drivers en dat is onderdeel van als je spreekt over risico management en ander reden kan zijn dat je veel meer geld kan beginnen en dat doe je aan de bestuurstafel. [Monitor op bestuurslaag?] In de praktijk denk ik dat het nogal tegenvalt, maar dat geldt niet alleen voor dit, maar met alles wat we doen met elkaar, we gaan iets doen, maar er zijn heel weinig die dan terug kijken van ja waarom deden we het ook alweer en hebben wij onze doelstellingen gehaald en kloppen onze doelstellingen nog bij een normaal bedrijf zie je dat aan de winst cijfers maar in het onderwijs is dat een stuk lastiger, maar als daar twijfels over zijn, hebben we genoeg winst behaald of hebben we verlies dan gaan ze naar dit soort dingen kijken maar dan is het eigenlijk al geen bewuste keuze meer. Zeker met een cloud oplossing moet je evalueren doe ik ngo wel de goede dingen en met de juiste partijen. [Risk management gedaan door bestuur?] 161
IN mijn beleving zie je een kentering, vroeger was het zo van ja dat doet de IT wel, nu zie je steeds meer dat ze aan de bestuurskunde meer aandacht aan besteden en in ieder geval controle uit oefenen. [Processen in voeren, gedaan door lager IT of bestuur? De lagere IT doen het wel, maar vanuit de bestuurskamer moeten ze wel op toezien dat het gebeurd. Wij zitten wel in luxe positie dat hier audit en controle zit en die bekijken dat soort dingen, maar wel in opdracht van bestuur. [Of is het management oversight?] In de praktijk is het vaker op laag niveau zo dat het als een sourcing vraagstuk behandeld moet worden, dat klopt ook wel, het hoort niet op de bord van de bestuur te liggen, maar ze moeten wel bewust zijn dat er wordt gekeken naar cloud en dat dat met de juiste argumenten gebeurd. Op het moment dat dat fout gaat, ze willen mensen ontslaan en alles in eigen huis doen, dat besluit moet in de bestuurskamer genomen worden. Als er lager in de organisatie er wordt wat gedaan op outsourcing dan moet het bestuur realiseren want zij worden er op aangesproken als er iets niet goed gaat. Ze moeten weten dat er met de juiste redenen dat pad bewandelen. Het ligt aan de organisatie of het bij de bestuur komt. Bij een normaal bedrijf doet het raad van bestuur echt alleen op hoog niveau dingen terwijl je hier hebt dat het raad van bestuur gaan we met aanbieder xyz mee in zee en dus ook met outsourcing. [Als raad van bestuur ook providers kiezen is dat dan ook governance?] Ik zou die governance activiteit wat wij hier noemen middel management zien en dat wordt later gecontroleerd door auditors, dat zit op een andere laag. [Zijn dit de juiste bestuurlijke activiteiten?] Ja, maar het ligt wel aan hoe je organisatie in elkaar zit. Bij sommige bedrijven zit CIO in raad van bestuurd. Dat is hier niet het geval. Bij een normaal bedrijf is vaak je organisatie heel anders. [Hoe werkt het bij jullie bij een groot project?] Dat is een raad van bestuur beslissing, Überhaupt gaan we dat doen. En dan geven zij aan van ja we willen dit soort risico’s niet lopen, het mag geen personeel kosten of wel en dat soort randvoorwaarden wordt vanaf dat niveau meegegeven en de uitvoering van dat soort controls worden daaronder ingericht. Je kan het ook laten afhangen van het proces. Heeft een onderzoeken ene servertje nodig dat kan je in de cloud regelen, daar hoeft het bestuurd druk om te maken maar op het moment dat er besloten wordt om studentenadministratie of we gaan onze financiële administratie in de cloud regelen dat moet je bestuurlijke op het hoogste niveau beslissen. We zien nu in de situatie dat we dingen hebben uit besteedt, een private cloud geoutsourcet, natuurlijk wordt er sterk naar cloud gekeken, maar als we onze studentenadministratie in de cloud willen hebben dat besluit wordt wel door het bestuur genomen, ook al is dat alleen de IT verantwoordelijke. Maar dat is niet altijd duidelijk, wie er precies verantwoordelijk voor is. [Welke processen ingevoerd voor cloud oplossingen? Klopt service management als run?] Je moet je service management sterk maken, uiteraard security management, er is eentje waarvan ik niet weet of je die apart moet benomen, functioneel beheer blijf je zelf doen tenzij je heel het proces uitbesteed, dat noem wij vaak zelf, of je dat nou doet door service management. 162
Zeker als je naar ITIL kikt dan lopen die kanalen vaak via service management ook in de praktijk zijn het vaak geen aparte lijnen. Maar formeel, en bedrijven die diensten leveren doen het allemaal via service management. [ITIL life cycle] Dat vind ik tijdens de run. Je noemde twee dingen, capacity management, tijdens design doe je dat natuurlijk ook, maar tijdens run als je het goed doet leg je bij de leverencier neer. Design blijf je zelf doen. Dat keert steeds terug. Bij het maken van een business maken maken wij geen ITIL voor, dat doen we projectmatig. [Risiko management en governance? Is governance enerzijds ook risicomanagement?] Ook daar begint het bij bestuur om daaraan randvoorwaarden te geven en daarna kun je het lager neerleggen om dat uit te laten voeren en management maar op het moment, zo gaat dat hier, dat daar conflicten zijn en fricties, of wat dan ook, die niet met die randvoorwaarden zijn in te vullen dan ga je terug naar bestuurstafel hoe ga je dit mitigeren. [Risico controls nuttig voor bestuur?] Weet je wat ook een rol speelt, om hoeveel gaat he. Kijk als het over lager bedragen gaat dan houdt het bestuur er niet mee bezig, gaat het over reputatie dan willen ze het wel weten, gaat het over grote bedragen willen ze het zeker weten. Ze moeten op z’n minst geïnformeerd worden over risico’s. Ze moeten zeggen als ik risico’s loop boven bepaald bedrag moet ik het weten. Ik wil absoluut geen reputatieschade hebben. [Risico controls cloud voor bestuur?] Ik denk dat dat voor veel bestuurders niet heel nuttig is. Als ze het wil weten of als ze het heel nodig hebben. (Als ze het willen weten is er interesse.?) V or IT managers is dit hartstikke relevant. De CFO”S zit er vaak tussen. Die moet wel ongeveer weten hoe het werkt. [Is CFO governance of management activiteiten?] Ik vind als je over dit soort dingen hebt zijn het governance activiteiten. [Awareness model voor board nuttig?] Ja, absoluut. Er wordt natuurlijk wel over gesproken met elkaar. Ook al komen ze elkaar tegen bij de golfbaan. Hey doe jij nog wat met cloud of heb je gelezen, zus en zo. Ja hoor, ik heb gelezen dat Amerika half internet afluistert. Doe jij wat aan de cloud?
Strategic IT advisor [User 5] [Uitleg onderzoek]. Als je het hebt over governance model, gaat het dan om de implementatie? [Implementatie en na implementatie] 1 maar, van cloud computing heb ik nooit specifiek de processen bekeken, ik eb te maken gehad met client/server oplossingen en nooit de doorstap gemaakt naar cloud computing. [Uitleg onderzoek is evaluatie] Wat specifiek voor cloud computing kan ik moeilijk over oordelen. [Uitleg gaat om snappen] 163
[Uitleg direct evaluate and monitor] [Uitleg model] Waar zit de relatie met ITIL? [uitleg service management] Je zit met een project kant en day by day opersation kant. Dat werkt toch enigszins anders. Bij project management heb je sterker governance dat je moet vast leggen, dat is ontwikkeling en implementeren, en naderhand zit je in de beheerssfeer waar je veel globalere afspraken maken over governance, in hoeverre dat verscheelt bij cloud kan ik me wel wat bij voorstellen, dat het laatste wel wat kritischer wordt, bv incident management. Bij strategie ga je je afvragen, de business case heb ik gezien, maar je gaat je ook afvragen wat voor service pakket, service definition ga ik aanhangen, de klantrelatie, wat wil de klant, hoe definieer je dat dan, de business case wat wordt ik er beter van. Dat valt ook onder het project. En je hebt strategie, dan design, transition dan moet je alles live krijgen. Als je het over service organisatie hebt, ICT service organisatie, die een bepaalde dienst willen uitvoeren voor hun klant, dan is er al veel geïmplementeerd in hun service organisatie, dan moet het alleen maar gematched worden in de processen die al draaien, dan is het al enkel de nieuwe dienst die geleverd wordt. Er is al veel ingericht, capacity en availability management, dan hoef je alleen stukjes toe te voegen. [Snap je het model?] Ik moet er nog eens rustig naar kijken, je overvalt me ermee. Ik moet er rustig naar kijken, ik kan mij voorstellen dat het redelijk afdekt, maar of het samenwerkt zo met elkaar zo dynamisch weet ik niet. Het staat er wel allemaal, maar klopt het zo. [verdere uitleg model] Ik vind het lastig hoor. [nuttig?] Zeker hele erg nuttig. Ik denk zeker dat het heel erg nuttig is, maar of je kan slagen om het zo in tweedimensionaal kunt brengen, vind ik een hele uitdaging. Daar moet ik over nadenken of het zo op die manier in de praktijk werkt. [Nieuw model].
CIO [User 1] [Is het model duidelijk?] Dit is het resultante van een heel denkproces, je moet ons een beetje meenemen onderweg. We praten hier intern over praatplaat, het is niet het eindpunt, maar hier ga je discussies met mensen voeren over het onderwerp. Als ik heel flauw ben, hoe topper de manager, hoe minder laagjes, deze twee binnenste cirkels vind ik te informatiedicht, vind ik teveel. Dat vind ik puur grafisch Als je dit tot 1 terug kan brengen, dan zou ik dat doen. Of een aanvullende plaat, daarop inzoemend is dit. Je wilt gaat alles in 1, kijk is wat ik gemaakt hebt. Maar als je zegt het doel is een van de moeilijkste dingen in onderzoek, je hebt zo veel gedacht en uitgevonden en dan moet je dingen los laten. Dat vertel ik even niet, dan komt de boodschap beter over. Ik schrijf eerst een stuk, het eerste wat ik doe, dan stop ik alles wat ik briljant vindt, daar maak ik een bijlage van, dat vindt ik ook zonde, man dat moet toch de wereld weten.
164
Misschien heb je wel twee modellen. In mijn feedback heb ik retrieved dit is te gedetailleerd voor top managers. Stel jij staat je scriptie te verdedigen, of hoe dat werkt, en je vertelt dit is een governance model dat moet topmanager moeten helpen, weet ene topmanager ‘CSP’? Daar moet je zelf kritisch naar kijken. Is dit bedoelt voor top manager of CIO? [Uitleg] In hoeverre is dit vernieuwend dat dit anders is? [Uitleg niet enkel risico’s] Je zegt adoptie traject, bij wie je dat moet brengen, dat hoort niet bij top manager? [Uitleg adoptie project is operationeel] Waar jij vandaan komt wordt governance vaak gepositioneerd als risks management, waar ik vandaan kom is governance alles en risk slechts een stapje. Deze vier stappen lijken heel erg op plan do act check. Governance is voor mij hoe krijgen we dingen hier gedaan. Daar kan je woordjes erbij en eraan plakken, dan ga je iets inperken. W hebben ICT governance, dat is mijn verantwoordelijkheid, dat we demand en supply de processen goed op orde hebben. Risk is een klein deel. Governance is ook iemand wil een nieuwe opleiding starten, hoe doen we dat dan? Is jouw model een cyclisch model, met een volgorde, of niet? [Uitleg model] Dus er zit een volgorde in? [ja] Maar hier ben je aan het denken over, hier zit je in plan. Wat managers helpt, dat je aansluit op dat, dat soort eeuwenoude, dit kent iedereen wel, iets in je fasering terug laat komen wordt het model stuk duidelijker voor ze. Dat hoeft niet helemaal te overlappen. Ik merk sowieso, evalueren is een link woord, ik zie het altijd als aan het einde. Je bedoelt hem aan het begin, je bent de propositie aan het evalueren. [Bruikbaar?] Ja. Een van de belangrijkste dingen dat je hier zit, is dat dit bij mij speelt. We zijn bezig met cloud strategie. Toen ik hoorde van dit onderwerp, is het altijd handig, ik ga er ook door doordenken. Nu direct dit model, ik denk dat je nu twee stapjes te gaan hebt, dat je meer focus hebt van je boodschap, wat heb je nou te vertellen. Al die lagen, of je moet het opsplitsen, ik heb misschien een paar dingen te vertellen, maar in 1 keer is teveel. Ik denk dat je het best ook kan richten op doelgroepen, bedenk goed welke doelgroep je wilt benaderen voor het onderwerp van je plaat’. Wat ik denk dat mijn een van mijn belangrijkste toegevoegde waarde is voor mijn managers, is om het steeds simpeler te maken. Als ik met externe werk, hebben ze allemaal dit soort modellen. Dan zeg ik stop, keep it simple en stupid. Dat je uiteindelijk hier op uitkomt, als je niet iedereen meeneemt, verlies je de helft van de mensen in de discussie. Ik denk dat de uitdaging eerder zit in dat je een complex verhaal makkelijk kan vertellen dan dat je een complex verhaal kan maken. Het onderwerp zelf is heel relevant. Als je hier een stuk uit kan 165
destilleren voor bestuurders, dat gaan mensen graag downloaden, probeer ik hoor het ook in je verhaal, dat je teveel verhalen te vertellen hebt, haal die uit elkaar. Je hebt teveel verhalen te vertellen, maar dat betekent niet dat het geen goed verhaal is. [Governance activiteiten, kloppen die?] Dat is leuk dat je dat vraagt. Heel gemeen, nee. Dit vind ik jouw zwaartepunt rondom governance. Ik merk dat bestuurders snel zeggen het niveau eronder ik neem aan dat dat geregeld is. Mijn bestuurders liggen wakker van bepaalde aspecten van risk management, maar zolang wij ons werk goed doen boeit het hem niet. Ik moet het hem in bewustzijn brengen, anders is het geen bestuurlijke activiteit. Dit wel, waar gaan we met de business heen en wat willen we bereiken, andere dingen njiet. De rest duwen ze weg. [Vanuit jouw laag wel relevant?] Ja, maar jouw vraag: wat is bestuur? Als je het over bestuur hebt heb je het over raad van bestuur en die zijn met name bezig. Ook gek he, ook daar, we hebben ene heilig beeld, dat zijn mensen die soms hele ad hoc gedreven zijn, ene professor die vals speelt, dan kan risk management opeens heel belangrijk worden. Het is ene illusie dat die mensen altijd langs dit soort cirkels denken, die hebben heel veel aan hun hoofd dus willen het heel simpel horen: heb jij het geregeld? Ok, dan hoef ik mij geen zorgen te maken. De vraag voor jouw is, welke boodschap wilt jij vertellen? [Governance niet duidelijk voor wie] Wat is jouw onderzoeksvraag? [Uitleg] Je ziet nu ook duidelijk dat je twee heren wil bedienen. Twee vragen en 1 antwoord is lastig. Het helpt jouw als je onderzoeksvraag scherp krijgt en vanuit die lijn denkend: geeft dit antwoord op die vraag? Een bestuurder boeit niet met de implementatie. Ik denk dat jij gebaad bent met werkhypothesen, wat is governance? Board level, en IT governance. Board level is veel meer het domein, waar gaan we naartoe, waar gaan we heen en is gericht op risico gericht, IT governance is meer gericht op inrichten van IT. [En op IT Governance niveau?] Ja, cloud evaluatie hoort binnen cloud sourcing strategie. Daar horen bij rollen en verantwoordelijkheden. Ik kan ook nog meer downdrillen, dan nog zou ik zeggen haal het uit elkaar. Maar de CVB governance is input, stukje strategie, en daar heb je op ICT gebied mee te maken. Je ICT strategie moet binnen die strategie passen. Er is ene bedrijfsbrede governance, als het goed is komt daar uit waartoe waarheen en daarbinnen heb je daar toe aan te houden binnen de ICT afdeling en cloud is daarbinnen een mogelijkheid. [Governance op board is niet heel anders toch?] Wat ik wel eens hoor in de grote boze wereld, is de vraag nu een disruptive tehcnology of niet? We hebben investeren, nieuwe gebouwen, nieuwe systemen, dat veranderd niks aan de kant van mijn business in onze wereld moax, de nieuwe e-learning, dat het de fundament van mijn business aanpast, bij cloud zeiden ze ook oprecht, het feit dat studenten, medewerkingen dingen uit de cloud halen dan veranderd het fundamenteel hoe je bedrijfsvoering in elkaar zit. We hebben daar geen duidelijk antwoord op. Ons antwoord op dit moment is langs dit soort aspecten. Heel serieus als ICT nadenken en dat als gefundeerd antwoord te geven aan de busines op hun vraag doe alles in de cloud. Ik ga er niet vanuit dat de board echt nadenken over, maar die worden gestuurd dit is een ontwikkeling en die 166
vragen aan de ICT geef hier eens een goed antwoord op. Je bent meer model bezig geef een vakmatig antwoord terug dan hoe regelen we cloud governance op de board level. [Wat doet de board?] Ik weet het niet. CMMI kijken meer naar volwassenheid van de organisatie, ccm in vijf stappen, vier en vijf zijn is alles dood georganiseerd, ik stop er iets in en er komt altijd hetzelfde uit. Wij als xx zitten in 1 en twee, 1 is ad hoc en helden gedrag, 2 processen zijn beschreven, 3 is wij handelen volgens deelprocessen, hele veel organisaties proberen op 3 te komen. Hoe werkt het op board level, ik denk dat zij op dit niveau acteert, board zegt ik wil dat organisatie op 3 werkt. Wat ik zou willen dat de board doet, noem ik het heel plat, ik vind dat zij er voornamelijk moeten druk maken om wat er moet gebeuren en dan voor ieder vak, ook de IT, zich druk moet maken over hoe ze dat doen. Cloud is voor mij een hoetje, zolang het geen disruptive technologie is ik vind dat echt geen board of directors topic. Als je de 9 vlaks model pakt zit hier de CIO, hier de CEO en hier de IT director. Hier wordt de wat vraag gemaakt, mijn rol is om de wat vraag te vertalen en deze knakker mag bepalen hoe. Hoe ding wordt vaak gezien als wat, we moeten cloud, wat wij terug roepen is welke business need zit erachter. Cloud evaluation, hoezo dan. Dan wordt het al snel dat gaat euro’s schelen, dan gaat het niet om cloud maar kun je besparen. Laat ons dan bepalen hoe we dat doen. Het gaat dus meer om awareness kweken, het is geen wat vraag.
CFO [User 2] Wat mij opvalt, in statisch overzicht, de Excel sheet, staan alle ingrediënten in. Dit klopt wel. Wat er eigenlijk verbetert kan worden, Hier lopen twee dingen door elkaar. Het proces van introductie en integratie, de fact finding, business case bouwen en twee het managen van what ever is in the cloud. Ik heb het opgeschreven. Aller eerste opmerking is de governance zelf. Je zou een alignement moeten vinden met het enterprise governance framework. Dit is erg binnen IT gegeven. Ik zie geen connectie met het enterprise governance. Governance wordt hier gezien als het aansturen van het proces. Dit stappen herken ik. Maar governance gaat ook over besluitvorming. Je zegt het gaat over de betrokkenheid van de board, maar wie heeft welk mandaat. Bijvoorbeeld het investeringsvorm, go/nogo momenten. Wie bepaalt wat? Dat zie je dus niet. [Uitleg enige wat hier terug is processen voor de cloud] Governance is de totale samenhang van processen, die beheersen de besluitvorming. Dat zie je dus niet. Het gaat ook over projectmanagement. IT heeft een gezonde spanningsveld met de business. Wie heeft de verantwoordelijkheid? En de prioriteit. De business case leest ook zijn blaadjes; ja goedkoper! De IT zegt weer ja maar risico’s. De business case moeten beide mee eens zijn. Voordelen zijn niet alleen minder IT mannetjes, maar de business zegt ook ja we kunnen sneller transacties uitvoeren. Governance is meer dan enkel de proces stap van cloud invoeren. Ik snap het wel, het gaat om cloud invoeren, dit zijn de stappen die je moet doen. Verder probeer je ook statische en change door elkaar te zetten. Adopted zet je cloud evaluatie. Maak onderscheid tussen run and change. [Uitleg risico controls en adoptie proejct] Je vraagt is het me duidelijk? Nee dat is het dan ook zeker niet. De adoptie project is niet alleen van belang voor de risico’s. Ik zou de projectmanagement cyclus op de grond zetten en dan deze cyclus erboven. Deze zijn opzich valide. Hieronder de change en run uit elkaar trekken. Dan doe je recht aan hoe het in de praktijk gaan. We hebben aantal cloud oplossingen en die hebben we eens besproken en daarna is het geen issue meer. [Uitleg monitoren vanuit coso framework] 167
Dat is nog steeds wel run. Je inventariseert de cloud oplossing, je bouwt de business case. Dan zeggen we doen. Inrichten van SLA, verantwoordelijkheid van CFO en IT, is projectmatig. Inrichten van processen is allemaal projectmatig. Eenmaal in place is het run geworden. De change, Deze cyclus geldt ook voor opstellen Sla’s, opstellen KPI’s, requirements opstellen, daarna is het bijstellen. Je moet aansluiting zoeken bij life cycle management. Dat wil zeggen je hebt een start, dan heb je onderhoud een run, en op een gegeven moment loopt dit ook af. dit kan om een servertje staan kan ook om een service staan. Die connectie moet er zijn. De cloud, ik ken de rest van de documenten niet, je hebt een gebruiker en de IT afdeling die in zijn backyard internal en external capacity heeft en die treedt op als een traveling salesman om met de business eens te worden, die moet naar de requirements kijken enzo. Die managed de supply, ook als het cloud is. Je kan verschillende cloud providers hebben. Dit hele stuk moet hierin embedded worden. Ik verwacht dat hier iets omheen komt, enterprise governance framework komen. Als die zegt, zo doen we dat, dit doen we nooit. Er is een noodzakelijk verband. [Die zegt, wie doet wat? En policies? Ja ja, we outsourcen nooit. We offshoren. Maak onderscheid tussen change en run. We hebben hier een service en dat hoort hierbij. Als het puur om cloud gaat dan zoomt dit goed in. Maar vanuit top management perspectief, kan je dit niet doen zonder te kijken wat company wide wordt gedaan. Dit is aardig voor chef-IT. Die gaat niks doen, zonder dat de board of It director heeft gezegd en die valt onder het juk van enterprise governance framework. Bijvoorbeeld finance en risk willen wat zeggen over de business case, Governance gaat over betrokkenheid en accountability. Dat betekent in een business case willen we alleen cash zien. Al die dingen worden afgesproken en wie heeft de verantwoordelijkheid. Is het CFO only? Nee het moet zijn business CFO, CIO en business. Wat ik heb gezegd heeft betrekking op alles. Het moet een afgeleide zijn van de overall governance. [Uitleg governance zijn de maatregelen] De maatregelen zijn geen governance. Ik denk wel dat al die beslissingen voortvloeien uit governance. In die zin wordt het onderdeel van governance. Onder welke voorwaarden mogen we deze cloud service verlenen. Inderdaad als je COSO als vetrekpunt neemt dan betreft dat de hele company. En dat splits je op in totaal en divisies. Dat is hier ook van toepassing, als de cloud governance een cube zou zijn in het totaal van de enterprise als je die link legt zie je de afhankelijkheden die van invloed zijn op de business case, risks controls en KPI’s. Welke KPI’s? En beslissingsbevoegdheden. Heeft de CIO een eigen IT budget of is het afhankelijk van de business voor geld. [Zou je dit wel cloud governance noemen? Niet adoptie model?] Eigenlijk is dit adoptie model. Ik zie hier processen, het zou eerder cloud management en niet cloud governance noemen. Ik denk wel dat het heel belangrijk is dat er cloud governance is. Het wordt door veel mensen gezin als walhalla en weten dat er risico’s aan zitten. Maar governance op zichzelf, omdat het cloud is raakt het de business, IT heeft risico’s. Maar uiteindelijk, als cloud genormaliseerd is, maakt het uit onderdeel van het totaal. [Governance/management verschil?] Als je als uitgangspunt neemt dat governance is het structureren van je besluitvorming en de afspraken die je maakt, dan heb je een goed onderscheid tussen hoe doe je dingen. Hier kan je ook offshoren neerzetten. Dat is ook een heikel punt. Dat moet gemanaged worden, risico’s, moeilijk moeilijk. Maar het onderscheid tussen hoe geef je vorm aan besluitvorming, wie zat in welke board, Dat staat los van dit. Dit is implementatie, maak daarom onderscheid tussen run and change. Dan heb je proper housekeeping voor ene nieuw verschijnsel. Maar terecht wat e zegt, tot welk niveau moet wie van wat weten. Ik laat web hosting voor het aanmelden van events. Ze hebben geen idee dat er klantgegevens
168
inzitten en dat er risico’s aan vastzitten. De noodzaak van die risico’s is groot. Maar de governance, strikt genomen ik denk dat je niks aan de governance hoeft te doen. [Zou het misschien gebruikt kunnen worden voor awareness?] Ik zou zeggen van hoe kun je zorgen dat in de onderneming die er toe doen, binnen de CIO functie om die awareness te creëren dit zit er aan vast. Maar ook dat er binnen de governance die er bestaat, binnen welk niveau nemen we beslissingen over de Cloud. Als je het over cloud governance hebt, daar moeten we iets mee, grenst aan outsourcing, aan offshoring, waar laten we de besluitvorming vallen. Dan heb je de raakvlak van cloud met governance. Een awareness model is meer change, is duidelijk maken, leadership van CFO. Als het gaat over governance dan hoef je die awareness niet te doen. Dat is meer een communicatieopdracht van de CIO. Bijvoorbeeld iedere CIO is gemandateerd dat elke CIO mag SaaS invoeren. [Dat is dus de laag erboven]? Ja, dat klopt. Dan eronder zit je bij project management, steering committee. Het is de microgovernance die er omheen hangt. Toen je zei de betrokkenheid van top management. Ja, alleen bij de eerste keer bemoeien ze er mee. Daarna niet. Management, onze MT, waar gaan we over, strategie. Als dit gepasseert is, komt het niet meer op tafel. Tenzij iemand zegt business case is omgeslagen, of cloud provider lock-in. Zolang je als MT hebt besloten we gaan die weg op en het is belegt in de operatie dan zit er iemand op tafel en die heeft in de portefeuille die zegt niks we gaan ervan dat is goed. Dat is niet helemaal waar, we krijgen wel rapportages, we zijn niet blind ofzo. Maar als de prijzen van een provider bv opeens omhoog schieten, dan ho dan gaan we naar alternatief kijken. Dat komt op de tafel van de boards. Maar dat is management. Governance is dat we hebben besloten elke maand de architect advies geeft voor besluitvorming. De borging dat er geen overhaaste beslissingen worden genomen zit in governance, daarom is dit van belang. [eigenlijk is dit cloud management dus] Ja, ja. Dit had ook outsourcing kunnen zijn. Een vrij goed generiek model. [Om het na te lopen, tis moeilijk te begrijpen, informatie klopt, maar geen echte governance] Het is een zoom van het totaal. Als je de governance van het bedrijf hebt. Dit bepaalt waar de CIO zit, wat is de connectie met de finance? [De processen zitten op hoger niveau?] Als je ITIL goed hebt ingericht, dan is er geen revolutie. De revolutie zit em in de awareness., wat betekent het, wat zijn de risico’s. Risk management is heel belangrijk. Als risk management zegt vanaf hier mag je verder. Het is niet anders dan outsourcing. [Awareness model?] Deze initiële fase dat is de intro. En dan krijg je communicatie. De borging zit op board niveau. We willen pas dat er besluit worden genomen als de architecten er wat over zeggen. Wat kan, is dat ze zeggen tegen de CIO, dan zeggen de MT leden, CIO doe er wat aan. Als volgt hoe we het doen, architecten brengen het in, de MT kiezen de solution. We brengen het als voorstel in de board. Je wilt niet dat er geen draagvlak is van de board. De borging van de besluitvorming is belangrijk. Het mandaat van de architect is ik geeft het advies en niet eerder wordt er iets besloten. Dan in de MT van de CIO wordt besloten alles wat je noemt, dan wordt dat vertaalt in een voorstel voor de board en dan mag je verder. De connectie met de algemene governance kan je niet los zien.
[Cloud governance is onderdeel van It governance?] 169
Het is inderdaad wel governance hoor, het is governance van het niveau het is er, het bestaat en de organisatie gaat er mee om. Daarom zeg ik. In de run past dit, de change zit er ingewurmd, dat moet je er uit houden. En daaromheen zit de enterprise governance. Dit klopt, maar het is te weinig. Dit is belangrijk dit geeft de speelruimte voor de mensen daarboven, Hoe veel geld hebben we überhaupt voor IT? Zit de CIO in de board? We hebben situaties dat de CIO aan de CEO rapporteert. [ITIL is governance?] Is IT governance, binnen IT. De CIO heeft ITIl ingevuld. Die praat Jip en Janneke taal naar de board, om dat duidelijk te maken naar de board. De governance geldt voor CIO, CEO, CFO, CR, moeten aan governance houden. Wat ik al zei, is de structurering van de besluitvorming is governance. De cloud is een manier om je doelstelling te bereiken. [wel cloud governance?] Ja, wel op run niveau. [Verschil governance en management?] Governance is dat je afspreekt, Zelfs op SLA niveau, wie zitten hier aan tafel om de performance te evalueren? Wie tekent de SLA af? Wie spreekt er af dat we geconformeerd hebben aan de SLA? Moet dit de CIO zijn? Wanneer besluit je dit? Eenmaal in place, eenmaal in kwartaal zitten we aan tafel. Wie zitten er? Wie van de provider? Wie van onze kant? Governance van project management heb je ook, wie besluit no/go moment. Wie is er bij betrokken, wie heeft het mandaat. Dat is governance. [Security controls, wie is verantwoordelijk?] Je hebt micro, meso en macro. Wie is verantwoordelijk voor controls. Op welke voorwaarden kan iets door gaan? Welke lichamen zijn er in het leven geroepen om iets te valideren iets goed te keuren. Stel je voor er komt een internal auditor, die vindt een fout ergens, die rapporteert ergens, management geeft antwoord en het wordt gemitigeerd. Heeft ie nu een bevinding, zolang hij nog niet gerapporteerd heeft aan de board? Nee, de governance zegt dat iets een feit is zolang het niet gerapporteerd heeft. [Heeft de board een management functie?] Ook dat is governance, onderdeel maar verstrekkend, dat de CIO of dat de business verantwoordelijk is voor de volgende zaken. Als uit de monitoring issues komen, dan blijkt uit de mandaat oh dit gaat boven mijn mandaat. Bijvoorbeeld incidenten vanaf een miljoen gaan naar de board. Database is gehackt alle credit cards liggen op straat, dat moet naar de board. Maar het netwerk ligt eruit, dan moet rapport worden dan blijft binnen de MT. De governance regelt dat dat soort incidenten binnen de afdeling afgehandeld moet worden. De governance bepaalt wat een rapportable item is, zoals reputational damage. [Businescase, organizational impact, risks?] Het is kip of het ei. Er is eerst een governance en dan komt er nieuw element, daar wordt bij stil gestaan. Wat betekent dit, hoe raakt het de bestaande governance. Zijn er aanvullende dingen nodig, zeker vanuit risk en IT, voor finance niet zoveel. Dan wordt er vanuit de bestaande governance aanvullende maatregelen afgesproken. De evaluatie en stilstaan gebeurd op dit niveau. De CIO is aangever is, het is een IT ding. Architecten die iets voorstellen en krijgen weer wat terug. Dan is er een heel cyclus. Eventueel wordt dan maatregelen genomen voor governance. Het is alleen governance, waar ligt de besluitvorming. De governance zegt hoe ziet de business case eruit. Wat is je windows, 5 jaar, tien jaar. Governance is een misbruikt woord. Het betreft nu waarover we het hebben. Als je het hebt over we hebben een business case, risico’s, we organizationele impact dat wordt in kaart gebracht, maar de besluitvorming erom trent, maar het kip en ei verhaal is hoe vindt 170
men binnen governance hoe wordt business case in kaart gebracht. Theoretisch, strikt genomen, kan het zijn dat als ze voldoen aan governance in place kan het lager worden beslist van een cloud oplossing. Maar eigenlijk kan je niet zonder board met cloud in zee gaan, maar dat staat dan in governance. Ze zijn wel benieuwd, die business case die we hebben, hebben we die gehaald? De value assurance bv, die is voor hun wel van belang. [Kunnen ze hun governance afstemmen op basis van de organizational impact, business case, risks?] Ja dat kan. Ik veronderstel dat hier een CFO en CIO in de board zit. Die doen het met risk vertegenwoordiging en finance vertegenwoordiging. Er komt een voorstel die ze moten erkennen. De governance zegt dat het enkel ok is dat de board moet instemmen. Life cycle management zegt wat is dan de introductie. Wat kost het dan? Gaan we tweede provider aanzetten? [Kijkt de board naar orga. impact? Ik denk de eerste keer dat de CIO en CFO een opvatting hebben, die geven presentatie in de board en vertellen wat het is. [CFO kijkt naar orga. impact en business case?] Op board niveau kijken ze heel high level. Dat die aspecten besproken moeten worden in de board. Wil je tot besluitvorming willen komen, dan wil je die dingen willen weten. Jouw model, zou gebruikt kunnen worden als voeder voor die aspecten, business case, risico’s, organisatorische impact. Om ze ene globaal plaatje te geven. Jouw model klopt wel, als nieuw fenomeen is moet je dit allemaal doen, maar dit hoort ook bij outsourcing. Hier hangt governance binnen, wie is bevoegd bij de Sla’s bv. Primair als plaatje is dit een management plaatje. Onze management weet al hoe ze cloud moeten aansturen, Het gaat er om dat ze als organisatie als geheel ziet ja we gaan het doen en op die en die terreinen want we denken dat we erop vooruit gaan, maar hoe je het aanvliegt dat dat is al bekend. [Dus awareness model?] Ik heb meer probleem met de schil erom heen. Bv IT avoidance. IT wordt overgeslagen door de business. Maar als je praat over awareness dat moet in de board gebracht worden, dat is de taak van de CIO. Ah, dat betekent het dus, dan mandateren wij en dan kan iedereen zijn gang gaan. En gebeuren de stappen uit jouw model. Dit is allemaal het gevolg van iets. [Is risk management niet ook governance process?] Je moet onderscheid maken; binnen IT heb je security operations, die eerst lijns risico management doet. Dagelijkse praktijk, data wordt gecheckt, wordt dagelijks back-up gemaakt, gebruikt niemand zelfde password etc. Ook managen testen van netwerklijnen en praten met corporate audit services. Dat is geen governance, maar er zit governance omheen. Zoals wat doen zijn. Dan komt de tweedelijns, wat hebben jullie gedaan eerste lijns? Die werken ook samen met corporate audit services. Dan komt de derde lijns dat zijn de accountants. De eerste lijns en tweede lijns werken samen. Governance zegt wat is de eerste lijn verantwoordelijkheid van en wat is de verantwoordelijkheid van tweede lijn. Een hoop non-native speakers gebruiken het ook in de zin van overzien, dat is een andere type governance dan corporate governance dat gaat over beheersing. Engelse talige schrijvers gebruiken corporate zoals het hoort. [Dus dit model is meer overzien eigenlijk?] Ja, idd, dat is geen technische governance aspecten. 171
[orga impact, risks, business case; awareness model?] Nee nee, het gaat over structuur. Hoe veel mensen minder hebben wij? Structure follow strategy. Je moet awareness over hebben, waar ook risk bij hoort. Wat ze willen weten is, we hadden 1000 man we gaan naar 800 man. De besparing is zoveel miljoen. De orga. Impact hangt samen met de business case. Je hebt ook accepted risks. Die hebben bepaalde looptijd. Als we nu overstappen hebben we die risico’s, we hebben nu migratie risico’s. De board moet die accepted risks accepteren. De presentatie van de CIO in de board, bestaat uit de risico’s (accepted)., orga impact en business case. Jouw model is nodig om dat verhaal te houden bij de board. Dollars, fte + risico’s. Je moet ground up werken. Hebben zoveel mensen nodig, SLA’s Bijzoveel taken heb je zoveel mensen nodig. Wat is de rekening nu die je aan Amazon betaald en dat verglijk je met hudige situatie. Dat is de business case. Dat is impact op de FTE, dat zijn de risico’s. Dat plaatje moet daar geaccendeerd worden. En daar komt besluit uit en dan krijg je de governance. Dat is het groter plaatje. Als je bij het groter plaatje hebt, heb je initial, awareness, dan heb je 1, wat je oplossingin zijn, dan 2 is invoering, de change of implementatie en dan heb je management. Daar horen verschillende plaatjes bij, althans verschillende stadia. Vier is weer change, je hebt altijd beweging. [Dus dit model is meer voor lager management?] Ja, als je het hebt over betrokkenheid. De board die voorwaardenscheppend is voor de IT manager, die handelen in de context van corporate governance. Daarbinnen, eenmaal mandaat gekregen gaan ze op grond hiervan aan de slag. De business case is er op macro niveau. Daarna komen er gedetailleerde business cases voor de verschillende providers, dat kan binnen de CIO gemeenschap. Dan kan de corporate governance zeggen beslissingen boven tien miljoen gaat naar de board. Iedere fase heeft andere betekenis. In de run is alles ingekapseld, dan gaat er niks naar boven. [Dit model voor board?] Ja, zo ziet het er operationeel uit. Dan ga je naar meso niveau. Dan wordt het een rondje. Dit is inderdaad operationeel.
Security project manager [Expert 6] Wat mij opviel is: waar begin ik? Toen ik het model zag, waar begin ik? [Uitleg] Wanneer in een project ga ik dit model toepassen? Stel een cloud oplossing wil ik voor een bepaald proces hebben en dat werk ik uit in een plan. Wanneer gebruik ik dit model? Tijdens het plan? [ja] Dus deze aspecten neem ik mee in het plan? [Ja, de assumptie is nu dat er operationele aspecten zijn , het adoptie-project, en governance activiteiten] Dus ik heb hier ‘start project’? [Voordat het project wordt cloud al geëvalueerd] Mijn feedback is dat dit niet duidelijk voorkomt in je model. Het is niet meteen duidelijk waar begin ik. Een tool komt niet uit de lucht vallen en het is er. Er is eerst vooronderzoek, past het in onze enterprise architecture, je hebt bepaalde fasen in een project, van start het idee tot goedkeuring van het management. Welke aspect pas ik toe in welke fase van het project. [Uitleg dat er vanuit is gegaan dat het project pas na evaluatie komt] 172
Hier zie ik SLA en hier zie ik service management. Heeft deze dan met hem te maken en deze met hem te maken? [uitleg van security controls] Wat onduidelijk is. Is je categorisering. Ik zie hier SLA terugkomen en hier SLA terugkomen. Het is voor mij nu onduidelijk wat ik nou moet afdekken. Waar komt het toepasbaarheid van de cloud oplossing binnen Enterprise architecture. [Uitleg zit in business case]. Ah ok, het zit er wel in. Kan je het niet met pijlen aangeven? 1234. [Uitleg risico controls] Welke literatuur heb je daarvoor gebruikt? [Uitleg literatuur] Ja, ok. Dus deze vier hoort bij het monitoren? [Uitleg security controls en verhouding tot project fasen]. Ah, vandaar de kleuren hier. Dat dit rood rood rood is. [Hoort dit operationeel project als aparte geïmplementeerd iets of zijn al die governance aspecten niet onderdeel van het project?] Normaal lever je een business case aan en die moet uitgewerkt worden. Daar staat in wat er in moeten komen te staan. Vervolgens wordt er een project plan geschreven, waarin dit soort dingen terugkomen. [Uitleg verschil governance management] Van welk niveau zie je dit? [Uitleg niveau van governance] Als je misschien wel zestig projecten hebt gelopen, dit wordt altijd gedelegeerd. [Uitleg dat het groot initiatief heeft] Je hebt stuurgroepen en daar haken dit soort mensen erbij. Alles wat hier wordt beslist en dat kan op basis hiervan te zijn. Senior management bemoeit zich ermee nauwelijks. Te gedetailleerd. Gaan van de expertise uit van anderen; wat kost het, wat levert het op, wat zijn de risico’s? En tikken de aspecten af, zoals van jouw model. Bij de start bemoeien heel veel mensen zich mee. Bij de implementatie komt de projectleider. Hoe ga ik invulling geven aan de processen is veelal niet echt iets van belang voor senior management. Meestal sluit wel een GRC functie aan bij start van zon’project. Wat ik wel mis, is het stukje privacy? [Uitleg staan bij SLA & Vendor requirements] Heb je ook een beschrijving van hoe je het model moet lezen? [Uitleg dat conceptueel model is]. Tip, ik heb mijn model gewoon weggestopt en toen gedacht wat wil ik nou precies uitleggen. En dan aan je ouders of je vriendin laten zien en vragen of het duidelijk is. Stap missen af van het cirkel
173
model. Misschien wordt het dan duidelijk wat je wilt uitleggen. Bij een cirkel heb je meestal het idee; het stopt nooit. [Is dit niet meer misschien operationeel en niet governance en eerder onderdeel van het project?] Je gaat hier al vrij de diepte in. Governance board zegt enkel heb je hier invulling aaangegeven. Hoe, daar bemoeien ze zich niet mee. Misschien dat je gelaagd-heid in kan brengen, tussen governance en operationele aspecten. Binnen in bv kan je operationele. En uitleg met tekst helpt veel. [De tabel wordt dan niet echt gelezen]. Dat komt omdat er heel veel tekst in staat. Dat schrikt af. Als ik jou was, laatste tip ga is de structuur bouwen van organisatie en kijk welke informatie is van hun van toepassing. Wie heeft de informatiebehoefte? [Klopt de inhoud?} Qua inhoud klopt deze punten. Zeker weten. Alleen deze ene vind ik de vreemde eend in de bijt. [Uitleg monitoring bestaat uit vier aspecten] Ok, dan moet je het zeker aanpassen. Maak dat duidelijk. [Zeker verschil tussen project en governance aspecten]. Ja, dit zijn allemaal stappen van het project. Ik mis de volgorde tijdens een project. Wanneer ga ik wat doen. [Misschien plan do check act?]. Ja, dat is nu helemaal hip. [Dan heb je hoge governance activiteiten en operationele?] Ja. De CIO bemoeit zich vooral met de strategie en enterprise architecture en de invulling van het project. Het moet passen binnen de strategie en de risico’s moeten ook beperkt. Als hij daar vertrouwen in geeft dan laat hij het zijn gang gaan. Het moet passen in het beeld waar ze heen willen gaan. En na implementatie krijg je evaluatie moment, vandaar dat plan do check act zo sterk is. Hij zit in de stuurgroep en als hij signaal krijgt dat cloud project gedaan is dan is het prima. Zo houd je de zestig projecten beheersbaar. [Hoe verhoudt het project zich tot de processen? Verloopt er een project die de processen coördineren?] Ja, de project manager die coördineert de processen. De wie doet wat wordt bepaalt in de stuurgroep. [En acquisitie valt onder hoge service management proces zoals vendor management?] De afdeling inkoop zou dat doen. Je stelt de processen bij. Die zijn er. Bijvoorbeeld als er geen service management is, dan moet de service manager daarvoor inrichten en dan rapporteer je weer naar boven. Als project is niet als doel om daar invulling aan te geven. Bij de business case, zeg ik ook welke processen raak ik, wat is de impact. Het geeft volledig inzicht in deze aspect voor hem. [Als je dit model zou maken voor senior management? ] Staan al die componenten die ik gedefinieerd heb in de business case? Dit is allemaal belangrijk voor de business case, voor het project en voor de check. 174
[Zou een overkoepelend model meer nut hebben voor hem, met bijvoorbeeld organizational impact, risks en business case?] Ja, dat sowieso. [Is dit wel governance?] De stuurgroep vraagt deze activiteiten of dit wel uitgevoerd wordt. De uitvoering vindt hieronder plaats. Of het is voor hem een middel voor de stuurgroep van dit ga ik doen. [Maar zijn operationele activiteiten zoals capacity management ook niet belangrijk dan?] Dan ligt het eraan hoe diep je kunt gaan. Je kan heel incident management erbij pakken en dan heb je een aparte thesis. [Is dit qua monitoring wel goed voor governance?] Ja, zeker dat is heel goed. Dit kunnen ook KPI’s zijn. De stuurgroep is adviserend, de projectmanagement is uitvoerend. [Is de business case wel governance activiteit?] Die kan ook door 1 iemand geschreven worden. Maar het kan ook door stuurgroep geschreven worden. Dat ligt eraan. [Wat vind je van de additionele informatie?] Deze vier aspecten? Het is heel hoog over, je kan het laten staan. Maar ik denk dat ze wel weten dat organisaties weten wat in de business case moeten komen. Maar specifiek voor cloud kan je het laten staan. Als het wel op literatuur gebaseerd is. Ik ben niet mee eens dat organizational impact enkel op IT departement effect heeft. Als je iets uitbesteedt gaat het koppen kosten. Stel ik doe een Cloud oplossing voor een HR afdeling. Met de nieuwe applicatie kan ik het met de helft van mijn mensen doen. Cloud kan impact hebben op de mensen die we hebben. Binnen HR kan het ook zo zijn dat er mensen wegvallen. Het is niet heel nuttig, maar je kan het erbij zetten. Risico’s enzo is een hele aparte studie. Dat kan je niet erbij zetten. [ Tot slot, voor hoger management dan CIO is dit dus niet geschikt? Nee nee, alles wat boven de CIO komt die kijkt niet naar dit soort modellen. Dit model is meer voor de stuurgroep, de CIO kijkt naar de business case. [Dus dit model is voornamelijk geschikt voor stuurgroep, een hoger niveau kan voor CIO] Ja, dat is prima. [De controls vallen binnen de processen?] Ja, het project kan dit eisen aan die stappen of processen.
CTO [User 4] [Uitleg cloud governance model] De dingen die je net opnoemt, processen, repsonsibilities, busines case, monitoren dat zijn geldige punten. De dingen die gelden, on-premise zijn bij ons in huis, voor mij zijn al die dingen die je noemt niet verschillend voor de traditionele on-premise implementatie. Wat cloud is een breed begrip, dat kan een private cloud zijn, een public cloud, een hybride vorm, en inhoudelijk heeft dat impact op die punten maar in de details. Bijvoorbeeld Als je iets in een publieke cloud draait en wilt integreren met
175
een onpremise applicatie dan kan bijvoorbeeld de master data management governance erg belangrijk zijn. Hoe verhoudt dat tot jouw model? [Uitleg off-premise & risk controls] Wat wij zien vanuit de praktijk dat echt anders is dat als je op het moment over een on-premise oplossing spreekt dan is de IT afdeling meestal goed betrokken en zijn dingen zoals security en risks goed geregeld bij public cloud zie je toch dat de business vaak zelf op eigen houtje oplossingen afneemt en dat ze later pas kijken past dit binnen onze IT architectuur en dingen zoals je zei zoals security en data governance, maar ook als je on-premise dingen doet heb je ook allemaal security dingen, omdat je moet ook vanuit het publieke internet moet inloggen op de systemen dat is niet nieuw ofzo en daarvoor heeft de IT afdelingen token enzo in huis het punt is vaak dat die mensen niet betrokken zijn en dat dus later allemaal dingen naar boven komen die eigenlijk in het begin van het project gedaan had moeten worden. Omdat heel vaak en ja dat veranderd hoor, kiest men en dan heb ik het over publieke cloud, en niet over private clouds dat ontstaat vaak vanuit IT, bijvoorbeeld een CRM oplossing voor een verkoopafdeling, heel vaak ontstaat dat dat zon afdeling gefrustreerd is van dat de IT te lang duurt en dat ze dan iets graag operationeels willen hebben en vooral van de business functie wordt vooral naar de functionele capaciteit gekeken en veel minder naar wij noemen dat onboarding, bij publieke clouds, noemen wij het onboarding, hoe raak je operationeel binnen je oplossing en zo zie je gewoon dat men vaak binnen functionele aspecten richt en niet naar risico’s of naar integratie aspecten en die problemen komen pas later aan bod. Dus een van de conclusies is dus dat het belangrijk is dat IT involved is. [Uitleg model net gemailed] Moet ik bij de cirkel beginnen? [Uitleg model] Dat klopt ook, want die waarde monitoring heeft ook impact op het begin van het traject. Je begint bij wat je wilt bereiken. Heel vaak is de strategie die uitmonden in KPI’s, die zet je aan het begin, en vanuit daar krijg je ook je functionele requirements. Dat wordt niet vaak zo gedaan hoor, maar het zou zo moeten. Vanuit wat je wilt bereiken kijk je naar welke requirements heb je voor je oplossing. Wij noemen het PPI process performance indicators, dingen die je in je process wilt verbeteren, bv utilization rate van monteurs. Die operationele KPI’s zijn afgeleid van een strategie dat erboven ligt, meestal op applictaieniveau zit je op tactisch en operationeel niveau. We beginnen vaak met strategisch niveau. Op dat moment zie je bijvoorbeeld dat men werkkapitaal wilt vrij maken en dat kun je doen op een lager niveau dat klanten sneller betalen en daaruit kan je KPI’s afleiden, bijvoorbeeld het aantal dagen dat het duur dat klanten hun factuur betalen. Dat trekken wij door naar best practices. Als we willen dat klanten sneller betalen op welke manieren kan je dat allemaal doen. Een voorbeeld is dat het handig is dat de facturen bijvoorbeeld foutloos zijn en dat we snel kunnen reageren op klachten van klanten en dan doen wij een analyse van die best practices en maken wij een maturity analysis als klanten zeggen dat de facturen al altijd foutloos zijn dan hoeven we geen nadruk daaro te leggen als ze weten dat hun klachtafhandeling niet goed is dan is het de best practice die helpt om de bso te verlagen en dus werkkapitaal vrij te maken en het is waar je niet goed in ben dus daarin kan je je zelf verbeteren. Dan heb je dat in kaart gebracht en dan ga je kijken wat zijn de kritieke succes factoren om de klachtafhandeling te verbeteren dan kan zijn om mensen te training of het kan zijn dat je een automatiseersysteem nodig hebt en dan pas ga je naar ons toe om wat aan klachtautomatiserings te doen. Om het op die manier kan je altijd je requirements te koppelen aan strategische doelen. Vaak ontbreekt die lijn. Wij noemen dat value lifecycle management. Het value lifecycle bij het begin en uiteindelijk als je het project gaat beginnen. Er is een of andere cloud vendor 176
die je kan helpen om je klachten te verbeteren en dan kom je op het punt dat als het heel belangrijk dat de mensen aan de telefoon heel belangrijk is dat ze inzichten hebben wat de klant hebben gekocht en dat zit onpremise dan is de implementatie hele belangrijk en gedurende het project blijf je de KPI’s monitoren. Wat je ziet is dat de mensen die aan het begin zitten van wij willen meer werkkapitaal vrijmaken en de mensen die de selectie doen van de oplossing en dat die uit elkaar lopen en ze niet meer weten wat ze willen oplossen. Dat komt ook omdat het vaak verschillende mensen zijn. In het begin zijn vaak hoger management die tegen mensen zeggen doe maar een pakketselectie en dan is die link kwijt dan zie je vaak bij die projecten dat iemand van hoger niveau die komt terug en die stelt vragen en komen er mensen bij kostenaspecten en dan ga je naar je business case toe en moet je wel weten wat je wilt oplossen en als klanten zegmaar van 80 dagen naar gemiddeld 40 dagen gaan dan kan je 40 dagen sneller betalen en kan je mak kelijk bereken wat het opelevert en welke investeringen je zou willen doen en daar gaan. Xx heeft daarvoor een oplossing gemaakt voor klanten en wat wij daarin doen geven wij benchmarks die we verzamelen van klanten. Bijvoorbeeld BSO vraagstuk: we gaan naar Heineken toe en vragen aan hun wat is jullie BSO, ze zeggen dan bijvoorbeeld 80 dagen, ja is dat hoog of laag? Wat wij doen, we vragen het aan klanten, zodat wij jaarlijks die gegevens verkrijgen en dan vragen we aan Heineken met wie willen jullie je vergelijken, bijvoorbeeld alle bierbrouwers van Europa. En dan kunnen we een analyse maken, dan komen we bv op 60 dagen dan weet je dat 80 dagen slecht is. Dan zie je dat je benchmarks nodig hebt. Dat is de manier die wij vaak gebruiken. [Kloppen de aspecten?] Je trekt het eigenlijk los van cloud. Cloud kan een requirement zijn..stel ik verzin wat..op het moment dat de business case alleen gehaald kan worden als de oplossing bestaat uit iets dat alleen in de public cloud beschikbaar is, als je het on-premise zou doen ben je een half jaar verder, dan is dat ene hele belangrijk element in je business case, maar niet andersom, we kiezen voor cloud en dan..snap je, dan zit je op oplossingsniveau en als je dan terug moet, bijvoorbeeld integratie is duur en dus een groot nadeel, dan moet je terug kunnen gana naar je business case. Wat weegt zwaarder, integratie kosten of het feit dat we binnen vier weken operationeel zijn en dan kan je feitelijk gaan rekenen waarvoor je kiest en dat zit in je governance model, heel vaak gebruiken wij dan, wij hebben zon model wie is responsible en accountable wie kan daar besluit over nemen. En bij de meeste bedrijven is dat ratjetoe. Wat je vaak ziet, dat is wel goed in je model daar heb ik geen opmerkingen over, maar naar mijn mening is zon model onafhankelijk van cloud onpremise, het zijn algemene uitdaging van IT vraagstukken, hoe beheers je al de risico’s in het project en hoe zorg je dat je al die doelstelling die begon gedurende het project kan monitoren. Het is naïef om te denken dat alles goed zal komen In het project komen dingen naar voren die je va tevoren niet wist, het niet is niet zo dat alles loopt zoals je bedacht hebt. Dus je moet telkens terug kunnen komen naar je business case. Als dat er niet is het lastig om besluiten te nemen. Dit zie je op alle niveaus ook buiten it. Bijvoorbeeld de overheid met die hoge snelheidstrein. Dan kan je het ook afvragen Wat willen we eigen bereiken met die trein. En is het ook acceptabel dat het zoveel meer gaat kosten of wat dan ook. Dan zie je vaak dat de lijn verbroken is, die zie je dan niet meer. Dat is mijn enige opmerking. [Wanneer heb je de business case?] Voordat je kiest met cloud begin je al met de business case. Het is gewoon een manier om gebruik te maken van software. Je kan een project starten om kosten te besparen om heel je infrastructuur in de Cloud te sturen. Daar kan een strategie achter zitten, heel vaak is dit de OPEX CAPEX discussie, dat ze zeggen operationeel zijn we al zoveel geld kwijt dat we geen ruimte hebben om geld te investeren voor nieuwe innovaties en dan kan er een project ontstaan. Door heel de infrastructuur in cloud te brengen willen we zoveel procent van onze kosten te besparen en dat willen we investeren door dingen in IT te stoppen. Dan is de cloud puur een enabler om in eerste instantie kosten te besparen en daarmee te innoveren, het is altijd een middel nooit een doel. 177
Op detail niveau zitten er veel verschillen waar je moet op letten. Als je kiest voor public cloud, dan is het bv heel erg ven belang waar staat je gegevens. Als je cloud provider is een Amerikaans bedrijf, dan kan de Amerikaanse regering afdwingen om je gegevens in te zien dat speelt niet als je het in een private cloud stopt. Uiteindelijk kies je voor een public Cloud omdat daar voordelen aanhangen en andere aspecten moet je dan onder controle hebben en dat verscheelt tussen die modellen. Daarvoor heb je ook een aantal governance modellen voor. Bijvoorbeeld bij een van onze klanten hebben wij een model waarmee we in kaart brengen welke gegevens zij bereidt zijn om in een public cloud te stoppen, welke in een private cloud en welke altijd on-premise moeten stoppen. [Wat is governance?] Governance is voor mij een breed begrip. Alle voorbeelden die ik noemde dat kan het allemaal zijn. En zeg maar hier kies je de insteek governance binnen een cloud omgeving. Wij hebben zelf software voor GRC zaken en dat heeft er mee te maken wat zijn je risico’s, hoe mitigeren we die, analyses wat er mis mee kan gaan maar het is net in welke context je het plaatst. En zegmaar governance kan je ook hebben rond masterdata. Het governance model hebben we bij een utility model gezien rond hun master data wat een tabel was waarin opgeslagen stond dat prijsinformatie dat mocht nooit naar een public cloud en enkel private cloud en andere dingen weer wel. Dat was een governance model rond masterdata dat als input kan dienen van ja voldoen wij eraan. [Uitleg dat het afhankelijk is aan wie je het vraagt] Het is afhankelijk aan wie je het vraagt wat het betekent, dat klopt ja. [Usable?} Dat is wel een hele grote stap zo’n vraag ha. [Senior management betrokken bij de activiteiten]? Bedoel je vanuit de praktijk of hoe het zou moeten zijn? Dat is vaak de praktijk situatie, maar zo is het niet hoe het zou moeten zijn. Het is erg belangrijk dat je de link houdt wat je wilt bereiken. Hoger management en bestuur is daarin eker belangrijk. Als je op hoog niveau zegt wij willen werkkapitaal vrijmaken dan is dat een doelstelling op vrij hoog niveau als je dat vraagt op boekhoudafdeling heeft die geen flauw idee wat je daarmee moet doen. Het is belangrijk dat je dat op hoog niveau vaststelt dat je een aantal aspecten op lager niveau. Stel je hebt conclusie dat zon systeem je klachten kan helpen, dan zijn er mensen op lager niveau die eisen stellen aan het systeem, maar hoger management moet rond het hele project de value monitoring blijven doen omdat er keuzes gemaakt moeten worden die altijd terug moeten refereren aan wat j wilt bereiken. En dat kan degene die bv iemand op klachtenafdeling die moet vinden wat er op het scherm moet zien om met het systeem te werken, maar hij kan niet bewaken dat het uiteindelijk reuslteert dat klanten sneller moeten gaan bepalen. Daar zijn ook andere dingen voor zoals opleiding je moet juist het hoge management in alle fasen betrokken houden om continue af te wegen gaan we de goede kant op zoals bij een navigatiesysteem, dit is het einddoel en er kan van alles gebeuren tussendoor en dat systeem zoekt elke keer weer een andere weg en dat kan je niet ter plekke iemand op laten lossen. En dat is super belangrijk. [Stuurgroep betrokken?] Ja, meestal heb je de structuur dat je een stuurgroep en werkgroep hebt. En de stuurgroep zegmaar die moet allemaal afwegingen maken die vanuit de werkgroep komen bijvoorbeeld, ik noem maar wat, eene project gaat langer duren er komen allerlei dingetjes naar voren, de stuurgroep moet naar besluiten over nemen zodat de werkgroep verder kan. In die stuurgroep is het belangrijk dat daar de afgevaardigden uit de business zitten. Die uiteindelijk, in dit geval zou de CFO verantwoordelijk kunnen zijn voor het werkkapitaal verhaal en dus moeten zij wel in des stuurgroep zitten zodat zij kunnen afwegen dit vind ik belangrijker dan dat en daar zit ook de leverancier vaak in om advies te 178
geven welke opties er zijn. Meestal zie je bij grote bedrijven en dat gaat veel veranderen door cloud is dat de traditonele IT functie, de mannen met de schroevendraaiers, gaat veranderen naar business analysten, mensen die op snijvlak zitten tussen wat IT technisch mogleijk is en het begrijpen van business processes. Je ziet vaak dat zij tusen business en IT zitten, die brengen in kaart de business processen bijvoorbeeld. Je hebt die analisten die helpen de vertaalslag te maken naar IT. [Verschil programma’s en projecten?] Als voorbeeld klantgegevens, wij praten over master data management is de technische kant, dat je bepaalde gegevens moet synchroniseren bijvoorbeeld of bronnen samenvoegen. De technische aspecten, master data governance is het proces er achter, zoals wie mag op dat moment klant gegevens aanpassen en dat leg je vast in proces vorm en daar gaat het vaak mis. Bijvoorbeeld niemand mag klantgegevens aanpassen behalve 1 afdeling, dan is dat je master data governance. Moet even oppassen wat ik nu zeg, omdat ik niet goed begrijp wat je zegt. We maken onderscheid tussen programma’s en projecten. Programma’s zijn vaak breed op hoog strategisch niveau en daar onder hangen projecten met een begin en einddatum met duidelijke deliverables. Als je kijkt naar de business case, dat is verweven van het begin tot eind van het project, in het begin heb je wat wil je bereiken en dat is input voor je business case. Heel vaak is dat te laat, dan denkt men na over investeringsopties en dan pas naar de business case later. Je business case is de continue refenretiekader. Je moet in zo’n project een afweging maken. Iets wordt duurder. Het is een referentiekader voor je requirements, voor je bepaalde afwegingen te maken tijdens het project. Heel vaak is het niet zo, daaom hebben wij value lifecycle ontwikkeld zodat je bij je business case begint en eindigt. Als je een goede business case hebt kan je altijd terug gaan naar belangrijke beslissingen, zoals hoeveel werkkapitaal willen wij vrijmaken. Als je dat refentiekader niet hebt, kan je die vragen niet oplossen. [Klopt het model?] Het is een complex ding. Vrij hoog model, daar zitten vrij veel complexiteit onder. In de zin dat je zegmaar, de governance als je kijkt naar proces niveau, je moet bijvoorbeeld dingen documenteren, omdat je daar verplicht tot bent, dat is dan heel belangrijk iets wat ingesloten zit in je project en dat is ook belangrijk op het laagste niveau als mensen gaan werken met het systeem dan moeten mensen weten over de dingen van die verplichtingen, maar dat vertrekt ook weer vanuit de governance, als daar heel belangrijk is dat mensen dat doen zodat je kunt waarborgen dat bv gegevens tracable zijn, dan kun je die dingen niet los van elkaar zien. Op bestuurlijk niveau ben je verantwoordleijk om de business case te halen. Mensen willen alleen investeren om rendement te halen op hoog niveau, bijvoorbeeld om klanten sneller te laten betalen, dat is de verantwoordelijkheid op bestuurlijk niveau. Als dat betekent dat requirements zijn dat de provider bv geen data centers hebben, dan gebeurd dat wel op een lager niveau, ergens binnen de IT wordt dat uitgedoktert of ze er precies aan voldoen. [Activiteiten op bestuurlijk nievau?] Alleen het gele gedeelte, value resurance, dat is het enige waar zij verantwoordelijk zijn. Of ze het rendement halen. Daar zijn ze accountable voor. [Is Awareness over bijvoorbeeld de risico’s van cloud computing voor hen belangrijk?] Als je op bestuursniveau zit, die bewustwording is er wel, omdat er al veel voorbeelden zijn geweest. Bv stel dat je in directie zit van farmaceutisch bedrijf en op het moment dat er iets fout gaan in productieproces en klanten worden ziek dan draag je daar als directie verantwoordelijkheid voor en ik denk dat zij daar wel bewust van zijn. Risico’s zijn groot breed begrip. Dit zijn risico van business gezien en die kunne uitmonden in IT technische oplossingen. De grote complexiteit is de relatie te 179
zien. Daar is software voor om de relaties te leggen tussen de risisoc’s. Bv bij invoering van een cloud oplossing waardoor je verkeerde medicijnen maakt en het is de vraag of men in de complexiteit dat risico’s zien. De awareness is er zeker, veel bedrijven nemen risk officers in dienst. En dat is heel vaak gevoed dat soms men in de directie persoonlijk verantwoordelijk gemaakt kunnen worden door dingen die in het bedrijf gebeuren eenvoudige voorbeelden zijn dat als je en publiek bedrijf bent allerlei dingen die je roept over het bedrijf daar ben je verantwoordelijk voor als je mensen misleid dan krijg je daar problemen mee, de awareness is er zeker, maar de vraag is of de mensen in de werkelijke complexiteit in de dingen daar allel relaties te zien. Achteraf is het makkelijke, door dat ging dat mis, maar om van te voren alle risico’s in kaart te brengen en te mitigeren en te zien wat er kan gebeuren door risico’s. In governance modellen probeer je dat te doen, maar dat is erg moeilijk om dat van te voren te doen. Een praktijk voorbeeld, jij kiest nu de insteek cloud, als je het hebt over risico’s dan mag je dat nooit afhankelijk maken van een bepaald project dat over Cloud gaat, een risico kan ook zijn dat mensen in een bedrijf alle gegevens in dropbox zetten die zelfde wachtwoord gebruiken als voor andere dingen, dat zijn grotere risico’s dan de risico’s van de cloud providers. Op hoger niveau moet je dat meenemen, wat zijn de kans dat gegevens op straat liggen. De manier waarop dat kan gebeuren is breder dan iets in zon Cloud project. Door het in de cloud te doen kunnen er dingen veranderen en daardoor kunnen bepaalde risico groter en kleiner worden, maar dropbox kan ik als cloud zien, binnen [x] is het verboden om gegevens in dropbox te zetten. Het alternatief ervoor is een eigen dropbox waarvan we de veiligheid wel kunnen garanderen en dat kan je een cloud project noemen, maar we begonnen bij het risico wat gebeurd er als mensen niet goed omgaan met klantgegevens. [Verdere opmerkingen]? De enige opmerking die ik heb is dat de dingen die je hier noemt is generiek voor elk IT project dus ook voor cloud project of hybride en dat gevaar is dat als je dat gaat centeren rondom cloud dat je iets apart maakt van cloud. Dat is hetzelfde voor elk project, risk mitigation, value assurance, voor cloud heb je gewoon zelfde dingen. Maar andere dingen waar je op focust. Zoals waar de data ligt. Er zijn weinig bedrijven die direct beginnen met cloud er zijn veel dingen die je al gedaan hebt en ook mee moeten nemen. Dit zou je hoger kunnen tillen, dit is model voor alle IT projecten en er zijn bepaalde dingen waar je focus op moet leggen.
180
Appendix G: summary expert interviews (first feedback round) Interviewee
CIO (University)
CFO (Dutch bank)
CSO (University)
CTO (also cloud expert)
Strategic IT advisor (owner consultancy company)
ID
User 1
User 2
User 3
User 4
User 5
Security project management (also cloud expert) (Dutch insurance company) Expert 6
Understandability
No, too much information and adoption project seems to overlap the governance activities. Evaluation is done in the end. Steps/phases not clear. Yes, very interesting subject for as well the board as for me. But not in current form.
Unclear how adoption project relates to the governance activities.
Very clear. But not so clear what the role of ‘data classification is’.
Unclear where to start and relation of adoption project to governance activities.
Not immediately. I need more time to understand what the model is about.
No, not clear what the phases are and the role of the project activities.
It maybe be useful for the board to get an idea of cloud, but our management team already knows how to handle cloud adoption.
No, the board does more concentrate on strategy. Setting up IT organization is IT governance. Because cloud is not disruptive technology, board does not oversee implementation.
Governance is total of decision making processes. Who is responsible for all the project activities? No connection to enterprise governance. Business case and value assurance are project activities. Board and top management does provide policies and high level objectives.
Yes, after reading it for a couple of minutes, I don’t see anything missing from it. But for board, risk controls not that relevant, for CFO or CIO it is. Correct, the top management should be responsible for the activities in the model.
Usefulness
Governance activities
Table too detailed.
Difficult to say. No opinion at the moment. Model is very broad, can be applicable to all kinds of IT projects.
Yes, this topic is very useful and trending.
Not for top management, but mere fore Steering Committee.
Yes, but got a wide perspective of governance.
Business case and value assurance are more project activities than governance activities.
It are project activities. Senior management delegates all these activities. They do not have time to oversee and manage many cloud projects.
Senior management is often not involved, but should oversee project within their steering committees (application life cycle management).
The board does only check whether things have happened, not how. It depends on the decision making structure whether the activities are performed by CIO or by IT and project managers.
Information accuracy
-
-
-
Additional comments:
Two stories are told in the model: for the board and for IT governors. Make more models for multiple audiences. An Awareness model for board and cloud governance for CIO for example.
Enterprise policies are for example, when information will reach the board, is IT involved.
An awareness model would be very useful for the board which provide information on cloud.
Correct
After project, service management processes become relevant.
Information is correct, except for organizational impact: not only on IT. Nature of application can also effect other employees. Maybe leave the circlemodel that implies it is a continuous set of actions.
181
Appendix H: feedback management processes Cloud infrastructure consultant (telephone) [Expert 3] [Verschil tussen project en cloud processen?] Ik zie dat voornamelijk als projectactiviteiten. Een project heeft een resultaat er komt iets uit en als dat resultaat bereikt is het project klaar en kunnen mensen verder met hun leven, de stappen die we over hebben gehad voor een cloud oplossing dat zijn meestal project activiteiten en daar kunnen wel processjes inzitten die je kan volgen. Dat zijn wel echt project activiteiten en op het moment dat je een provider hebt geselecteerd en draait het allemaal. Dan ga je over op je reguliere bedrijfsvoering en dat zijn processen dan kun je je normale service level management gaan uitvoeren als proces. Waar komt je vraag vandaan? [Dat is precies wat ik bedoelde, uitleg ITIL tijdens service design, hoe zit dat dan?] Laten we er vanuit gaan dat je naar een uitbeste dings situatie gaat. Je hebt nu intern je IT staan en je wilt naar een cloud dienst gaan dan heb je nu je eigen processen rondom proces, change en problem en configuration die heb je nu staan. Dan zijn je standaard processen op het moment dat je gaat uitbesteden hoef je dat niet meer te doen dan gaat de provider voor je doen. Wat je dan wel moet gaan doen is je provider aansturen daarvoor moet je wel nieuwe processen inrichten zoals service level management dat is het proces dat je zelf moet gaan uitvoeren daarin check je. mijn provider geeft aan je krijgt een beschikbaarheid van 99 procent. Dan moet je dat iedere maand checken hebben wij die 99 procent gehaald zo ja dan is het goed zo nee dan ga je naar je provider. En die processen zijn er nog niet en die moeten worden ingericht. Als je je eigen IT beheert dan ben je met andere dingen bezig dan het aansturen van een provider. In het project wordt het proces ontworpen, die persoon wordt verantwoordelijk, dit moet je doen, zo moet je het rapporteren, in zon project beschrijf je dat daar komt een proces beschrijving uit en die proces kun je dan is het process klaar en diemoet je dan uitvoeren. Dat is wat je continu blijft doen iedere maand kijken of je service levels worden gehaald [Dus in cloud project?] Ja. Projecten hebben heel duidelijk doel en einde en proces is iets dat continu doorloopt. Daar zit je op het schijdingsvlak van projecten en processen. Je hebt een project met bepaalt doel en het kan zijn dat je daar bij bepaalde processen moet doorlopen. Ik kan me voorstellen als je cloud implementatie gaat doen je de inkoopproces moet doorlopen waar er gecontroleerd wordt is dit ene prefered supplier en binnen je project doe je een uitstapje naar een van je processen. Het kan gebrueren dat je in je project processen moet uitvoeren. [Nieuwe cloud processen voornamelijk ‘run’?] Ja, op het moment dat je de server overdraagt naar je cloud provider dan moeten de processen er staan en dan kan je beginnen.
IT strategist (e-mail) [Expert 1] Steven, Overgang naar Cloud is een variant van oursourcing, nl je gaat een deel van je dienstverlening inkopen. Juist processen rondom aansturen/monitoren van leveranciers (SLM, fin mgt,Vendor 182
mgt, incident, problem, change etc.) zijn dan ook key. Zonder deze processen kan je m.i. niet outsourcen/overgaan naar cloud. Dit zijn dan ook echt processen die je in place moet hebben. Als ze nog niet bestaan kan het onderdeel zijn van een project om deze te implementeren. Dit zijn allemaal herhalende activiteiten, dus eenmalig als projectactiviteit uitvoeren is onvoldoende, wel kan je ze eenmalig uitvoeren binnen het project maar dan moeten de activiteiten daarna overgenomen worden door de lijnorganisatie. Fin mgt en leveranciersevaluatie wil je periodiek uitvoeren.
Security Project Manager (e-mail) [Expert 6] Hi Steven, Korte reactie; bepaalde ITIL processen zijn inderdaad alleen te implementeren als een oplossing reeds geïmplementeerd is. Welke wel/niet van toepassing zijn hebben we voor zover ik kan herinneren niet besproken. Ik ben wel van mening dat ITIL kàn aansluiten bij cloud oplossingen. Succes met afstuderen, Met vriendelijke groet,
CFO (e-mail) [User 2] “Bedankt voor je mail. Even een kort antwoord om duidelijk te maken waar volgens mij de verwarring ontstaat. Voorbeeld: de SLA. Bij uitstek een run proces, behalve de eerste keer dat je een SLA opstelt vanwege een nieuwe klant (change in run), een nieuwe klant met speciale dienstverlening (iets meer een project aan het worden wegens crossfuntionele coordinatie die nodig is) of een geheel nieuwe dienst aan een klant (zou ik zeker een project van maken). De vraag is nu, hoort het opstellen van een eerste nieuwe SLA tot change (lijkt mij wel) of een project (wellicht, tenzij de SLA een uitvloeisel van een project is en het opstellen op zichzelf tot change in run blijkft behoren - kwestie van hoe "de eerste/nieuwe SLA" wordt georganiseerd). Wij doen het zo: als een project serieus impact heeft op een SLA, wordt het opleveren van de eerste SLA als een project deliverable gezien. Lang verhaal kort: run activiteiten die substantiele gevolgen ondervinden van projecten (of er deel van uit maken) of andere veranderingen, zullen aanvankelijk als change/project activiteit gekenmerkt kunnen worden, waarna diezelfde (maar aangepaste of nieuw neergezette) activiteiten weer geheel tot run gerekend kunnen worden. Hope this helps!”
183
Appendix I: interview transcripts (second feedback round) Cloud infrastructure consultant (telephone) [Expert 7] Ik herken de stappen. Eerst bepaal je de strategie, ben ik er klaar voor, dan definiëren en dan de business case. Ik denk dat je dat in een heel mooi modelletje hebt gevat. Alleen hoe wil je het model inzetten en wat is het doel? [Uitleg] Ja, helder. Je ziet meestal twee lijnen. De eerste is we hebben een acuut probleem, we moeten kosten verlagen en dan willen we cloud inzetten. Anderzijds zie je ook wel dat er opnieuw naar een IT strategie wordt gekeken en dat cloud daar een onderdeel van kan vormen. Cloud is dan geen aanleiding maar gevolg van die strategie. [Cloud strategie, of komt er direct een project?] Wat je meestal ziet als je de keuze maakt, dat je een aantal uitgangspunten definieert. Aan welke wet en regelgeving moet je voldoen en welke services kan ik dus afnemen. Dat zijn uitgangspunten om concreet invulling te geven. Strategie is meer wat doe ik zelf en wat doe ik niet zelf. [Outsourcing strategie?] Ja, klopt. Je kunt bij voorbaat al uitsluiten van we willen absoluut niets met cloud doen of uit besteden dan houd het op. [Bij strategie stap kijk je dus of het mogelijk is?] Juist ja. [Ander model, processen kloppen?] Ja klopt. Op het moment dat je in de operationele stap bent dan gaan je processen echt volledig lopen. Risk management begint al eerder natuurlijk. De donker blauwe stappen ook, zoals requirement opstellen, security, dat zijn meer losse stappen en dan komt het proces die blijft lopen. [Wanneer implementeren?] Tijdens je implementatie fase. [Readiness assessment, global of je het aankan?] Ja, klopt ja. [Denk je dat de modellen verder kloppen?] Bij Governance denk ik ook aan wie is verantwoordelijk, wie doet wat, deze is natuurlijk van de afnemer gemaakt. Misschien is het goed om dat erbij te vermelden. En, ik denk dat dit wel aardig voorbeeld geeft hoe de processen die er spelen.
Strategic IT advisor [User 8] [Nieuw governance model uitleg] Wat je bij cloud eigenlijk doet is doordat je met een SLA een contractuele oplossing kiest waarbij je heel veel de vendor hoek in schuift, die moet dat regelen. Daarom moet je wel een hele goede SLA hebben.
184
Change management waar zit dat dan? [Uitleg bij service management] En monitoren? [Uitleg SLA monitoren] Ja, ja ik snap het. Dit model doet mij heel sterk denken aan het outsource model. [Future research] Ja, en dan kijken wat de verschillen zijn. Ik denk dat dit veel sterker naar data classificatie kijkt, want bij outsourcen staat de server wel nog vaak bij jou. Jij runt het nog, een tussen oplossing. En dit besteedt je helemaal uit, dan moet je sterk naar de data kijken. [Compliance van belang] Ja, tuurlijk, anders wordt je plat gelegd. Wat hier zo verdomd lastig is, is dat je hier te maken hebt met een organisatie, als je het intern houdt, tijdens de ontwikkeling van de applicatie rekening gaat houden hoe het straks in beheer gehouden wordt, dat weet ik niet. Dat maakt het voor de samenwerking tussen verschillende partijen vele malen duidelijker. Ik denk dat je als bedrijf die voornamelijk geïnteresseerd is in de output en niet in het proces ontzettend geïnteresseerd bent wat krijg ik geleverd, wat gaat het kosten en ben je in staat dat netjes te doen dat is zeker interessant voor het bedrijf. Onderschat niet dat als je hier wat wilt laten bouwen, voordat je de requirements gaat kloppen gaat een gigantisch project aan te voren. Daar wil je goed in zijn als bedrijf, dat is de markt, en hoe gaan we het doen en hoe gaat de IT het ondersteunen. En als je kan uitbesteden wat er moet gebeuren. Dan is dat fantastisch. [Uitleg dat security belangrijk is] We hebben al jaren aan outsourcing gedaan. Maar dan gebeurde wel nog veel on-premise. Daar is cloud computing dus het meest gevoelig voor qua IT service deel, dat ga je nu ook uitbesteden. Vroeger had je dat nog in huis. Als je standaard software op en die neem je af in de cloud, waar ben je dan gevoelig voor, de data die daar staat dat is het gevoelige onderwerp. Dat zij een update uitbrengen dat kan je geen reet schelen. Rondom die gedachte is cloud computing volgens mij gebeuren, laat ik standaard pakketten overal kunnen gebruiken. Maar mijn data staat daar, dus ik moet heel veel zekerheid kunnen krijgen dat de data op een zekere manier wordt behandeld. Dat is waar het bij cloud om gaat. Je gaat niet een office in de cloud zetten, je gaat een kritische bedrijfsapplicatie in de cloud zetten die misschien gebouwd worden. Dat maakt het voor mij ingewikkeld, dat zie ik niet gebeuren. [Uitleg standaard applicaties voor non-kritische processen]. Het is wel verdomd interessant. Dit model is goed. De andere is te gedetailleerd. De tabel is teveel tekst, dat kan je niet snappen. [Presentatie cloud evaluatie model] Ja, ik heb veel herkend dat is wel duidelijk. Ik vroeg mij wel af hoe dit model in een organisatie gebruikt wordt is dit projectmatig of wordt het door een afdeling is het de bedoeling of een afdeling er mee gaat werken. Of we stellen een project in om iets in de cloud te regelen hier heb je het model en regel wat. [Uitleg plaats van model]. Op operationeel niveau misschien wel dat mensen er afvragen van zijn we wel hier goed bezig of op beheers niveau die bepaalde dingen doen op het gebied van IT onderhoud en denken van misschien kunnen we het in de cloud regelen. 185
[Doet de CIO dit?] Naja, die moet het wel overzien en in de gaten houden. Het lijkt mij dat, het ligt aan de hoe de organisatie functioneert. Soms werken ze heel sterk bottom-up dan komen de ideeën en initiatieven van de uitvoerende organen, soms wel top-down, dan bepaald de CIO wat er allemaal moet gebeuren. Dat zit dan in een jaarplan om uit te gaan zoeken wat ze eventueel in de cloud willen plaatsen. [Onderdeel van sourcing strategie?] Ja, bijvoorbeeld. [Business case van belang?] Ik denk dat heel veel organisaties kritisch kijken naar de business case. Dan komt het uit de sourcing strategie, maar ik kan mij ook heel goed bedenken dat het uit de operationele kant komt. [Wat vind je ervan?] Er zijn wel een paar dingen die mij opvielen. De strategie hebben we net behandeld, dan krijg je de readiness, kan zij het aan. Is de organisatie er klaar voor. Hebben we überhaupt de resources, dat vind ik trouwens een betere benaming, ik heb dat hier ook weergegeven, die geef ik je straks mee. Dat je het meer van de resources bekijkt of dingen kunnen, dat zou dan het niveau readiness zijn. Dan kom je bij een punt wat mij betreft een vreemd begrip is waarvan ik denk dat je iets anders bedoelt, service definition. Dat zou ik impact analysis noemen. Als je de readiness hebt gehad, wat is nou eigenlijk de impact op de organisatie, op de resources, op de processen van dit in de cloud te plaatsen. Dat is een hele belangrijke. [Uitleg orga. impact in business case] Doe je dat niet eerder? Hier doe je de strategische analyse, hier ga je ten opzichte van de business case afdalen en dan kom je niet meer bij de impact analyse. [Uitleg dat de service invloed heeft op de organisatie] Dan zou je de service definition beter kunnen aanpassen, waar hebben we het precies over. Je hebt natuurlijk verschillende vormen van cloud, ik mis die tussenstap, de hele belangrijke stap, waarin wel notabene staat wat je hier hebt staan, security, impact op de processen en netwerk. Wat is de impact op de functionele netwerk waarop de organisatie draait. De functionele processen worden uitgevoerd door functional service network. Eerst heb je customer service, dan heb je de processen die borg je en die worden uitgevoerd door een functioneel service netwerk. De impact van iets dat je gaat veranderen in de IT die impact in enerzijds customer service, anderzijds de processen en andere onderdelen van service netwerk, dat wil je weten. [Uitleg belang van service voor impact]. Is dat service definitie of requirements, heb je het dan niet over requirements? [Uitleg service selection op hoog niveau] Een organisatie heeft natuurlijk een tig aantal applicaties draaien. Je zou dus die applicaties tegen het licht houden van kan deze geschikt zijn om in de cloud te stoppen? Dus je zou het dan ene jaarlijkse oefening van maken om te kijken welke applicaties in de cloud kunnen, omdat cloud wellicht een groot voordeel kan bieden omdat je weet al dat het een kostensparing kan opleveren, een speciale vorm van outsourcing dus. Dat wil je graag tegen het lichten houden dus. En wat jij bij de service definitie dus doet is hoe definieer je cloud? [Uitleg definieer service] 186
Wat we in de cloud stoppen dan heb je al die slag gemaakt? [Ja] Je weet nog niet wat voor soort cloud je wilt toepassen. Ik heb begrepen dat er veel vormen van zijn. [Uitleg overlappen en rol van model]. Als je zegt wat wil je in de clou dan doe je een voorselectie, die doen we aan een aantal eisen die we op strategisch niveau gesteld hebben dan bepaal je dus wat voor invloed heeft het en de business case gaan we er centjes aan verdienen. We praten dezelfde taal, ik had het over impact analyse hier is het de impact op de organisatie. Wat ik heel goed vind is dat je apart de risico’s benoemd, dat wordt heel vaak vergeten. Wat zijn nou de risico’s, ook in kader van de business case en het loopt fout wat betekent het dan. Je kan best een gunstige business case hebben maar als de er zoveel risico’s zijn voor het migratietraject. [Benoemen van cloud risico’s]. Je hebt geen greep erop. Je moet maar afwachten of het voor mekaar komt. [Uitleg compliance vooral groot risico] Ja, security hebben ze zeker wel voor elkaar. Als ze dat niet kunnen bieden kunnen ze die dienst niet leveren. Kijk nou naar dat programma van Obama, dat kan je toch niet voorstellen. Ja, tot zover ok. [Snap je het?] Ja, dat is allemaal logisch. Ik kan allemaal volgen wat je aan het doen bent. Ik herken ook heel veel van die wij toe hebben gepast. De elementen komen terug. Zo werkt het. Stel ik heb een middelgroot bedrijf en hebben drie servers in huis en een eigen office en dat soort dingen. Hoe lang denk je dat je met zo’n model moet doen om aan te geven of het haalbaar is? [Uitleg klein bedrijf gaan zo naar cloud] Ik neem het serieus, ik wil graag weten hoe het precies ziet, hoe lang zou je hier over doen? [Uitleg] Maar hoe lang ben je er precies mee bezig? Zon model is aan de ene kant een houvast, dat structuur geeft wat je aan het doen bent. Aan de andere kant moet het er ook voor zorgen dat het sneller gaat als je maar iets doet. Het moet wel iets van waarde toevoegen. Achter het model zitten methoden en technieken. Ik neem aan dat als ze je gaan doorvragen aan het model, dat ze wel vragen van ja hoe moet ik het uitvoeren. [Uitleg dat er mensen in orga. zijn die weten hoe ze het moeten doen] Dit is geen werkmodel? Model als consultant punt 1 om jou te hebben om dit te gaan doen en punt 2 als leidraad en structuur om als consultant dit werk op te doen. [Structuur uitleg]. Maar jij doet dit dus niet in het kader van je afstuderen? Van het model moet je het dus specifiek maken? Het lijkt mij frustreren om te blijven hangen op het niveau van modelleren. Zeker als je met iets concreets komt van zo moet je het doen, dan zou ik zeker de stukken eronder willen zien hoe kom ik tot uitvoering. Je had het hier over readiness, de questionnaire. Die moet je aangeven. Dat heb ik uitgezocht dit is een goed methode. Ga naar methoden en technieken, anders ben je te abstract en academisch. Probeer een vertaalslag te maken naar de praktijk. Volgens mij weet je wel al heel veel, volgens mij als je in die kolom methoden en technieken erbij toevoegt dan heb je toegevoegde waarde. 187
Dan ben je goed bezig en een compleet verhaal. Het model kan ik toepassen, het is op de grond, geen theorie meer. [Snapt het?] Ja [Bruikbaarheid, verbetert door methoden toe te voegen?] Dat klopt. [Correct?] Het zijn woorden dingetjes. Het staat er wel, dat is gewoon goed. Ik snap het, het is bruikbaar als houvast voor alswel management en uitvoering die begrijpen waar je het over hebt. Maar nogmaals maak het bruikbaar, dan wordt het echt van nut. Alleen de links, dan laat je zien dit kan je gebruiken.
CSO [User 7] [Introductie cloud governance model] Dat is de praktijk dat op lagere niveau dingen worden gedaan als een sourcingsvraagstuk. Dat moet niet op de bord van het bestuurd komen maar ze moeten wel bewust van zijn dat er wordt gekeken naar de cloud en dat het met de juiste argumenten gebeurd. Wat op het moment als er iets verkeerds gaat of er worden mensen ontslagen en alles in eigen huis gaat doen, dat besluit moet op de bestuurskamer genomen worden. Dat er lager op de organisatie wordt besloten we gaan iets met cloud doen, betekent niet dat het bestuur er niet mee te maken hebben. Zij worden er op aangesproken als er iets niet goed gaat. Dus ze moeten weten dat er met de juiste reden dat pad wordt behandeld. [Management oversight of governance?] Het ligt aan de organisatie. Bij de meeste organisaties heb je een raad van bestuur die dingen echt alleen op hoofdlijnen doet, en hier heb je vaak dat een college van bestuur een besluit van gaan we met de leverencier xyz in zee. Zo’n beslissing over outsourcing dat wordt eigenlijk door het college van bestuur genomen. [Is dat dan wel governance?] Bij ons zou dat dan een middle management activiteit zijn en dat wordt nader hand weer gecontroleerd door auditors, dat zit op een andere laag. Het hangt heel erg af van hoe je organisatie in elkaar steekt. Bij sommige bedrijven zit de CIO in de raad van bestuur. Dat is hier niet het geval. [Dus het ligt waar de beslissing wordt genomen of het governance is of niet?] Ja, ja. [Klopt dit model?] Dit is zeker vaak de praktijk. Maar of dat echt zou moeten is een andere vraag. Maar dat projecteer ik op onze organisatie. Bij een normaal bedrijf zit heel anders. [Jullie cloud project naar Gmail?] Dat was echt een raad van bestuur beslissing. Ten eerste van gaan we het doen. Dit soort risico’s mogen we lopen dat mag wel personeel kosten of niet, dat soort dingen. Vaak wordt op dat niveau randvoorwaarden meegegeven, dit soort controls zitten eronder. Je kunt het ook af laten hangen van het proces. Heeft een docent een servertje nodig, dan kan dat gewoon gedecentraliseerd doen. Maar op 188
het moment dat je studentadministratie in de Cloud zet, dat soort dingen moet het bestuur doen vind ik in dit soort organisaties. We zitten nu in een situatie dat we alles hebben uitbesteed. Natuurlijk wordt er nou cloud gekeken omdat er veel voordelen aan zitten, maar het bestuur beslist dat. Ook al is het gewoon de IT vertegenwoordiger. Dat is bij universiteit niet altijd duidelijk, de IT portfolio houder van college van bestuur of de echte CIO. [Service management processen voor cloud?] Ja, service management moet je heel sterk maken. Security management bijvoorbeeld. Functioneel beheer doe je natuurlijk zelf, tenzij je heel It uitbesteedt. Of je dat nou door service management laten vertegenwoordigen of door apart iets. [Wanneer nodig, tijdens run?] Tijdens run vind ik. [Afronding, wat vindt u van de governance (nieuwe en oude) modellen?] Beide vind ik correct. [Cloud risico controls nuttig?] Wat een rol speelt is om hoeveel geld gaat het. Het bestuur moet de risico’s kennen en geïnformeerd worden. Op hoofdlijnen geven ze instructies hoe, zij moeten zeggen ja van ik wil absoluut niet reputatieschade lijden, als je die randvoorwaarden schaad dan wil ik dat je hier komt. [Nuttig voor bestuur?] Voor veel bestuurders is dat niet heel nuttig,. Voor IT managers is het hartstikke relevant. [Voor IT manager?] Ja, ja. Even kijken wat ik meer over kan vertellen. De CFO zit er ergens tussen. Die moet die controls ook op hoofdlijnen kennen.
CIO [User 6] [Cloud security] Moet je aangaan, wat ik heel vaak zie is dat het wordt opgeworpen als iets wat je niet moet doen en het is een vraagstuk geweest en elke keer is er een nieuw vraagstuk wat opgelost moet worden je kan niet zeggen dat er wereldwijd een trend is dat we dit als een dienst gaat aanbieden dat er redenen zijn dat er iets niet mag dan moet je bij jezelf ten rade gaan waarom het niet mag en dat kan dus gewoon niet. Er moet een methode zijn dat zij kunnen overleven als bedrijf en wij de dienst af kunnen nemen. Anders zou het niet passen. [Evaluatiemodel getoond] De business case heeft er weinig mee te maken. Waarom zou je cloud moeten nemen? [Uitleg vooral kosten]. Geloof je dat het echt goedkoper is? [Ja] Dat is wel wat er altijd wordt gedacht, minder beheer. Maar wat is minder beheer. Vroeger nam ik een product af en stel dat het niet voldeed, ging ik het aanpassen, ging ik daar beheer opvoeren gingen we het updaten. Nu gaan we naar de cloud en bel ik Microsoft op en dat boeit niemand, ze gaan echt niet 189
voor ons een mailupgrade uitstellen. Die eenheid dat ik mijn conformeer naar die standaard dwingt mij om met die standaard te werken. [Klopt het model?] Wat heel erg belangrijk voor ons was dat we zochten naar een stukje flexibiliteit, we wilden diensten afnemen, niet zozeer cloud, een functionaliteit afnemen die dat moment noodzakelijk was. Geen systemen die we dan moesten onderhouden, snel die veranderingen. Als dat in je core business zit is dat een beetje vreemd. Dat was wel een hele belangrijk vraagstuk geweest waardoor wij heel vroeg gingen outsourcen en hebben wij ervaring opgedaan met outsourcing veranderingen. We hebben heel veel gestandaardiseerd de afgelopen jaren dan werd het een software as a service constructie en dat we ons niet te druk hebben gemaakt om waar staat het. We hebben het afgenomen als een dienst voor jaarlijks bedrag, lijkt op leasen. Toen kwam de cloudoplossing waarin we nog meer aspecten van het afnemen als een dienst konden gebruiken. We praten wel over 20 jaar van die ontwikkeling. [Waar beslist?] Ik val onder de medisch directeur. Dus direct onder de core business en die weet veel van IT vraagstukken: hoe wordt het strategisch benut. De ellende met de cloud en SaaS bespreken we ook en wel op zon manier dat we niet van ons geloof vallen maar hoe we het oplossen. [Bestuur betrokken?] We hebben medisch en algemeen bestuur en daar onder vallen de lijndirecteuren daar val ik in. [Board of directors mee bemoeit?] Op het hoogste niveau dat wij hebben wordt dat wel voor bepaald. Dat wordt daar wel gesproken. Zij weten wel de partners. Techniek heeft er mee te maken, het bedrijfsmodel wordt verandert en zij moeten wel zien wat voor nut dat heeft en waar ze heen moeten. Ik heb het altijd als een soort niksie beschouwd: het is geen vraagstuk. Het is niet iets waar je lang mee stil moet staan. Je governance vraagstuk moet toch weer kloppen. [Governance?] Wat wij hier als governance beschouwen is veiligheid, kwaliteit, compliancy en dat moet wel kloppen en je business continuïteit is een belangrijk vraagstuk. Of je voldoet aan je kwaliteitseisen, aan de normen en verplichtingen naar je klanten. Of je nou cloud afneemt of niet. Ik denk dat je bij cloud een betere business continuïteit hebt dan als je alles zelf doet. [Klopt model? Business case dus niet?] Het is geen apart vraagstuk. Het is een onderdeel van een oplossing dat je toets op het stukje governance op dat moment, daarom zei ik tenzij. Tenzij zo beslissen. Dat is bij het invullen van het infrastructurele vraagstuk of het hosting vraagstuk. Het is logisch dat als het rekencentrum hier af neemt dat het in mijn groen comissie een meerwaarde heeft, zoals je zei servers etc. Dat wordt daar gemeten en het beleid wordt ook daarin afgestemd. De continuïteit vraagstuk in de veiligheidscommissie daar wordt het als meer een soort zekerheid beschouwd. Voor strategie en wendbaarheid en flexibiliteit moet er ene model komen waarin je die dingen kan merken wat je flexibel inzet, dat geldt voor je financiële kant. Het komt overal om de hoek kijken. Het is niet een ding. Het is niet zo van ja we gaan cloud. Daar moet ik ook niet me aankomen: ja jongens we gaan in de cloud. Wat is de meerwaarde en is dat een vraagstuk? Het is geen apart vraagstuk het maakt een onderdeel uit van het vraagstuk dat dat in de business leeft. De grote en mini strategische vraagstukken. Als er hier een bedrijf komt en die zegt hey je moet dit en dat afnemen. Maar dan zeg ik ja dat is prima, alleen als wij hiervoor een hele eigen infrastructuur moeten inzetten. Wat leveren jullie dan uit de cloud? Dan wil ik het als dienst willen afnemen. Maar wij hebben geen rekencentrum. Maar 190
welke preferred partners heb je dan die het wel aanbieden? Dan neem ik het af dan betaal ik het wel gewoon als een dienstconstructie bij jou, maar dan neem ik het daar af. [Geen vergelijking dan echt meer?] Alsjeblieft niet hier in de organisatie. [Business cases?] Het product vraagstuk komt ergens achter aan. In het begin heb je wel een business case, vanwaar wil je dit product invoeren en waarom deze functionaliteit en daar zit je business case. Dat maakt het ook wat makkelijker, een cloud moet dan goedkoper zijn en passen. [Ander niveau?] Ik heb geen business cases als CIO. [Hoe werkt het naar projecten na keuze cloud?] Ik bepaal het. We hadden een mail systeem integratie vraagstuk, zelfde mailsysteem. We hadden strategisch partner met Microsoft, dan wordt het Microsoft. Dan is dat de business case, daar zit de fusie partner en koppeling-vraagstuk in. De vorm maakt niet uit, het past binnen het business model of het cloud is. Het gaat tussen de verschillende aanbieders. Ik heb een hele summiere investeringsprogramma, ik heb geen eigen projecten. We zijn honderd 100 gestandaardiseerd en toch heb ik geen eigen projecten. Bijvoorbeeld het medicatievoorschrijfsysteem. Dat is geen project voor mij, maar dat is een bedrijfsmanager waarin de apotheek zit en daar zitten mensen van mij in en moeten ook een bepaald architectuur hebben en daar zit de business case: voldoen we aan de inspectie en normen etc. [Klopt het tot business case?] En die discussie gaan we aan. Die rol nemen we op als architectuur bewaker. Soms wil je iets als business invoeren en dan wijkt het af van de architectuur en soms is er een oplossing en soms niet. Soms is er iets niet en dan host je iets tijdelijk op locatie. [Dus niet beginnen met cloud afnemen?] Nee dan is het techniek of trend gedreven. Dan zou heel raar zijn. Waarom zou je onderzoeken of iets dat kan ondersteunen? Op een gegeven moment komt er cloud als oplossing. Het is heel raar om te beginnen met oplossing en niet de vraag. Dat zou ik een hele rare benadering vinden. [Uitleg strategisch project]. Als je gaat kosten besparen dan kijk je waar zitten je kosten. Voor ziekenhuis is dat best wel moeilijk. En hoe verhoudt het dat tegen de opbrengsten. Het kan een tientje kost en vele meer opbrengen dan als iets honderd kost en niks opbrengt en dan moet je naar dat proces kijken. Ik ben een ziekenhuis en daar maakt een IT ook deel van uit en misschien is het wel zo duur om dat het veel te complex is. Dan kan je zeggen we gaan dit afstoten. Dan ga je kijken naar het IT component. Het IT component is dan te duur voor het proces dat we hier voeren. Je beheer last als dat hier veel is dat zou dan kunnen leiden dat je met cloud goedkoper wordt en 9 van de tien keer komt het op de business continuïteit en wendbaarheid wordt cloud gekozen. [Service moet passen binnen security policies, strategy en EA?} Als je net zo ver ben als ik dan wordt je dor je succes gedwongen. Als je geen beheer meer doet, heb je ook minder beheerders, minder kwaliteitbeheerders nodig. Als ik al vijftig procent heb uitbesteed of 70 procent in de cloud heb staan dan heb ik nog maar voor 30 % beheerders nodig en als er dan een 191
dienst binnen komt waarvoor ik veel beheer nodig heb dan moet ik mijn organisatie daarop afstemmen dan wordt het eerder een cloud oplossing. [Security geen probleem?] Dat zou dan hele vreemd zijn. Een leverancier die ene dienst afneemt zou dan iets aanbieden waarvan dat stukje niet in orde is. [Publieke internet?} Nou kijk patiënten privacy dat blijft altijd wel ene apart vraagstuk. Maar je moet wel je normale bedrijfsrisico beperken door je normale huis tuin en keuken beveiliging in orde hebben. Je moet wel een hack uitvoeren om te kijken hoe je ervoor staat of het nou binnen of buiten staat. Als je dit report ziet [consultancy report security] dan zie je dat de beveilig buiten iets kwetsbaarder is, maar de leverancier kan dat wel makkelijker aanpassen dan dat ik dat moet doen. En als ze het niet oplossen dan ga ik naar een ander. Dat is makkelijker dan dat ik dat niet kan oplossen. Ook je interne beveiliging kan kwetsbaar zijn. [Introductie governance model] Je moet iets verder gaan. Je moet je leverancier meenemen in je audit trail. Traditioneel veranderd er niets aan je verantwoording. Terwijl verantwoording en actief beïnvloeding van het resultaat zat dichter bij elkaar vroeger. Toen ik verantwoordelijk was bij IT en er zaten mensen onder je, dan kreeg je zo dingen voor elkaar. Het resultaat en output staat je verder van af, maar de verantwoording niet. Het auditen vindt dus tegelijkertijd plaats bij de vendor. Dat doen we actief. Als ze dat niet toestaan dan heb je daar speciale spelregels voor, zoals bij Microsoft, zou je op een andere manier moeten borgen en dat is ene traject die we met Microsoft hebben gedaan. Je hebt een certificering, je moet aan een aantal eisen voldoen: hoe kan ik zien dat daar beweging in zit, de continuïteit in verbetering wil ik gewoon zien. En daar kan je hele duidelijke afspraken mee maken. Dat is wel iets hele erg belangrijk. Dat is wel een spanningsverschil met vroeger, dan ging je er gewoon heen, liet je een auditor komen, nu moet je in contract opstellen, dan vindt de audit plaats, dat is je tijd voor plan van aanpak, dan wil ik zien wat je er mee doet zodat het in de volgende audit naar buiten komt. [Compliance logs?] Wij zijn nu met name hier bezig om gezamenlijk te monitoren. Stel dat zij een rekencentrum aanbieden, dat vereist ook een bepaald soort monitoring. Waarom zou een cloud provider geen inzicht geven in hun performance indicators. [ClaudAudit voor compliance logs?} Ja, dat zijn juist de dingen die noodzakelijk zijn. Dan ben je veel beter in staat om je verantwoording te nemen dan dat het vroeger was. Het is het zelfde, je noemde ITIL, beneden zie je desktop monitoring, wat doet incident management, problemen management, de performance, zelfs de CTQ’s, je kan online alles inzien van het proces. Dit lijkt op de plan do check act achtige ding. Maar je moet continue in beweging blijven heb ik geleerd. Heel vaak wordt gedacht ik ga naar de cloud dan ben ik overal vanaf, en dat is een hele foute gedachte. De leverancier is in ontwikkeling, jij bent in ontwikkeling, je verantwoording, je normen je scope, dat moet je continue herzien dit proces. [Service management processen?] Ja, dat is zeker van belang. Als je met cloud gaat werken hoef je niet ehct meer goed na te denken wat neem je af. Dat is allemaal standaard. De concessies accepteer je. Het gaat puur om het beheersen en veilig krijgen. Je moet het niet het binnen een lokaal project oppakken. Je hebt ook algemene dingen 192
waar je van gebruik maakt, dingen wel in de cloud, dingen niet in de cloud, het is wel een apart process die het project controleert. Het gebruik maken van een cloud index in een cloud oplossing voor opslag enzovoort dan gaat er een hoop binnen en buiten je project plaatsvinden, een soort risicomanagement en governance process plaatsvinden. Daarin zitten ook de business vertegenwooridgers en een controller die het gehele zonder business noodzaak het bekijkt. [Begrijp je de modellen?/nuttig] Hier (evaluatiemodel) kijk ik anders naar. Zo zie ik het niet. Dat andere model zit wel vele ervaring in wat wij hebben zit erin, maar je denkt wel altijd wel vanaf hoe het nu gaat. Iedereen heeft het over de risico’s en hoe houd je nog controle zelfs mensen die zovele van dit soort trajecten hebben gedaan die nog steeds het gevoel hebben dat ze minder controle hebben en minder snel besluiten kunnen nemen. Daarom is het wel belangrijk dat je die invalshoek neemt om te praten over de cloud. [Uitleg IT governance invloed] Neem dat sociale media netwerk van microsoft. Omdat business het gewoon gebruikt groeit het. Bij Microsoft hebben jullie allemaal verschillende emailadressen. Ik kan mij niet voorstellen dat jullie je eigen prive emailadres niet gebruiken. Zorg ervoor dan dat je je bedrijfsdingen op een makkelijkere manier gebruikt kan worden. Als zij iets anders willen gebruiken om te verwerken, liever, waarom zou ik daar iets aan doen? [Compliance?} Data is ene probleem, data in de cloud, veel staat nog private, staat in Ede bijvoorbeeld, de indexering om dat de ontsluiten dat wordt echt een audit ding, toestemmingsrechten, dat zijn hele andere vraagstukken maar wel heel leuk. [Dropbox gegevens gelekt]. Maar dat kan ook gebeuren dat je dossiers op je achterbank laat liggen. Je moet continue verbeteren en voorlichten. Elk ziekenhuis heeft beleid dat geen patiëntengegevens via de mail verstuurd wordt. Weet wel zeker dat als ik het check er patiëntengegeven wordt verstuurd. [Zijn jullie pionier?] Er zijn nog wel vraagstukken die de zorg moet overbruggen zoals je zegt om het echt van private naar de echte cloud te brengen van private lcoud naar cloud waarbij gedeeld is met andere klanten dat zijn wel de vraagstukken waar wij nu mee bezig zijn. Als wij nu de architectuur veranderen naar de twee lagen systeem dan moet het model dat wij afnemen daarop gebaseerd zijn. [Verschil tussen client/server en overal bereikbaar zijn?] Ja dan moet je wel je portal achtige constructie maken zodat je erbij kan. Met cloud kan het overal en altijd heel gemakkelijk. Wat ik erg belangrijk vind is multioutsourcing. Dat private cloud bij 1 aanbieder daar moet je echt van afstappen. Het is bij ons gegroeid van outosurcingstraject naar meerdere partijen. Megamulti. En het moeilijkste van Cloud en outsourcing is het managemen. Het multi outsourcings vraagstuk management is wel een hot topic en dat is iets waarvan ik nu echt een lessons learned hebt om bewust op te zoeken. Een verbetering om de integratie laag, multi outsourcing integration, dat is mijn service organisatie. Wat vroeger een helpdesk was wordt nu een integration service. Dat is zo belangrijk om goed in orde te hebben. De integratievraagstuk is de kern, dat moet je eerst goed krijgen, we keken ook eerst naar de integratie standaarden, daar zijn mensen hier ook in opgeleid en dat is ook eigenlijk de wel de kern van de succes. Dat is jouw kennis en bedrijfswaarde.
193
Information Security progam manager [Expert 8] [Introductie van cloud evaluation model] Je bent er mee eens dat corporate governance over niet alleen IT gaat? Die gaan niet de business case van cloud maken, maar dat is afhankelijk van hoe groot de organisatie is. De IT managers doen dit, de CIO heeft ms daar mee te maken maar ik denk dat het er een level onder is. Ik denk dat je strategie bepaalt wat je nodig is hoe snel de omgeving om je heen veranderd en dat bepaalt of je wel of zoiets moet doen. [Wel strategische keuze?] Ik denk dat in je strategie niet iets wordt genoemd of er al een keuze wordt gemaakt voor Gmail bijvoorbeeld, in een strategie schrijf je iets voor de komende jaren. Die wordt bovenin de organisatie afgesproken en dat wordt naar beneden uitgerold. Als ik onderin een pakketkeuze maak moet ik teveel veranderen. De strategie bepaalt wat je eventueel gaat doen, bijvoorbeeld we gaan veel met mails werken en daarom gaan we met een derde partij werken. Ik denk dat je bij strategie op hoog niveau moet kijken en niet operationeel bezig moet zijn en echt op een ander level moet zitten. Ik denk dat het heel erg afhankelijk is van de type organisatie waarin je zit. Bijvoorbeeld een ziekenhuis moet aan sommige regels voldoen en dan denk ik niet dat zij in de strategie over Gmail praten. [Cloud wel?] Op strategisch niveau denk ik dat je zegt we doen alkeen maar waar we goed in zijn. Een ziekenhuis is goed in behandelen van patiënten en niet goed in IT en daarom hebben zij een IT desk en die maken de keuze om iets in cloud te zetten, Wij bij onze school zeggen we zijn goed in doceren en de IT desk moet ondersteuning bieden en die kijken naar of zij zelf iets moeten doen of iets in de cloud doen. Heel veel stukken van ons zijn toch openbaar, we willen dat we kennis uitdragen, dus als het geen gevoelige gegevens inzitten, kan het zo in de cloud. Dat is een uitwerking van de strategie, niet de strategie zelf. Het is een oplossing van een probleem. [Op IT desk niveau?] Die wordt wel aangestuurd door de CIO. Maar op dat niveau wordt het bepaald ja. Wij hebben bij ons geen raad van bestuur, maar een college van bestuur en die bemoeid zich er niet mee, de CEO moet wel goedkeuring geven want die is verantwoordelijk voor het budget. [Vanaf strategie?] Dat is een hele andere vraagstuk, wij moeten iets met cloud want de wereld doet het, dan kijk je vanuit je strategie. Voorheen konden we niet zeggen we hebben een komende schoolperiode en daarom hebben we in januari duizend servers nodig en normaal veel minder. Met cloud kan dat zomaar. Dan is het al snel duidelijk wat de voordelen van cloud zijn. [Cloud strategie?] In de wereld van de IT zie je de verschuiving naar cloud en tegelijkertijd is het de security afdeling die het tegenhoudt, maar tegenwoordig zeggen veel providers dat ze kunnen garanderen waar de data staat. De problemen zijn nu een stukje security en privacy, is het wel veilig? Ze zeggen van ja we versleutelen alles. Maar als iemand binnenkomt en je data verliest, dan ben je het nog steeds kwijt. Er zijn altijd mensen die kunnen erbij om het te ont sleutelen of bits aan te passen, dan krijg je het berichtje ‘mogelijk beschadigd bestand’. Heel vele mensen realiseren niet dat als ze iets doen met Hotmail bijvoorbeeld dat je iets met Amerikaanse servers doet. Dat is makkelijk, maar je data staat dan in Amerika. Dat zie je nog steeds heel veel. Het is interessant dat het nog steeds zo is. Er zijn nu wel steeds meer providers die kunnen 194
garanderen waar je data staat. Wat ik interessant vindt, als je uitbesteed naar de cloud, dan wordt er een SLA gemaakt. Bestaat er een deel erin wat de security, compliance aspecten bevat? [Cloud governance model laten zien] Waarom vanuit ITIL? Ik heb een beetje gevoel dat dat ligt aan de mensen met wie je gesproken hebt. Natuurlijk is ITIl veel gebruikt maar er zijn ook anderen. [Uitleg service management gescoped volgens ITIL] Als we een stapje terugdoen, niet kijken vanuit cloud maar van een standaard organisatie. Als je nu gaat zoeken naar security controls voor gewone organisaties is het ook lastig te vinden. Een ISO kan je ook nog cherry picken voor de maatregelen die je nodig hebt. Voor de cloud lijkt mij dat ook. Je riep over risk appetite, dat wordt bepaald door een risico analyse. Als organisatie kies je ergens de keus wat je wel en niet in de cloud komt te staan en ik denk dat je over het stuk dat naar de cloud toe gaat en het stapje daarvoor wat mag er en wat mag er wel in de cloud. Bij verschillende ministeries zie je dat de managers alles maar in de cloud stoppen. Dan kom ik overal bij, maar anderzijds zeggen zij ook van ja niet alles mag en dat gaat in de private cloud en dat wordt door defensie zelf beheerd. Ik denk dat je het zelfde hier moet afvragen wat mag wel wat ,mag niet dan krijg je zelf risico analyse van welke informatie gaat er de cloud in, welke assets wordt er overgenomen, welke assets houdt je zelf en wat staat erin die assets en dan per organisatie bepaald het welke controls je nodig hebt. [High level security controls is uniek] Dit stukje risk management process waar ik op instak, wat mag er wel of niet in de cloud, dat komt door het risico proces, dat heeft een bepaald leidraad, maar de data classification is een probleem. Hee veel organisaties komen naar ons toe van kan je onze data classificeren. Wanneer is iets vertrouwelijk en wat niet. Sommige bedrijven hebben vijf lagen van data. Dat is een uitdaging. Dat heeft ook te maken met je readiness terwijl ze geen classificatie hebben en monitoren en loggen doen ze niet eens. Ik denk dat je dit duidelijker kan maken, de SLA, als je iets roept over CIA, confidentialy, itegrity and availability. Je zou bij de SLA dat al noemen. Als je afdwingt in de SLA over integriteit en beschikbaarheid, los van dat er al een stuk staat. Maar dan zou je apart kunnen gaan benoemen, dat je bepaalde vertrouwelijke data altijd juist en volledig moet zijn en altijd zoveel procent beschikbaar moet zijn. Ik denk dat als je dat hier aanschrijft dan kan je bij availability plans van wat als de samenwerking stopt. Vendor negotiation en evaluation is ook belangrijk. Dit komt erg overeen met het werk van Eric Beulen over outsourcing. Dit is heel erg herkenbaar. Welke vragen heb je nog meer? [Monitoring/audit are processes or risk controls?] Ik denk dat het een apart auditing process is, dan moet je altijd rekening mee houden met drie aspecten, bestaan, opzet en werking. Op het moment dat je een auditing doet op opzet dan komt er een auditor langs die vraagt wat heb je gedaan dan zeg je hier is mijn draaiboek en daarin staat alles wat er gedaan is, zo kan je laten zien dat opzet werkt. Gaan we stap verder, bestaan, dan gaan consultants praten met medewerkers: er staat in de login dat jullie 1 keer per maand eem backup maken, ok check. Bij 1 stap verder, werking, dan wilt het een totale log krijgen van een gedurende periode. Bij governance gaan die audits terug naar boven. Bij auditing heb je internal en external, welke eisen zijn er, het kan zijn dat je door bepaalde compliance wetgeving verplicht bent een externe auditor te laten komen. Zit je bij een bankaire sector, dan zal die van jou een externe audit eisen. Kritieke assets moeten misschien wel 2 a 3 keer per maand geaudit worden. Het zou daarom niet misstaan om een apart audit proces op te nemen. [Niet van risk management?]
195
Risk management is een process, met een plan do check act cycle, maar daarin gaat ook al veel mis. We hebben wel eens bij bedrijven zon risico analyse gedaan, waarin we de risico’s hebben geïdentificeerd en de controls ingevoerd en dat is het. Maar wat wel belangrijk is, en dat zou je security management kunnen noemen, management weer in wat mij betreft, waarbij je telkens blijft scannen, veranderd er iets, zijn er mensen die zich hebben omgeschoold en daardoor treden omhoog zijn gegaan in de organisatie, moeten die andere rechten krijgen. Als die control niet wordt aangepast of zij de juiste toegangsrechten hebben gekregen kloppen die niet meer. Daar moet een stukje plan do check act op van toepassing zijn en een stukje auditing erop die gaat bekijken jij zegt dat er role based access is zouden deze medewerkers deze rechten moeten hebben dan gaan wij dat controleren. Ik zie de log, bestaan klopt, de medewerkers zeggen ook van ja, dus opzet check, werking dat kan helemaal niet want deze man kan daar en daar en daarbij. Dat is verklaarbaar, want de man is van die functie naar die gegaan. [Dus audit is los?] Ja, risk management is alleen het stuk wat zijn op dit moment de risico’s, dat is een periode in de tijd dat je dat doet. [Security management zijn processen of controls?] Ik denk dat er verschillende niveaus door elkaar gaan nu. Een SLA is een bepaald document, compliance logs ook, maar ga je het over controls hebben dan is dat variable, de security controls zijn afhankelijk van risk management, ook data movement is afhankelijk, omdat iets wat nu sensitive is hoeft dat later niet meer te zijn. Ik denk wel dat het belangrijk is dat het hier wordt toegepast. Data movement vind ik een security control , dat moet je zeker monitoren, dat is zeker een control je wilt weten wat er met je data gebeurd en waar het staat en dat komt terug met je classificatie. Auditing is dermate belangrijk, dat ik dat los zou trekken. Er komt een stukje compliancy en wetgeving kijken, en je moet het aantonen, dat is wat een auditor wilt. Je moet zorgen dat als je aan bepaalde standaarden voldoet je dat ook nog doet als je naar de cloud gaat. Als je zegt dat je volgens eem bepaalde ISO werkt en wel aangeeft dat je gebruikt maakt van IaaS dan wil diegene ondanks een cloud oplossing wel aangeven maar ik heb mijn SLA apart op basis van CIA een bepaalde risico analyse gedaan en deze risico zijn nog steeds van mij, want dat is wel spannend gebied nog, bij wie ligt het risico en verantwoordelijkheid. Daar schijnt nu het ene en andere qua vraagtekens te liggen, sommigen zijn van mening dat als jij je data outsourcet de verantwoordelijkheid ook bij die provider ligt. Daar ben ik het niet mee eens. Je zou in je SLA iets kunnen roepen over de CIA. Die zou je lost moeten adresseren. Vanuit je risk management proces bijvoorbeeld van ISACA dan kom je heel vaak uit van de assets die je in je cloud hebt zitten en je rate van confidiatiality, rate van integrity, rate van availabilit en ik denk dat die daarom toch wel de output is van het risk management process. Dat je dat kan gebruiken data classificatie is echt een matgele. Dat is het enige dat als ik naar je model kijk zie ik verschillende niveaus: SLA en vendor requirements is op hoog niveau en data classifications is echt een control. Als ik ernaar kijk zie ik het overkoepelende niveau van plan en engage voor de managers die willen weten wanneer het klaar is. Dan krijg je hier wat gebeurd er in die stappen. Misschien dat je een mapping kan maken van wat hier voren komt om naar een totaal model te maken. Na een risk management process bepalen wij what in de cloud. [Control anders dan een process?] In de literatuur is control een maatregel. Dus je kan een control hebben zoals data classificatie. Je hebt als maatregelen data classificatie, dat blijkt uit je risk management proces. Data classificatie hebben wij nog om drie nievaus en dan hebben wij apart proces die bepaald wat gaat er in level 1 in level 2 etc. 196
[Zijn dit controls of activiteiten?] Ja, mitigeren van die risico’s aangaande van en naar de cloud gaan. Het zijn meer stappen dan controls. Binnen het process passen controls. Auditing is een process, geen control. [Monitoren compliance is auditing process?] Dat zou kunnen. Internal security controls zit eigenlijk in het risk management process, omdat het een proces is blijf je het continue monitoren. Network security is 1 van de. Je ziet heel vaak over cloud en security hebben ze het ook vaak over Identity and acces managent. Drie keer a krijg je dan. Als ik kijk naar je model, die bovenste stappen maakt het heel duidelijk dat er een vier stappen plan is. Waarbij mensen bij plan fase rekening moeten houden om met bepaalde aspecten zoals je hier hebt geschreven, maar ook hoe zit het met privacy, dat heb je ws al uitgezocht. Hier komt weer SLA en negotiation weer terug en blijkbaar ga je in gesprek met mensen. Bij engage moet je al goed rekening houden dat je geen vendor lock in hebt. De internal security is wat je wenst van de provider. En het is bij ons, als je kijkt naar dit model, de infra in de organisatie en data dat erop staan, mensen werken in processen, die hebben data en die werkt op infrastructuur. Bij internal security gaat risk management over die drie aspecten heen, of we nou SaaS of IaaS invoeren, de risk management gaat ook over je mensen en processen heen. Ik denk altijd dat interne security en risk management proces ook over het geheel gaat. Ik begrijp nu dat het enkel alleen over SaaS en IaaS en PaaS gaat. [Uitleg risk management] Ik denk dat het hier al zit, ben je ready. En nogmaals, als ik de link leg met het normale outsource verhaal. Je bent pas ready als je zit op het derde niveau van Cobit. Als je kijkt naar het cmmi model zeker bij COBIT 5, als je op niveau 3 zit ben je ready. Volgens mij moet je je security eisen los stellen van het outsource verhaal. Je moet weten waaraan je moet voldoen. We moeten conform bepaalde regels handelen, of je wel of niet outsourced. Van te voren moeten je die al hebben anders ga je alles tegelijk doen. Eerst moet je een bepaalde baseline, een basisniveau wat je accepteert en dan kan je zeggen dat je vanuit het proces met een bepaalde input en output. Wat ik meestal doe is bepalen: wat is onze bestaansrecht, welke bedrijfsprocessen dragen primair bij aan onze strategische doelen en daarom zijn die belangrijk. Als we het over een primair proces gaan hebben dan kan het wel dat het meer indepth gaan naast basis beveiliginsdingen. Als we kijken naar onze CIA wat is nou echt het belangrijkste en nemen we voor zon primair process aanvullende maatregelen als je dat eenmaal in kaart hebt en je beslist om je assets van primair processen in de cloud zet dan zorg je van te voren al dat het goed zit, anders krijg je hier ineens alles. Data classificatie invoeren, maar we weten niet eens wie welke rechten moet hebben terwijl je in de cloud zit werkt niet. Veel consultants maken het veel mooier dan het is, terwijl je de outsourcet partij niet eens kan aansturen. [Security management process controls?] Ja. Het hebben van een CMDB met het hebben van daarbinnen allemaal assets en die koppelen aan de primaire processen en daarmee bepaald output markeren als CIA. Bijvoorbeeld de confidiatiality is hoog en als dit binnen de cloud staat dan moet je hiervoor hoge maatregelen stellen. Nu lijkt het of je alles hier moet doen en dan op het einde je processen opeens. In de ‘plan’ fase moet er al een hoop gebeuren qua security. Er zijn mensen die willen dit graag achteraf doen, vooral de business, dat is ook wel zo, alleen als je dadelijk helemaal niet meer kan reageren omdat de concurrent al onze business plannen hebben en ook al hebben gehandeld dan hoef je niks meer in de markt te zetten. [Monitoren van events een proces?] COSO is helemaal gemaakt voor compliance. Die kan je misschien onder security management stellen.
197
[Uitleg security management?] Ik versta onder security management een proces waaruit controls komen. Het kijken naar compliance komt ook voor in security management. Een ISMS start om te kijken welke wet en regelgeving er zijn en welke maatregelen er dan moeten zijn. Verderop krijg je stapje naar risk appetite en welke risico’s accepteren we en welke brengen we onder controls. Er gaat wel een hele proces vanuit. [Wat is het verschil met risk management?] Risk management is het stuk waar men in mijn optiek mee moet starten en security management is het overkoepelende stuk. Risk management is onderdeel van security management. Informatiebeveiliging bijvoorbeeld, we willen maatregelen treffen om risico’s te beperken en daar stopt het. Security management gaat kijken naar wat zijn de maatregelen, zijn die nog wel voldoende en belangrijk, het kijkt ook naar de mensen. Bij risk management laat je de mensen teveel met rust. Een firewall instellen lukt altijd wel, maar er zijn altijd mensen die denken van, hey ik kan deze poort vast open zetten. Je hebt nu ook security management. [Uitleg security management processen (acces control)] Het is wel breder dan dat. Acces control is echt een control. Het geeft aan wie waar rechten toe heeft en waarom. Dat wil je management. Ik noemde airbac, dat is eigenlijk acces management. [Key management?] Wat versta je eronder? [Uitleg key management] Ja, dat zie ik echt als een control [En service management processen/ITIL zijn geen controls?] Ja zeker, een ITIL proces is voor mij, bv service delivery se. Dan zie je dat er een incident binnenkomt, een incident wordt geregistreerd, en dan wordt het eventueel geëscaleerd. Dan ga je richting problem management, dan richting change management en release management, dan krijg je de eerste echte koppeling. Dat kan al bij incident management als er een info security probleem wordt geregistreerd dan wordt de security officer erbij betrokken. Is het een change, dan moet er een change advisory board moeten zijn en afhankelijk van de change moet er een security manager bij zitten van ja leuk dat we iets veranderen, maar dit is een primair process wat ermee te maken heeft. Zo zie ik meer ITIL processen. De security management lijken meer controls. Maar je kan het ook hoge trekken: hoe zit het met de mensen, de cultuur, de structuur. Security management is breder. Risk management ligt hier, sec management natuurlijk ook. Want Risk management is een onderdeel, maar het is veel meer. Het begint met het kijken hoe het staat met risico’s en wat we eraan gaan doen. Maar vergis je niet dat we ook te maken bij security management te maken hebben met compliancy. Risico’s hebben ook te maken met die wet en regelgeving. Security management is overkoepelende tak en risk management valt daarbinnen. [Bij cloud literatuur vooral risk management] Dat is logisch, bij cloud kijk je enkel dit stukje, daar kijkt security management ook naar. Het is een bepaald risico dat veranderend. Waar je voorheen intern ging inloggen doe je nu via een SSl verbinding. Dat zijn allemaal controls. [ITIL heel project of enkel operationeel?] Daar ben ik het mee eens. Een project in mijn optiek start je om er later met je processen er mee verder te kunnen dat draai je niet om. 198
Appendix J: summary expert interviews (second feedback round) Cloud evaluation model Interviewee
CIO
Strategic IT advisor
User 8
Cloud infrastructure consultant (expert) (telephone interview) Expert 7
Information security program director (expert) Expert 8
ID
User 6
Organization
Hospital
Own company
Consultancy company
University of applied science
Understandability
No problems.
No problems.
Usefulness
Model does not depict my activities: cloud adoption decision is done on project level and I don’t lead projects.
Maybe provide methods/tools then it will be very usable.
Information is correct.
Information is correct.
Model can be used as part of sourcing strategy or on project level.
The IT managers do this. It could be the CIO is involved, but I think it happens lower in the organization.
Information accuracy
Cloud does not start with strategy: it starts as a solution to a problem. Also, migration restrictions count. A business case is made for a specific product and functionality. A cloud solution must be cheaper. You don’t start with cloud, than it will be technical driven. It starts with a problem.
Additional commnents
Service definition could be made more clear: what is a service? I recognize many things. It are minor details, but it is correct.
Model can be used as part of sourcing strategy or on project level (top down, bottom up).
Cloud Governance model Interviewee CIO
Strategic IT advisor
CSO
ID Organization
User 6 Hospital
User 8 Own company
User 7 University
Understandability Usefulness
No problems. Yes, even someone who has done tens of projects still discuss cloud security and
No problems. This model is good. The other one (initial framework) is too detailed.
No problems. For IT managers and CFO this is really interesting.
Cloud infrastructure consultant (expert) (telephone interview) Expert 7 Consultancy company
Information security program director (expert)
Expert 8 University of applied science
199
Information accuracy
Additional comments
gaining control. Good perspective for the model. You have to take your provider in the audit trail. You want to see their improvements. You are still accountable if you use cloud. The whole risk management process is also a continuous thing, your regulations change, your providers change. Cloud governance is all about controlling the cloud service and making it safe. There is a higher level governance process which looks at the solution on a bigger scope, as part of portfolio or value management, but that seems to be covered.
Really interesting what to do when you lose control. Not knowledgeable on cloud.
This reflects the practice, but other model (initial framework) reflects how it should be.
Information is correct.
Information is mostly correct, but use same kind of concepts. SLA requirements is activity, data classification is control. Implement internal security should be done before (readiness). Security management processes are controls. Audit is important process. Maybe add CIA to beginning. Security management is broader than risk management.
Maybe exact roles between provider and consumer would be interesting.
200
Appendix K: tools, techniques and additional information According to an interviewee [User 8] in the feedback-phase on the revised cloud evaluation framework, tools and techniques should be added to the cloud evaluation model to make it more usable. This appendix covers these tools and techniques. Although none has commented on additional tools for the cloud governance framework, for comprehensiveness, tools for this framework are also addressed. These tools, techniques and additional information enabled management to actually perform the activities in the models, although these could be delegated by lower managers. The cloud governance model is developed in order to provide higher management insights into what the governance of cloud solutions entails. The actual execution of the activities could be done by lower managers, such as risks managers or service management experts. The tools could be used by these managers which make the model also usable by these stakeholders. Higher management could also make use of the tools themselves, if they choose to perform the activities. An important note is though, that these additions are not the result of scientific research. They could be commercially oriented or lack in scientific quality, which should be kept in mind. They are not part of the scientific framework developed in this research. First, the method for identifying these tools is shortly discussed. Hereafter, the tools, techniques and additional information sources are presented for the two frameworks.
Approach Tools, techniques and additional information for the cloud governance and evaluation frameworks are identified accordingly:
Additional information, tools or techniques which were found during the literature scan of the original literature review were added. If multiple tools or documents were found which covered the same information, scientific findings would be favored above non-scientific tools. Also their position in ‘Google Scholar’ (for scientific tools) and in ‘Google’ (non-scientific tools) is taken into account when choosing between two scientific or two non-scientific sources, as this shows their popularity. This is considered to be a determinant for their usefulness.
If no models were found, a short literature scan in ‘Google Scholar’ and ‘Google’ was performed. The first 5 pages of results of each method were taken into account. The choice of model and tools was first based on title and summary, then the whole article was read.
201
Tools and techniques for the cloud governance framework Cloud governance consists out of the risk-reducing controls and the processes to manage cloud solutions. It is assumed additional material could be useful for both the implementation of the processes as performing the risk-reducing activities. However, not much literature was found on the processes which need to be implemented for cloud computing. The only paper which was found on service management processes, was that of Jansen (2010). For the risk management process, the adaption of COSO for cloud computing (2012) can be used. Both of these publications were part of the literature scan of the literature review. With regards to implementing the data classification, the SeCA model (Spruit & Baars, 2012) provides an example of a data classification, which can be used with their model. A more detailed publication was found through an additional search in Google, as no scientific framework or method was found. The publication in the journal of ISACA (Etges, CISA, CISSP, McNeil, n.d.) provide in-depth information on how to implemented and establish a data classification. The keywords ‘Data classification PDF’ was used, as with the word ‘PDF”, tons of websites with short articles were retrieved. This publication was found as the sixth result in Google. Although this was thus not the highest one, it was perceived to be the most valuable and trustworthy, as ISACA is a well-known and credible source. The next activity is to determine risk-reducing requirements of the provider and the SLA. Many are mentioned Appendix A of this research. Further, the SeCA model (Spruit & Baars, 2012) provides some requirements for the cloud solution and the provider by taken into account the data classification. A very extensive tool which was found in the original literature scan, was the ‘Cloud Controls Matrix’ of the CSA (2011). In their document het have published all the necessary security controls which need to be implemented at consumer’s and provider’s site. These can be used to determine which controls the cloud provider must have implemented. They are also a very good source for the internal controls of the consuming organization. These are also mentioned, at a higher level, in Appendix A. This Appendix A does cover all the availability-risk reducing strategies (such as exit strategies) and aspects which need to be monitored. For more specific information on a certain control, the publication in which it was mentioned can be retrieved.
Element
Implement data classification
Support
Tool and origin Original literature scan
SeCA model (Spruit & Baars, 2012)
Additional scan in ‘Google Scholar’ Nothing found.
Additional scan in ‘Google’ Etges, R., CISA, CISSP, McNeil, K. (n.d.) Keywords: “Data classification PDF”
202
Determine SLA and Vendor requirements
Vendor and SLA requirements.
Negotiate and evaluate vendor & SLA Implement internal security
Vendor and SLA requirements.
Develop availability-risk reducing strategies
The availabilityrisk reducing strategies which need to be developed. The exact aspects which need to be monitored.
Monitor
The exact internal security controls which need to be implemented.
Element Implement internal security
Appendix A Cloud Controls Matrix (CSA, 2011) SeCA Model (Spruit & Baars, 2012) Same as above.
Appendix A Cloud Controls Matrix (CSA, 2011)
Appendix A
Appendix A
Tool Appendix A
Cloud Control Matrix (CSA, 2012)
Implement data classification
Determine SLA and Vendor requirements
SeCA model (Spruit & Baars, 2012) Etges, R., CISA, CISSP, McNeil, K. (n.d.) Appendix A CCM matrix (CSA, 2011)
SeCA model
Not needed.
Not needed.
Not needed.
Not needed.
Not needed.
Not needed.
Not needed.
Not needed.
Not needed
Not needed
Description An overview of the internal security controls which must be implemented is shown in Appendix A. How they should be implemented is not mentioned though. A detailed description of the security controls which must be implemented at consumers site are listed in this document, based on the cloud model and security standards (e.g. PCI). This research presents a possible way to classify data, which then can be used with their model to determine certain provider requirements. Detailed document on how to develop a data classification. An overview of the SLA and vendor requirements which must be taken into account. An extensive list of security controls, mapped to security standards (e.g.PCI), which can be used to determine which security controls the vendor must implement. This model provides provider requirements based on the classification of the data which is put in the cloud.
Negotiate and evaluate vendor & SLA
Same as above
Develop availability-risk reducing strategies
Appendix A
An overview of the availability-risk reducing strategies which must be developed.
Monitor
Appendix A
An overview of the aspects which must be monitored by the consumer.
203
Tools and techniques for the cloud evaluation framework For the first activity, ‘Cloud need’ the benefits and risks on a high level are considered to be of support. Two comprehensive sources were found during the original literature review: a document of the respectable organization ENISA (2009) on the risks and benefits of cloud computing and an online tool planforcloud.com (see section 4.2.1.1.), which is based on scientific publications. Also, Misra and Mondall (2011) (section 7.1) provide a tool to determine the overall suitability of cloud computing for the organization, based on the sensitivity of data the organization is handling, the utilization pattern of the resources and the critiqueality of the work performed. For the readiness assessment online questionnaires can be used. The one of EMC, the ‘Cloud Flight Check’, is the highest ranking tool in Google which covered a readiness assessment for cloud computing. A short new literature scan did not identify any scientific cloud readiness assessment tool. One document was presenting a ‘cloud readiness tool’, but this entailed selecting cloud candidate applications. This ‘cloud readiness tool’, the ‘Magic Matrices Method’, (Loebbecke, Thomas & Ullrich, 2011), which was found when using the keywords ‘cloud readiness assessment’, supports the activities of choosing cloud candidate applications. The factors for choosing cloud applications correspond to the ones included in the cloud evaluation model: core business (Strategy / Enterprise Architecture), Availability (Security policies / data classification), Standardization (Strategy / Enterprise Architecture), Network Connectivity (Network), Compliance (Security policies / data classification) and Identity Management (Integration). One factor was not identified though, namely ‘Degree of Contribution within Continental’, which refers to the centralization of management tasks related to the service. The tool planforcloud.com does not only provide the benefits and risks of cloud computing, but also offers the option to evaluate different cloud models. This website is therefore also considered to be of support to the activity of choosing a cloud deployment and delivery model. The ‘SeCA’ model (Spruit & Baars, 2012), discussed in the section on related information security governance frameworks (section 6.4) supports choosing a cloud model based on a data classification and the data which belongs to the cloud candidate application. Both of these tools should provide a basis for selecting the deployment and delivery model which will be elaborated through the business case. The Australian Government (2012) has provided a business case template specific for cloud solutions. This template corresponds to the findings of this research, to include the benefits, risks costs of the cloud application and to assess the organizational impact to get a clear picture of the changes cloud computing brings to the organization. To determine the benefits, risks and costs planforcloud.com can be used. Also ENISA (2009) provides an overview on the benefits and Li, Li, Liu, Qiu, and Wang (2009) have proposed a mathematical model to determine the TCO. No tools, techniques or methods were found to assess the impact of cloud computing on the organization.
204
The tools and the process for selecting them are shown below. Element
Cloud Need
Support
Cloud risks and benefits on a high level could be of support to determine whether cloud computing could be beneficial to the organization.
Tool and origin Original literature scan
Readiness
Service definition
Planforcloud.com is a website based on scientific publications and provides the benefits and risks. The extensive document of ENISA (2009) provides a comprehensive overview of cloud benefits and risks. Misra and Mondall (2011) provide an overall suitability tool.
A questionary could support assessing the readiness of the organizational capabilities for cloud computing.
None was included.
A tool to select cloud candidate applications could be of support.
None was included.
Additional scan in ‘Google Scholar’
Additional scan in ‘Google’
Not needed.
Not needed.
Not found.
'Cloud Flight Check’ developed by EMC was highest ranked.
Keywords: “cloud readiness assessment”, “tool, technique, method”.
Keywords: “cloud readiness assessment”, “tool, technique, method”.
The ‘Magic Matrices Method’, (Loebbecke, Thomas & Ullrich, 2011) is a tool to select cloud candidate applications.
Not needed.
Keywords: “cloud application selection”, “tool, technique, method”.
205
Cloud model
Tools or methods which support selecting a cloud delivery and deployment model are considered to be beneficial.
Business case
An organizational impact analysis tool, a business case template, a cost calculation method and an overview on the risks, costs and benefits are considered to be of support.
Planforcloud.com is a website based on scientific publications and provides the option to compare different cloud models based on the benefits and risks. The scientific ‘SeCA’ model (Spruit & Baars, 2012), supports selecting a cloud model based on the data classification. No business case template was found. Planforcloud.com provides a tool to calculate the total cost of ownership of deploying a cloud solution. Li, Li, Liu, Qiu and Wang (2009) provide a mathematical model to determine the TCO. Planforcloud.com also provides an overview on the risks and benefits. No tool was included to support organizational impact analysis.
Not needed.
No tool was found to support organizational impact analysis. No business case template was found.
Not needed.
Keywords organizational impact: “organizational impact analysis”, “cloud computing”, “tool”. Keywords business case: “Business case template”, “cloud computing”. Table 34: process of adding tools and techniques to the corresponding table of the cloud evaluation model.
No tool was found to support organizational impact analysis. Australian government provides a business case template for cloud solutions. Keywords organizational impact: “organizational impact analysis”, “cloud computing”, “tool”. Keywords business case: “Business case template”, “cloud computing”.
Step
Tool
Description
Cloud need
planforcloud.com
This website provides the benefits and risks for multiple cloud models. This document provides an extensive list of risks and benefits of cloud models. Provides a suitability method to assess the organizational suitability for cloud computing. An online tool to assess the readiness of the organization to move to the cloud.
ENISA (2009) Misra and Mondall (2011)
Readiness
'Cloud Flight Check’ (“EMC Readiness”, n.d.)
206
Service definition Cloud model
Magic Matrices Method (Loebbecke, Thomas & Ullrich, 2011) Planforcloud.com SeCA model (Spruit & Baars, 2012)
Business case: Organizational impact Business case: Costs
Planforcloud.com Li, Li, Liu, Qiu, and Wang (2009)
Business case: Risks Business case: Benefits Business case: Develop Business case
Planforcloud.com ENISA (2009) Planforcloud.com ENISA (2009) The Australian Government (“A guide to”, 2012)
A model to select cloud candidate applications. It is not validated. This website provides the benefits and risks for multiple cloud models. A model which helps determining security measures for reducing cloud related risks, including selecting the appropriate cloud delivery and deployment model based on the classification of the data which will be put in the cloud. No tool was found. See above A Total Quality Of Ownership model for cloud solutions. See above See above See above See above A business case template for cloud solutions, which also take into account the relevant factors identified in this research, namely the organizational impact, risks, benefits and costs.
207
Appendix L: existing frameworks analysis In this appendix existing frameworks are discussed whether they could be used as a basis for the developed framework. They cover the two objectives of this research: assist management with the evaluation of cloud computing and provide insights into cloud governance. Whether the frameworks provide a sufficient basis to act as a foundation for the development of the cloud evaluation and governance framework, is based on the framework requirements.
Cloud evaluation frameworks This research addresses cloud evaluation through integrating the organizational impact, risks and the business case. An existing framework needs to include these elements.
A cloud evaluation framework is considered to be an appropriate starting point when it includes the organizational impact, risks and business case.
Two evaluation frameworks exist which aim to assist decision-makers whether to move to the cloud. Also, one framework deals with the migration of moving legacy applications and two adoption frameworks provide the activities to adopt cloud solutions. None of them integrated the cloud risks, organizational impact and business case for cloud computing. However, the ‘Cloud Adoption Toolkit’ comes close to the research objectives of providing assistance in moving to the cloud (Ali Khajeh-Hosseini et al., 2012). But as the business case is not included in the model, it is chosen to not use this model as a foundation to build upon. Research
KhajehHosseini et al. (2012)
Klems et al. (2009).
Beserra et al. (2012)
Conway & Curry (2012)
Shimba (2010)
Name framework
Cloud Adoption Toolkit
-
CloudStep
Managing Cloud Computing-A Life Cycle Approach.
Scope
Evaluate cloud computing.
Evaluate cloud computing.
Cloud adoption activities
Risks
A sheet is provided with the cloud risks and the risks are part of the decision making process. Impact on stakeholders is addressed as a step, but no
No
Evaluate whether to move legacy systems to the cloud. Takes into account security related constraints.
ROCCO: Roadmap for Cloud Computing Adoption Cloud adoption activities
No information, but it is taken into account.
No information, but it is taken into account.
Takes into account organizational constraints.
Included as activity.
Included as activity and in their research it is discussed.
Organizational impact
No
208
information is provided. Business case
While costs are calculated, the business case is not included.
Requirements and costs are included, but no business case.
Use this model for development?
No, business case not being referred to.
No, does not address any of the aspects.
Takes into account financial aspect of cloud solutions, but not business case. No, is focused on which legacy systems to deploy on the cloud, not on the overall decision of moving to the cloud.
No.
Mentioned in their research, but not in model.
Business case not being referred to. No information on organizational impact.
Business case not being referred to.
Information security governance frameworks The governance frameworks which do solely focus on security could also be used if they provide a high-level overview on the risk-reducing controls for cloud solutions.
A cloud information security governance framework is considered to be an appropriate starting point when it provides high level overview on the risk-reducing controls.
Three security governance frameworks propose a certain form of collaboration architecture between providers and consumers to safeguard the assets. Further, one framework can be used to classify services based on data classifications. However, none of them provided an overview of the security controls of cloud computing and are therefore not considered as a good starting point for developing the framework. Authors
Jericho (2009)
Forum
Julisch and Hall (2010)
Focus
Assist in choosing cloud formation & collaboration architecture
ISMS for cloud services
Security controls
Does not address security controls.
Addresses only the collaboration with provider, not security controls.
Use this model for development?
No, does not address security controls.
No, does not address security controls.
Ahmad and Janczewski (2011) Joint Governance Board for ‘bridge’ between consumer and provider. Does not address security controls, only a theoretical decision making framework. No, does not address security controls.
Almorsy et al. (2011)
Spruit and Baars (2012)
Alignment of FISAM security standard with cloud computing
Assist in choosing cloud service based on data classification.
Does not address security controls, only a theoretical security architecture. No, does not address security controls.
Addresses only the requirements of the services based on data classification.
No, to small scope.
209
Cloud governance frameworks Cloud governance is in this research is perceived as the security controls which need to be applied and the processes which need to be implemented for managing cloud solutions. As the target group is higher management, a high level view on these processes and controls must be given to provide these rushed managers a bird-eyes views on cloud governance. Also, a second layer of governing cloud solutions was identified in this research, which follows the activities of ‘evaluate’, ‘monitor’ and ‘direct’. A framework addressing the high-level overview on risk controls or the processes or the top management activities which deal with the implementation of cloud governance is seen as a foundation to build the artefact on.
A cloud governance framework is considered to be an appropriate starting point when it provides high level overview on the risk-reducing controls or processes, or the top management activities implementing cloud governance.
ISACA’s framework (2012a) is very comprehensive, but does not provide a clear, high level overview and risk controls are not addressed explicitly. Also, as the goal of COBIT is to provide process controls (what the processes should do), not processes, it is mere an audit tool. Guo, Song and Song’s (2010) framework is focused on implementing SOA techniques and only applicable when an organization has to govern a big amount of services. He’s (2011) framework did address many of our objectives, but does not provide information on the risks aspect of cloud computing and because of its resemblance to SOA governance, it seems overkill. It can be concluded none of the frameworks provide the processes or risk reducing controls for cloud computing that adheres to the view of cloud governance of this research. Therefore none of the models will be used as a basis for development, but a new artefact will be created. The frameworks are summarized in the Table below.
Frameworks Focus
ISACA (2011) Control objectives for governance of cloud computing
Guo et al.(2010) Service and policy management through SOA-related tools
He (2011) Governing a cloud solution through distinct activities
Risk controls
Not explicitly mentioned.
No.
No.
Processes
Only the controls, not the processes.
Only processes needed for managing thousands of services through SOA tools.
Only SOA processes.
Governance activities
No
Yes, but they follow the implementation of SOA governance.
No
210
Use this model for development?
No, only process controls and not a scientific framework.
No, only applicable for managing thousands of services.
No, this model also applies SOA methods to cloud computing.
211
212