Transcript Cloud governance frameworks - Utrecht University Repository

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