Technical Report

Transcription

Technical Report

Arbeitsberichte der
Hochschule für Wirtschaft FHNW – Nr. 28
Enterprise Architectures for
Cloud Computing
Laura Aureli, Arianna Pierfranceschi, Holger Wache
ISSN
Nr. 1662-3266 (Print)
Nr. 1662-3274 (Online)
ISBN
Nr. 978-3-03724-143-1
Institut
Institut für Wirtschaftsinformatik IWI
Datum
Juni 2012
© Jahr Hochschule für Wirtschaft FHNW und der Autor bzw. die
Autorin. Jede Reproduktion, auch von Teilen und unabhängig vom
Medium, ist nur mit Genehmigung der Hochschule für Wirtschaft
FHNW und des Autors bzw. der Autorin gestattet.
„Enterprise Architectures for Cloud Computing“ von L. Aureli, A. Pierfranceschi, H. Wache
www.fhnw.ch/wirtschaft/iwi
„Enterprise Architectures for Cloud Computing“ von L. Aureli, A. Pierfranceschi, H. Wache
www.fhnw.ch/wirtschaft/iwi
Technical Report
Enterprise Architectures for Cloud
Computing
Laura Aureli, Arianna Pierfranceschi and Holger Wache
2012
University of Applied Sciences and Arts Northwestern
Switzerland
School of Business
2
Responsibility
Holger Wache
Institute for Information Systems
School of Business
University of Applied Sciences and Arts Northwestern Switzerland
E-Mail: [email protected]
Phone: +41 62 286 01 71
Laura Aureli
School of Business
Arianna Pierfranceschi
School of Business
c 2012 School of Business, FHNW, Institute for Information Systems, H. Wache
Contents
3
Contents
1. Introduction
1.1. Problem . . . . . . . . .
1.2. Goal . . . . . . . . . . .
1.3. Requirements . . . . . .
1.4. Enterprise Architectures
1.5. Proposed approach . .
1.6. Structure of the paper .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2. Background
2.1. Introduction . . . . . . . . . . . . . . . .
2.2. General Concepts of Cloud Computing .
2.2.1. Software as a Service . . . . . .
2.2.2. Platform as a Service . . . . . .
2.2.3. Infrastructure as a Service . . .
2.2.4. Public Cloud Computing . . . . .
2.2.5. Private Cloud Computing . . . .
2.2.6. Hybrid Cloud Computing . . . .
2.3. Enterprise Architectures . . . . . . . . .
2.4. Main problems in Cloud Computing . . .
2.4.1. Portability . . . . . . . . . . . . .
2.4.2. Privacy . . . . . . . . . . . . . .
2.5. Interrelation between Cloud Computing
and Enterprise Architectures . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
10
11
12
13
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
14
14
15
16
17
17
18
18
20
21
22
. . . . . . . . . . . . . . . . . .
23
3. State of the Art
25
4. Best Practices
4.1. Application security and encryption
4.2. Governance and risk management
4.3. Incident management . . . . . . .
4.4. Portability and interoperability . . .
4.5. Privacy . . . . . . . . . . . . . . .
4.6. Security and disaster recovery . .
4.7. Service availability . . . . . . . . .
.
.
.
.
.
.
.
27
27
29
30
31
33
35
36
5. Representations Extensions
5.1. Graphical representations . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1. Domains and generic framework . . . . . . . . . . . . . . . . . .
5.1.2. Graphical representations applied to a generic framework . . . .
38
38
40
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
4
5.2. Knowledge representations . . . . . . . .
5.2.1. Application security and encryption
5.2.2. Governance and risk management
5.2.3. Incident management . . . . . . .
5.2.4. Portability and interoperability . . .
5.2.5. Privacy . . . . . . . . . . . . . . .
5.2.6. Security and disaster recovery . .
5.2.7. Service availability . . . . . . . . .
5.3. SLA representation . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6. Conclusions
A. Business Rules
A.1. Application security and encryption
A.2. Governance and risk management
A.3. Incident management . . . . . . .
A.4. Portability and interoperability . . .
A.5. Privacy . . . . . . . . . . . . . . .
A.6. Service availability . . . . . . . . .
54
55
57
59
61
63
64
65
69
72
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
76
76
77
78
79
80
81
List of Figures
5
List of Figures
5.1. Pyramid representation of the Enterprise Architecture Framework Extended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Graphical representation for application security and encryption domain
5.3. Graphical representation for governance and risk management domain
5.4. Graphical representation for incident management domain . . . . . . . .
5.5. Graphical representation for portability and interoperability domain . . .
5.6. Graphical representation for privacy domain . . . . . . . . . . . . . . . .
5.7. Graphical representation for service availability domain . . . . . . . . .
5.8. Graphical representation of the complete framework . . . . . . . . . . .
5.9. Graphical representation of the technology level adapted from Hinkelmann (2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.10.Graphical representation of the technology level adapted from Hinkelmann (2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.11.Graphical representation of an internal behavior of an application adapted
from Hinkelmann (2011) . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.12.Graphical representation of a structure of one or more applications or
components adapted from Hinkelmann (2011) . . . . . . . . . . . . . .
5.13.UML graphical representation for the data level . . . . . . . . . . . . . .
5.14.BPMN graphical representation for the business level . . . . . . . . . .
5.15.Graphical representations of terms and fact types involved in the domain
application security and encryption . . . . . . . . . . . . . . . . . . . . .
governance and risk management . . . . . . . . . . . . . . . . . . . . .
incident management . . . . . . . . . . . . . . . . . . . . . . . . . . . .
portability and interoperability . . . . . . . . . . . . . . . . . . . . . . . .
privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
service availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.21.Terms and fact types involved in an SLA . . . . . . . . . . . . . . . . . .
39
41
42
43
43
44
46
47
50
51
52
53
54
55
56
59
60
62
64
67
71
List of Tables
6
List of Tables
5.1. Standards used in Cloud Computing . . . . . . . . . . . . . . . . . . . .
5.2. Service availability decision table . . . . . . . . . . . . . . . . . . . . . .
63
69
6.1. Mapping between knowledge representation, graphic representations
and best practices affected . . . . . . . . . . . . . . . . . . . . . . . . .
74
1. Introduction
7
1. Introduction
1.1. Problem
As stated in Velte et al. (2009), cloud computing allows to use applications that are
physically running in a different location than the computer on which the user is working. Cloud computing includes also the usage of platforms and infrastructures physically stored in places different than the company or user’s site. This can be considered
as a new way to make business, since it allows companies not to own their infrastructures. The same applies to platforms and applications. For these reasons, the usage
of cloud computing can give value to companies.
For this reason, many companies desire to move into the cloud. At the moment there
aren’t specific practices that describe how to do it, taking into account the main characteristics of the considered enterprise. These features can span across many levels,
starting form the organizational structure of the company, through the definition of its
processes and procedures, the organization of its information system as well as the
architecture of its infrastructure.
The main reasons to move into the cloud, as stated by European Network and Information Security Agency (2009), are to cut costs in hardware and software, to have more
flexibility and scalability of IT resources, to guarantee business continuity and disaster recovery, to increase computing capacity and business performance. Moreover,
Ebneter et al. (2010) state that cloud computing enables the sustainability and growth
of start up companies or companies shifting in new areas of activities. This means that
start up companies are facilitated, thanks to the benefits - listed above - that going into
the cloud delivers.
In a similar way, enterprise architecture frameworks can deliver value too. This is
done, since they allow to represent the company structure, its business processes and
information systems, as well as its infrastructure, as described by Architectures for Enterprise Integration (2003).
Thus, companies use enterprise architecture frameworks to describe their main features. What is not yet clear is if a company, to evaluate the possibility to go into the
cloud, can just consider its architectural description or if it’s necessary to add more
features.
1. Introduction
8
The possibility to extend a generic enterprise architecture representation should be
considered in order to be able to describe all the features that are important to decide
to go into the cloud. As an example, it will be shown that features of the enterprise
related to security and privacy of data, interoperability and portability, encryption of
data, governance and risk management must not be underestimated, but they must be
considered and represented in terms of knowledge, as well as graphically, to give a
more comprehensive view of the company.
Each company has a cloud potential. The cloud potential reflects the readiness of the
company to shift its business activities - part or all of them - into a cloud environment.
The readiness is related, as already said, to the security of data and processes, risk
management procedures, ability to change cloud provider or to interoperate with many
of them.
The lack of usage of enterprise architecture extensions can lead to a wrong evaluation
of the potential of the company to go into the cloud. The cloud potential can be either
under-evaluated or over-evaluated. In both cases, there will be serious consequences.
On the one hand, if the company’s potential is high but it’s not made visible, there could
be losses in terms of money, flexibility and scalability of resources, as already explained
at the beginning of the description of the problem. On the other hand, if the company’s
potential is effectively low but it’s over-evaluated, this could lead to problems related
with security of data, privacy, governance or with the unreadiness to interoperate with
other cloud providers.
Potentially, the second scenario can be considered more dangerous than the first one
either in terms of possible damages or in terms of the image of the company, possibly
leading to a reduction of the business and related revenues.
Moreover, the usage of extensions could help not only IT people, but also business
employees, to understand better company’s potential. This allow to have an overall understanding of company’s capabilities, clear to different departments of the company.
1.2. Goal
The goal of this work is related with one main question: can companies use the existing enterprise architecture frameworks to understand if they have potential to go into
the cloud? This means, understand if the architectural description given by one of
the available enterprise architecture frameworks, is enough to evaluate the company
cloud-readiness.
More precisely, the goal is to find out if the architectural description of the company
already includes specific features. These are important characteristics to consider before deciding to go into the cloud. As said in the problem description, the main ones
1. Introduction
9
are related to security and privacy of data, interoperability and portability, encryption
of data as well as governance and risk management. Moreover, these features should
also be understandable by business people. To satisfy this requirement, a graphical
representation of them is needed.
A graphical representation helps the company to quickly identify the main issues related to the shift to a cloud computing environment. In this way, the cloud-readiness
analysis that has been done can be understood by company’s employees with different
backgrounds.
If any of the existing frameworks don’t have the needed features for the evaluation,
then a way to add these characteristics has to be found. In this case, it’s likely that the
generic framework will need some extensions - graphical but also in terms of knowledge, that is what the extension means, refers to, as well as how it’s derived. In this
case, the goal is to give some proposals about the extensions to apply to the enterprise
architectural description of a company.
At this time, it’s already possible to understand that it’s important to extend the common
architectural representations of enterprises, especially to help managers or responsible people with a realistic evaluation of the possibility to go into the cloud.
Our goal is to give suggestions on how to extend these generic representations. Later
on in the paper, it will be shown that it’s possible to group these suggestions in main
areas. For each group of features considered, there will be given advices on how to
extend the knowledge (that is, the information needed and the related analysis of it)
and the graphic representations.
These suggestions, also called best practices, allow the company to describe its features related to the kind of data it uses, how sensitive they are, the issues related with
privacy and the need to encrypt them. They also span across the need to use standard
data formats and applications interfaces to guarantee portability, as well as interoperability.
Once provided these best practices, companies will be able to structure their features
related to those main areas and to understand what are the possible problems that
they can meet during the journey ”going into the cloud”. Since the recommendations
are expressed in natural language and there can be many of them, providing a graphical representation to be added to the architectural representation of the enterprise,
would be a solution. In this way, the evaluation of the company’s potential and the
awareness of possible problems will be easier, faster, understandable and clear also to
business people.
To relate the graphical representation with the best practices expressed in natural language, it’s necessary to express the knowledge behind them. The knowledge representation helps in expressing in a more formal way, what are the main issues, for each
1. Introduction
10
of the identified areas, that should be considered. As an example, formalisms that
can be used for the knowledge representation, can vary from business rules - to define what should be true and enforced, what is suggested and what should or must be
avoided - to UML representations to describe relations between different components,
ontologies to represent the semantics of the considered scenario or F-Logic.
A summary of the proposed approach can be found later on in the introduction. Details
about the representation extensions, will be shown in Chapter 5.
1.3. Requirements
Considering the goal described, there are many requirements that should be analyzed
and considered. First of all, the company should consider its guidelines and policies.
In this area, it’s important to analyze all the possible features and constraints that could
impact the possibility to go into the cloud. For instance, policies usually also talk about
security, from many points of view. The company should be able to understand what
are the requirements and constraints related to data security (in terms of privacy, if
they are sensitive, if they are considered as confidential or if a potential spread of them
could impact the business and company’s competitive advantage). Other important
requirements are related to application and hardware security, generic security related
with possible disasters, as well as the capabilities to prevent and manage them. If policies express the prohibition to shift some part of the business into a cloud environment,
of course they must be observed.
Moreover, the architectural description of the company should include all the basic
characteristics related to the technical, application, data and business levels. The company should have represented all the infrastructure used, the business processes, the
data and their features, the objectives of the enterprise, as well as the organizational
structure, and all the relations between these terms. In other words, an architectural
description of the company needs to be already defined. This description should include all the basic and important features related to the architecture of the company.
After having considered the policies and the architectural description, it’s important that
the company understands what are the main elements to be considered and evaluated
before going into the cloud. That is, the company should be able to identify what are
the real data that should be protected in the best way, what are the servers that need
a security audit, what are the business processes that use sensitive data and so on.
In short, there is the need to relate what the policies state with the real description of
the company. Moreover, it’s also necessary to consider all the laws and regulations
affecting the behavior of the company and to map them to the company’s description,
in the same way as with company’s policies.
1. Introduction
11
To summarize, one main requirement is given by the presence of laws, regulations and
company’s policies affecting the shift into a cloud scenario. After that, company’s architecture must be described in terms of organizational structure, business processes,
data used and infrastructure. The main point of the architectural description is the presence of necessary extensions showing company’s features that have to be evaluated
before going into the cloud. These features have already been described in the problem description section.
If the architectural description used doesn’t include these characteristics, the company
has, first of all, to identify them. That is, the company has to define what are the
guidelines that has to be followed in order to do a good evaluation of its cloud readiness. These guidelines have to include the description of the features and the way they
should be evaluated.
As defined by Tamm, Seddon, Shanks and Reynolds (2011), “Enterprise Architecture
is the definition and representation of a high-level view of an enterprise‘s business
processes and IT systems, their interrelationships, and the extent to which these processes and systems are shared by different parts of the enterprise.”
This definition perfectly highlights what is the aim to be achieved with an enterprise
architecture: to have an holistic view of the whole company. In this way, it’s possible
to define the desirable future for the company, and thus what are the enterprise‘s business processes and IT systems to improve, starting from the current state.
Enterprise architecture supports business and IT alignment guiding the change on several levels and helps to set up a roadmap for achieving the company goal.
Another interesting definition for enterprise architecture is given by Lankhorst (2009):
”Enterprise architecture captures the essentials of the business, IT and its evolution.”
This is a crucial point, indeed, is fundamental to understand what are the essentials of
a company to keep as references, in order to develop specific right solutions. Thus, an
enterprise architecture allows companies to have a vision always clear of the essentials of the business, allowing, at the same time, for maximal flexibility and adaptivity.
The decision to use an enterprise architecture approach is crucial, since as said by
Lankhorst (2009), ”without good architecture, it is difficult to achieve business success.
The most important characteristic of an enterprise architecture is that it provides a
holistic view of the enterprise.” Companies are usually described by using enterprise
architecture frameworks. These frameworks allow to represent the architecture of the
firm - in terms of different kind of view - and to describe the interrelations between
them.
1. Introduction
12
A good Enterprise Architecture definition is given by Architectures for Enterprise Integration (2003), in which it is described as ”a coherent whole of principles, methods and
models that are used in the design and realization of the enterprise’s organizational
structure, business processes, information systems, and infrastructure”.
Nowaday, there are a dozen reference framework to model an enterprise architecture
and the most important, and thus, the most known are the following: ”Zachman Enterprise Architecture Framework” (ZIFA), ”The Open Group Architecture Framework”
(TOGAF) and ”Department of Defense Technical Reference Model” (DoD TRM), which
cover about two-thirds of all firms.
Among all of them, the Zachman Framework has been the first one appeared in academic literature around the early 1990s and today it is considered one of the fundamental framework in the enterprise architecture history. Other frameworks such as DoDAF,
MoDAF, and TOGAF are considered framework but are classified as Implementation
Frameworks or to be more clear methodologies in combination with a framework. Companies can choose among one of these frameworks choosing the one through which
is possible create a synergy of the firm’s various capabilities.
As written by Tamm, Seddon, Shanks and Reynolds (2011), a recent survey by Infosys claims that around 90 percent of the respondent organisations have an enterprise architecture function and they chose among various professional organisations
as CAEAP, GEAO, IFEAD, TOGAF, ZIFA, etc. and government enterpriser architecture initiatives as FEAF, DoDAF, GEA, MoDAF, etc. In addiction, the most large global
management consulting firms offer enterprise architecture related services and this
suggests that all these organisations around the world spend a considerable amount
of time and efforts on enterprise architecture (Tamm, Seddon, Shanks and Reynolds
(2011)).
1.5. Proposed approach
The approach proposed in this paper can be divided in three main steps. The first
one aims to identify some suggestions, from now on called best practices. These are
guidelines that should be considered by each company which is evaluating the possibility to go into the cloud.
The goal of these best practices is to touch the most important and critical areas of
each company and analyze each of them, trying to highlight the main issues and problems that a company can meet during its ”cloud computing journey”. In this way, companies will be more conscious about the choice they will make.
The second step of the approach focuses on giving a knowledge representation for the
1. Introduction
13
best practices considered. This work allows to map the guidelines, expressed in natural language, with a more formal way to express these suggestions. The best practices
can also be seen as a kind of rule in which each condition correspond to an action.
This gives the possibility to express them in many ways, especially with rule-based approaches. To be able to do that, companies should be aware that there is the necessity
to define the domain of the rules, that is to model the scenario, the entities involved
and the relations between them.
The third and last step of the proposed approach provides some hints to extend the
knowledge representation, in order to model the best practices in a graphical way. The
goal of this step is to allow people to understand what are the important features of
the company that should be considered, without checking the best practices or analyzing the defined rules. There will be described how to graphically represent that, for
instance, a specific datum requires a high level of security due to privacy concerns, or
that specific servers need a security audit once a month, or that the format of specific
data is considered as a standard. These extensions are related to different level of
the architectural description of the company; this means that some extensions will be
added at the data representation level - and then related to the process which uses
those specific data - or at the application or technology level.
It’s important to notice that sometimes it’s not possible to be absolutely certain of some
company’s features. As will be explained later on, even if a company uses a specific
standard for virtual machines, there could be the possibility that it won’t be able to communicate with the chosen vendor. This could happen since standards can be adapted
to company’s’ needs. In this case the graphical description will show the presence of
a standard but in the reality it won’t be the certainty of the ability to communicate with
different vendors. This little explanation needs to show that, in the end, even if the company will extend its architectural description, it’s up to the firm to represent the feature
in the right way, after a careful and realistic analysis.
1.6. Structure of the paper
This paper is organized as follows: in Chapter 2 background concepts of cloud computing and related problems, enterprise architectures and their relation with cloud computing are described. In Chapter 3, the state of the art of the analyzed topic will be
presented. In Chapter 4, the main best practices that should be considered to evaluate
the possibility to go into the cloud are listed and analyzed. Chapter 5 shows possible
extensions of the representations - both in terms of knowledge and graphically - and
possible ways to represent Service Level Agreements.
2. Background
14
2. Background
2.1. Introduction
In this chapter the aim is to give a general overview about cloud computing, enterprise
architecture and the relation between them.
2.2. General Concepts of Cloud Computing
In Perez (2002)’s opinion, Cloud computing represents the new phase of network evolution as well as the future of the Internet.
Cloud computing is a general term within represents a set of hardware and software
technologies which allow customers to access, store and process data through resources over the Internet. As written in National Institute of Standards and Technology
(2011), “cloud computing technologies can be implemented in a wide variety of architectures, under different service and deployment models, and can coexist with other
technologies and software design approaches.” Gartner (2010), indeed, defines cloud
computing as a style of computing where massively scalable IT-related capabilities are
provided “as a service” using Internet technologies to multiple external customers. The
cloud computing concept is thus used to describe services provided by Cloud Services
Providers. The cloud services models are mainly three, each of which has distinctive
characteristics that differentiate them from the traditional IT hosting and thus from services managed in traditonal way.
A detailed description of cloud services models follows:
2.2.1. Software as a Service
Software as a Service, also known with the acronym ”SaaS”, is a software delivery
model where a software vendor develops, operates and manages web applications
and its associated data, and hosts them centrally in the cloud (OpenCrowd (2011)).
The vendors may make these services available, to customers, directly or making use
of third-party hosting but focusing only of the quality of their services; without thinking
about the infrastructure, capacity, safety or other issues related to where the service is
2. Background
15
delivered and what are the performance. This service is extremely easy to use, users
may access to web applications and data through a thin client, and to use them is only
requires an Internet browser, since they are predominantly solutions web-based.
Regarding the costs of this service, it is important to specify the payment methods. It’s
not necessary that customers buy software licenses to use them, they don’t have to
pay for the software possession but only to use it. There are different types of fees
ranging, from pay-per-use to the fee per person. They use the software through API
which are accessible via the web, often as Web Services or REST.
As written in OpenCrowd (2011) SaaS has become a common delivery model for
most business applications, including accounting, collaboration, Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), invoicing, Human Resource Management (HRM), Content Management (CM) and Service Desk Management (SDM).
The SaaS acronym agrees in part with the philosophy of the ’ASP’ (Application Service
Provider), now in disuse, and indeed, it is seen as an extension of the ASP model.
2.2.2. Platform as a Service
Platform as a Service, also knonw with the acronym ”PaaS”, is a cloud computing service that provide a computing platform and a solution stack as a service (OpenCrowd
(2011)). It is possible to locate this type of cloud computing service by idealizing the
cloud heirarchy, which is seen as a pyramid divided into three layers and where PaaS
is positioned in the middle. This representation makes clear the role of the Platform
as a Service that often consumes cloud infrastructure but is also necessary to sustain
cloud applications.
As written by OpenCrowd (2011) PaaS components allow to develop, test, implement
and manage business applications, without considering costs and complexity associated with purchasing, configuring, optimizing and managing of basic hardware and
software. These PaaS components can be used to design and develop applications
and application services such as team collaboration, web integration, database integration, security and state management. These services can be used as an integrated
solution in the web. It is possible to define some different typologies of Platform as a
Service:
• Add-on of development facilities, which allows to modify existing SaaS applications.
• Stand-alone development environments, which are intended to provide a generalized development environment.
2. Background
16
• Application delivery-only environments, which are aimed at the distribution that
provide services such as security and on-demand scalbility.
• Open Platform as a Service, which allows the developer to use any programming
language, any database, any operating systems, any servers, etc.
2.2.3. Infrastructure as a Service
Infrastructure as a Service, also known as ”IaaS”, is a delivery model where are distributed computing infrastructures as a service, that are typically platform virtualization
environments. The virtualisation enables IaaS providers to offer almost unlimited instances of servers to customers and make cost-effective use of the hosting hardware
(OpenCrowd (2011)).
Infrastructure vendors provide fully outsourced services to support several operations
which may be required by customers, allowing them not to purchase servers, software,
data storage or network equipment. Customers can select and choose basic software
servers for their part of the cloud and then load up their libraries, applications and data.
Usually companies configure them by themselves. For cusomers is likely to have considerable IT skills in-house because the infrastructure offered is quite plain. The service
provider owns the equipment and is responsible for housing, running and maintaining
it.
As written in OpenCrowd (2011), companies can use IaaS to quickly build new versions
of applications or environments. In this way they don’t have to order new hardware and
wait for it to arrive and being configured. Another popular use of IaaS is hosting the
websites of organisations. This keeps the website and its drain on IT resources away
from an internal infrastructure whose primary purpose is to run the business, not the
website. In these instances the IaaS provider takes on any worries about monitoring
traffic and keeping the website available. The cost of the service is usually based on
a per-use basis and on the amount of resources consumed, that generally reflects the
level of the activity use(OpenCrowd (2011)).
This cloud service is therefore seen as an evolution of web hosting and virtual private
server offerings.
After having given a general overview of distinctive characteristics that differentiate
the three mainly cloud services models, it is also important to show another classification of the cloud in terms of the location where the cloud is hosted. Cloud compunting,
indeed, is also classified in cloud deployment models which represent specific types of
cloud environment. The most known types of cloud deployment models, as stated in
OpenCrowd (2011), are main three. For clarity, it is fair also to mention a fourth type
2. Background
17
of model that is being used in several instances. This deployment model is known as
”community cloud” and it is similar to a ”public cloud” except for the fact that its access is limited to a specific community of cloud consumers. However, herein, will be
described the main models.
2.2.4. Public Cloud Computing
A public cloud computing is a cloud environment, also known as external cloud or multitenant cloud (OpenCrowd (2011)). This model essentially represents a cloud environment publically accessible that, generally, provides an IT infrastructure in a third-party
physical data center which is owned by a third-party cloud provider. That third-party
physical data center, that is hosted at the vendor’s premises, can be utilized to deliver
services without having to be concerned about the underlying technical complexities.
The customer has no visibility over the location of the cloud computing infrastructure.
As written in OpenCrowd (2011) essential characteristics of a public cloud typically
include homogeneous infrastructure, common policies, shared resources and multitenant, leased or rented infrastructure (operational expenditure cost model), economies
of scale.
Public clouds can host individual services or collections of services, allowing for the
deployment of service compositions and even entire service inventories.
2.2.5. Private Cloud Computing
A private cloud computing is a cloud environment, also known as internal cloud, corporate cloud or on-premise cloud. This cloud environment is a proprietary computing
architecture that provides hosted services to a limited number of people behind a firewall and is not shared with other organisations (OpenCrowd (2011)).
A private cloud intentionally limits the access to its resources to service consumers that
belong to the same organization that owns the cloud. In other words, the infrastructure that is managed and operated by one organization is primarily used to maintain
a consistent level of control over security, privacy, and governance. Advances in virtualization and distributed computing have allowed corporate network and datacenter
administrators to effectively become service providers that meet the needs of their
customers within the corporation. A private cloud is expensive but is considered more
secure than public clouds. It may be externally hosted ones as well as in premise
hosted clouds. Essential characteristics of a private cloud typically include heterogeneous infrastructure, customized and tailored policies, dedicated resources, in-house
infrastructure (capital expenditure cost model), end-to-end control.
2. Background
18
2.2.6. Hybrid Cloud Computing
A hybrid cloud is a cloud environment composed of at least one private cloud and at
least one public cloud. Typically this cloud environment can be offered in two different
ways:
• a vendor has a private cloud and forms a partnership with a public cloud provider,
• a public cloud provider forms a partnership with a vendor that provides private
cloud platforms.
However it is an environment in which an organization provides and manages some
resources in-house (e.g. some critical, secure applications) and has other resources
are provided externally (e.g. not-critical applications). For example, an organization
might use a public cloud service for archived data but continue to maintain in-house
storage for operational customer data. Ideally, the hybrid approach allows a business
to take advantage of the scalability and cost-effectiveness that a public cloud computing
environment offers without exposing mission-critical applications and data to third-party
vulnerabilities. This type of hybrid cloud is also referred to as hybrid IT (OpenCrowd
(2011)).
Enterprise architecture was born as an information technology discipline. As stated by
?, initially the purpose of enterprise architectures was to promote the strategic development of an organization’s IT systems through the modelling of the organization, as
well as the aligning of IT purchasing and development with business priorities.
In recent years, however, in the enterprise architecture field there have been some
changes easily identified in the definition of enterprise architecture given by Gartner:
“Enterprise architecture is the process of translating business vision and strategy into
effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its
evolution.”. As evidenced by Gartner’s definition, enterprise architecture has expanded
beyond the IT domain and enterprise architects are increasingly taking on broader
roles relating to organisational strategy and change management.
This view of enterprise architecture is a more holistic view and works across all levels
of the organisation, connecting business goals with the organisational data, applications and technology that facilitate them.
As stated by Marc Lankhorst (2007), this discipline is commonly considered to have its
2. Background
19
birth in an academic article by John Zachman, titled ”A Framework for Information Systems Architecture,”, published in 1987 by the research-oriented IBM Systems Journal.
The challenge of Zachman was to manage the complexity of increasingly distributed
system. Indeed, as Zachman explains in the article above mentioned, the cost involved
and the success of the business depending increasingly on its information systems, require a disciplined approach to the management of those systems. The growth of
the discipline, however, took place mainly in the practitioners’ cradle Marc Lankhorst
(2007).
Over the years, the interest in the discipline of enterprise architecture has grown more
and more and there has been steady academic work that interested this area. Anyway,
a research on enterprise architecture has been taking place in isolated communities by
different communities of researchers, each of which had different experiences, problems and ideas related to enterprise architecture and therefore are born several trends.
Practitioners of enterprise architecture are also called enterprise architects and their
goal is to deliver an architecture that supports the most efficient and secure IT environment and meets the business needs of a company.
In short, they deal to link the business mission, strategy, and processes of an organization to its IT strategy. They document all these, using multiple architectural models
or views that show how the current and future needs of an organization will be met in
an efficient, sustainable, agile, and adaptable way.
As already mentioned above, there were born several communities of researchers and
there were created various methods to describe the structure and dynamics of a company. These methods, or frameworks, also describe step by step procedures that can
be undertaken to construct both the architecture and the deliverables produced at each
stage. Most of these methods involve procedures that take account of the four common
architectural areas of domains: business, data, applications and technology. These architectural domains contain components within an organization, which are interrelated
in a certain way, in order to address all possible requirements of all system stakeholders, like people, departments and functions. Indeed, frameworks were created to be
used to organize enterprise architecture into different views, meaningful for the system
stakeholders. These enterprise architecture frameworks are often composed by different set of things, some of which are highly specialized. Others, instead, are often
standardized for defence and commercial systems.
Therefore, it is through all these methods that enterprise architects were able to produce taxonomies, diagrams, documents and models usable by all different stakeholders. Enterprise architects call a complete collection of taxonomies, diagrams, documents and models with the name artifacts, and they consider them the best way to
describe a company and to give to it a complete enterprise level architectural descrip-
2. Background
20
tion.
Artifacts can describe: the logical organization of business functions, business capabilities, business processes, people organization, information resources, business systems, software applications, computing capabilities, information exchange and communications infrastructure within the enterprise.
It is throught the correct use of a set of these artifacts, that an enterprise architecture
can have an optimal IT planning, architecting and an enhanced decision-making.
As stated by Jarvis (2003) ”each individual model in an enterprise architecture is arranged in a logical way and provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organization; its systems and data;
the technology used and any other relevant area of interest”.
An enterprise architecture is not so easy to build and apply on each different company,
but once in place it can have great power to resolve issues and provide insight into
complex, confusing situations Jarvis (2003).
Always according to Jarvis (2003), it is possible to list some points in order to have an
idea of what are the purposes which want to be achieved by choosing an enterprise
architecture framework to support the company:
• to provide a mechanism to evaluate business and technological change;
• to offer a vehicle for medium to long term business and technical planning;
• to link future aims with current achievements;
• to create a dynamic portfolio of projects i.e. scoped and bounded, sequenced,
ready for development, not just IT projects.
An enterprise architecture brings many considerable benefits and executives can have
a huge help from it, for proposing and testing strategies for the company development,
but also to plan and for reacting in an easy way to business changes.
2.4. Main problems in Cloud Computing
Even more companies, today, are embracing cloud computing as a way to lower investment costs, greater the Retrun On Investment and increased efficiency. But many
others companies fear the cloud because they don’t want to trust their data to a vendor
or simply they don’t want to put them in an external place they can not totally control.
Indeed, cloud computing is simply sharing or storage, by users, of data or applications
on servers owned or managed by third parties, which are accessed via the internet.
2. Background
21
But this could become a problem when information is scattered in centers with different
legal regimes, where often the laws are inadequate and inappropriate.
People still think in terms of physical servers well located but it is not trivial to manage
data privacy in a cloud environment. It is possible that the cloud infrastructure is used
in a malicious way to conduct an attack. The lack of physical control and the sharing of resources can lead to problems of industrial espionage, loss or manipulation of
data, as well as to the exposure of data to third parties. In addition, the security of
APIs exposed by cloud services is critical because the security model of them must
be properly designed to prevent them being exploited for attacks. It can be easily said
that the cloud computing includes all the traditional information security risks but also
some additional risks. The most relevant ones which should not be undervalued and
on which we want to focus herein are related to the portability and the privacy.
2.4.1. Portability
The term portability is used in cloud computing context most of the time in regard to
an application. It is also called cloud portability and technically, as explained by Continental Automated Buildings Association (2004), it is used to ensure that an application
has a common method of programmatic interaction to the underlying and services. In
other words, it is the capability to run applications and its associated data, between
one cloud provider and another with minimal disruption. But it is important to highlight
that is also the capability to run applications and data between different cloud environments: i.e. from public to private.
The problem is that cloud service providers are multiplying in numbers everyday and
most of them use its own proprietary API’s. This means that if a company, which initially has chosen a cloud provider, in the future would need to switch to another cloud
provider, probably it will have problems.
As stated in Cloud Security Alliance (2009) the necessity to move from one cloud service provider from another can born from different reasons which will be listed hereafter:
• high increase of costs;
• the provider will stop to operate at all;
• the provider will not provide some of the services being used, strong decrease of
service quality.
As discussed in Cloud Security Alliance (2009), it is possible to go in more detail,
describing possible problems for each kind of services. Regarding Software as a Service, a possible issue may occur when old software applications must be changed with
2. Background
22
a new one. In this case it is necessary to analyze the features of the new software
application because it may not have an adequate security level, which should at least
match the old one. Regarding Platform as a Service, instead, a possible problem may
occur when an application must necessarily be modified in order to allow the portability.
In this case, the problem could involve the number of necessary changes, and which
are not always possible. Finally, regarding Infrastructure as a Service some problems
could occur when applications and its associated data must migrate from a cloud environment to another. In this case the problem can regard conditions which affect the
new cloud environment and which may not be appropriate to run those applications
and data.
2.4.2. Privacy
Privacy is a critical risk factor that affects, practically, each kind of company. There
are, however, special cases in which companies operate in some critical areas and
data can not migrate outside the company sphere. They are, obviously, sensitive data,
particularly relevant for the company’s business, such as strategic data or industrial
secrets. But also other kind of data may also be considered sensitive data. Personal
customers information, for example, are extremely important for an individual practitioner, who may be very loath to deposit company’s data to an external service.
Choosing a cloud provider means to trust entirely to his ability. It must be, therefore, a
provider extremely professional in the care of the infrastructure and implementation of
all best practices in security.
Usually, a problem concerning privacy can occur because of data location. As stated by
Pearson (2009), indeed, private information of each company is stored in databases,
where it’s collected with private information of several other companies. Then, another
issue that should not be underestimated, as pointed out by Gartner: companies often do not known where their data are exactly. Sometimes it is neither clear in which
country they are stored, and thus, in what jurisdiction they are (Gartner). This can be
a problem whether databases and servers are located in countries with different privacy laws considered not safe enough and where data may not be safe from attacks.
Anyway, service provider must ensure by contract the policy used for privacy. They
are primarly responsable, and thus, must always be able to ensure the safety of the
service provided. Companies, in order to avoid privacy risks due to different privacy
laws, should consider carefully the terms and conditions of the service provider.
2. Background
23
2.5. Interrelation between Cloud Computing
and Enterprise Architectures
After having given the necessary knowledge in the preceding paragraphs, to understand what cloud computing and enterprise architecture are, in this section we want to
complete the general overview talking about the interrelation between them.
As discussed above and as stated also by Linthicum (2010), an enterprise architecture
is a strategic information asset base, which defines the mission, the information necessary to perform the mission, the technology necessary to perform the mission, and the
transitional processes for implementing new technologies, in response to the changing mission needs. An enterpise architecture characterizes and models the enterprise
throught a set of interrelated layers or views: strategy, business, data, applications, and
technology (or infrastructure).
A company which decides to move into the cloud must have a mature and well formed
understanding of the enterprise architecture on which is based and, thus, a clear view
of components which concern it (strategy, business, data, applications and technology). This understanding is absolutely necessary for the enterprise to make meaningful decisions related to cloud computing. As exemplified by Linthicum (2010), indeed, it
is through a good knowledge of the own company that is possible to assess whether a
move to the cloud is advantageous, what services most lend themselves to a cloud deployment, and what cloud deployment model (private or public) makes the most sense.
According to Linthicum (2010) it is possible to distinguish three key roles for enterprise
architecture in facilitating cloud computing strategy and planning: front-end decision
support, cloud implementation planning support and enterprise context.
• Front-end decision support.
An organization’s enterprise architecture should inform decisions about the desirability of a move to a cloud environment, what services should move to the cloud,
and the appropriate deployment models. Existing business processes, services
and resources should be analyzed through the lens of cloud characteristics and
quality dimensions, such as elasticity, reliability, and security.
• Cloud implementation planning support.
During the period of transition, an enterprise architecture provides the current
inventory of services and the roadmap to which services are being deployed into
what clouds. As new business needs emerge, the EA provides solution architects
with a view of what has been deployed in the cloud already and what is planned
for future deployment.
• Enterprise context.
2. Background
24
Sharing and reuse of services and resources, have been primary objectives of
enterprise architecture. In the context of a cloud strategy, enterprise architecture
provides a critical enterprise view to ensure cloud decisions are optimized at the
enterprise level and independent decisions on cloud-based point solutions are
viewed in a broader context.
3. State of the Art
25
3. State of the Art
A literature review has been done in order to find out the main issues of this topic and
already proposed approaches. Unfortunately, there are not yet so many papers and
articles about it. According to Ebneter et al. (2010), first of all it’s necessary to define
a set of best practices which capture all the knowledge. These best practices can be
then used to compare the configuration and the description of the enterprise. Ebneter
et al. (2010) propose to use a graphical model to show the main features of the enterprise in a way that they can be understood also by business people. In particular,
these graphical models can be used to extend the description of business processes
but also the IT infrastructure and the organizational structure. Unfortunately, this work
is not yet completed. It just gives some general hints on how to proceed but nothing
more. There are no specific information about what best practices should be considered, neither about the knowledge or graphical representations.
Thorn (2011) stated that the enterprise architecture description should be well defined
in order to be able to move into the cloud. Again, the main aspects that should be
considered for the evaluation are related to the level of interoperability requested and
defined, the needed level of security, the presence of applications proprietary interfaces, problems related to new products and services (e.g. secrecy of the not yet
patented process). Thorn (2011) focuses especially on the usage of TOGAF9 in order
to guarantee the fit between the enterprise architecture description and cloud computing. This approach could be a little binding since it’s specifically oriented to the use
of a particular enterprise architecture framework. This means that not all the companies can be able to use it, since they could need some modification of the enterprise
architecture description in order to use TOGAF9 and the approach proposed in Thorn
(2011). Moreover, Thorn (2011) doesn’t show a set of best practices important to be
considered, that is a fundamental part of the enterprise architecture description optimization. Therefore, also this paper doesn’t give many clues on how to proceed. Best
practices are not considered at all and the approach used is for a specific enterprise
architecture framework. Possible ways to extend the knowledge or the graphics are not
included in the work.
Delaquis & Philbin (2011) also agree that a good enterprise architecture description is
critical for the evaluation of the readiness to go into the cloud. In their opinion, the main
3. State of the Art
26
questions that a company should ask itself concern the ability to emulate its processes
in a cloud scenario, the level of security the cloud provider is able to offer and if the
security mechanisms are compatible with the ones of other cloud computing vendors.
This work gives generic hints on the most important issues of cloud computing and
the most important areas of the best practices that should be considered. Except that,
there is no linkage between cloud computing and enterprise architectures and no suggestions on how to extend the architectural description of the companies.
Many best practices can be found in Velte et al. (2009), Cloud Security Alliance (2009),
Federal Office for Information Security (2011) and National Institute of Standards and
Technology (2011). After having analyzed these publications, it’s possible to understand that the main areas of interest are application security and encryption, governance and risk management, incident management, portability and interoperability,
privacy, security, as well as disaster recovery. Anyway, these papers are useful only
for the identification of the main areas of focus and the main issues that should be
considered in each area.
The current state of the art doesn’t satisfy our requirements: it was not possible to
find out already existing approaches that allow to extend the enterprise architecture
description in order to evaluate companies’ readiness to go into the cloud. Some best
practices have been found out. They will be considered and analyzed in this work, in
order to describe the fundamental cloud computing related issues to consider, when
describing an enterprise architecture. There was not possible to find how to relate
these recommendations with the concrete architectural description, neither in terms
of knowledge nor in a graphical way. Nevertheless, possible solutions to extend the
graphic representation is by using stereotypes, as proposed in Open Group (20082009), or by using enterprise architecture modeling languages, as can be deducted in
Ebneter et al. (2010). For these reasons, how to extend the architectural description of
a company, in order to evaluate its readiness to go into the cloud, still remains an open
question.
4. Best Practices
27
4. Best Practices
In this chapter there will be described some guidelines and recommendations that
should be followed, in order to evaluate if the architectural representation of the company that desires to go into the cloud is good enough or if it needs some extensions.
These recommendations are organized in different groups: application security and
encryption, governance and risk management, incident management, portability and
virtualization, privacy, security and disaster recovery, as well as service availability.
4.1. Application security and encryption
Applications running in cloud systems are affected by and can affect many features.
As written in Cloud Security Alliance (2009), the main factors are related with:
• Dependencies with other systems: sometimes the dependencies with other
systems can be really strong and can also involve external service providers.
This scenario leads to the need to change the architecture of the application in
order to guarantee application security.
• Software development process: if the application will run in a cloud environment, then all the phases of the software development life cycle are affected.
This implies that the identification of the requirements, design, implementation,
verification and maintenance should be done considering the main problems that
can occur in a cloud environment.
• Vulnerabilities: this factor includes not just the vulnerabilities related with the
applications but also possible vulnerabilities deriving from the dependencies and
relations with other machines operating in the cloud environment.
The other aspect of security is related with the data used and stored inside the cloud
environment. As written in Velte, Velte & Elsenpeter (2009), if you have to work with
sensitive data, a cloud environment could not be the safest place to store them. Anyway, one possible way to protect them is using encryption.
According to Velte, Velte & Elsenpeter (2009), usually it’s better to choose a paid encryption service in opposition to one based on advertising. The main reason is that is
4. Best Practices
28
more likely that in the last type of service, data are analyzed and assembled through
users profiles and then used for marketing purposes. In general, it’s better to store
data in the most secure place, even if it means to store them in house and waiting for
a better external service.
As stated by Cloud Security Alliance (2009), cloud customers want that their cloud
providers encrypt their data (sensitive and normal ones) in order to be, more or less
guarded, if data are stolen or lost. Moreover, in some cases, there are also laws and
regulations that oblige cloud providers to use a strong data encryption system. It’s important to notice that sometimes, laws treat lost encrypted data as if they are not lost
at all, Cloud Security Alliance (2009).
For these reasons, the choice of the provider will be done considering, among other
criteria, the kind of encryption offered and how much strong it is.
Recommendations
Some recommendations concerning application security and encryption can be listed,
considering what it’s written in Cloud Security Alliance (2009):
1. Communications inter-host should be secure.
2. The management of application credentials is critic: they should be protected and
secured.
3. It should be paid attention on the management of application files, and related
locations, used for logging and debugging.
4. Cloud providers should give the possibility to the customers to check the security of application by performing remote vulnerability assessment and application
vulnerability assessment.
5. It’s important to use encryption to separate the storage and the usage of data.
6. The chosen encryption system should conform to the existing industry and government standards.
7. Understand how the cloud provider manages encryption keys and if it uses the
same key for all its customers. Particular attention should be paid on how the key
life cycle is conducted, that is how the key is created, stored, used, recovered and
deleted.
8. Separating the key management from the hosting of data, by using different cloud
providers, protects the customer and the cloud provider.
4. Best Practices
29
9. Keys used to encrypt data must themselves be protected when they are stored,
in transit or backed-up.
10. Cloud provider should give the possibility to limit the access of stored keys to the
entities that need them.
11. Cloud provider should offer a recovery system in the case that encryption keys
are lost.
12. Check if the data are encrypted also during the transit inside the cloud provider’s
network. Cloud provider’s network is more secure than the Internet but, anyway,
it’s shared between different customers.
13. It’s possible that in IaaS scenario, also virtual machines files and temporary data
need to be encrypted.
4.2. Governance and risk management
According to National Institute of Standards and Technology (2011), governance is related to the control of policies, procedures and standards of application development.
Moreover, it deals with activities related to deployed services like the design, implementation, testing and monitoring.
The identification of the suitable organizational structure, but also of processes and
controls, are the main issues in order to have an effective risk management and information security governance, as stated in Cloud Security Alliance (2009).
Recommendations
Some recommendations concerning governance and risk management can be listed,
considering what it’s written by Cloud Security Alliance (2009) and National Institute of
Standards and Technology (2011):
1. To guarantee that fixed requirements are met, it’s necessary to perform security
controls, assessment and audits. Audits are important to determine how data are
stored and used, as well as how they are secured.
2. The cloud computing provider and the customer should collaborate and develop
a good information security governance, in order to achieve selected goals and
requirements that support the mission of the company and its information security
plan.
4. Best Practices
30
3. Assessments of information security governance structure and processes and
security controls should be planned and executed. The main criteria of the assessment could be the maturity and consistency of the information security management processes.
4. Security managers and responsible people should be involved during the settlement of Service Level Agreements in order to ensure that security requirements
are enforceable.
5. In general, Service Level Agreements should include documented and demonstrable security metrics and standards.
6. The risk management procedure should consider the identification and evaluations of assets, the identification and, consequently, the analysis of possible
threats and vulnerabilities and the strength of the impact on the assets. Possible scenarios should be evaluated and different risk treatment plans should be
analyzed and developed.
7. If the cloud computing service provider doesn’t offer effective risk management
processes and practices, the customer should consider the possibility to use his
own abilities in order to close the risk management gap.
8. In order to manage risks, it’s important to pay attention to the roles and the related
responsibilities within the risk department.
4.3. Incident management
”Incident response involves an organized method for dealing with the consequences
of an attack against the security of a computer system” National Institute of Standards
and Technology (2011).
To guarantee a certain level of security and privacy and to react to an incident, the collaboration between cloud provider and customer is critical. According to Cloud Security
Alliance (2009), one of the main problems for cloud customers is that, sometimes, applications running in the cloud environment are not really good in terms of data integrity
and security. Consequently, these applications have a certain degree of vulnerability
which can trigger security incidents.
It’s important to notice that the incident response strategy is different between cloud
providers. Moreover, the management of application data and access, as well as the
related regulatory requirements, depend on the data geographic location (different regulations among different countries) Cloud Security Alliance (2009). According to Na-
4. Best Practices
31
tional Institute of Standards and Technology (2011), depending on where the data are
located, there is the possibility that an investigation could be banned.
Recommendations
Some recommendations concerning incident management can be listed, considering
what it’s written by Cloud Security Alliance (2009) and National Institute of Standards
and Technology (2011):
1. One of the first things that a cloud customer should do before the service is deployed, is to explicitly define what is considered an incident and what a mere
event.
2. Before signing a contract, the available and used procedures for incident response
should be understood and, if possible, negotiated.
3. It’s important for the cloud customer to understand and find out what are the tools
used to detect incidents, to ensure the compatibility with the existing systems.
4. As a general rule, applications and systems design and security should be good.
If they lack in these features, even if the incident response capabilities are really
good, there could be problems to face the incident.
5. It’s important to consider the ability of the cloud provider to restore a previous
state of the system. Sometimes, the remediation process need to go back to
twelve months in order to restore a good configuration of the system.
6. If there are data labeled as private, then they have to be encrypted in order to
reduce the consequences of a possible incident.
7. A cloud provider should offer, at least, systems and tools, for responding to incidents, reflecting the state of the art (e.g. firewalls, proxies, application logging
tools).
8. The future geographical location of the data should be considered in order to
understand possible problems related to the impossibility to conduct incident investigations and different ways to manage application data and access due to
existing regulations.
4.4. Portability and interoperability
According to Federal Office for Information Security (2011), cloud computing portability
can be considered as the independence of platforms, that is the capability of running in
4. Best Practices
32
different cloud computing environments. Cloud customers should have clearly in mind
that, in the future, there could be the necessity to switch cloud provider. Some of the
reasons, according to Cloud Security Alliance (2009), are: a high increase in costs,
the provider won’t operate anymore at all or won’t provide some of the services being
used, as well as a strong decrease of service quality.
It’s important to keep in mind that if there is a lack in the usage of standards, then the
portability operations could be difficult.
It’s possible to describe in short the main issues of cloud portability, considering the
different types of services, as written by Cloud Security Alliance (2009):
• Software as a Service: old software applications will be changed with new ones.
In this case it’s important to ensure that the new application security level is at
least as the level provided by the previous service provider. Moreover, attention
should be paid to ensure the success of data migration from one provider to the
other.
• Platform as a Service: it’s likely that some application modifications will be necessary in order to allow portability. The main goal is to reduce the number of
modifications needed and, at the same time, to ensure a certain level of security.
• Infrastructure as a Service: application and data will be migrated in the new
cloud environment and they should be able to run in the new scenario.
According to Federal Office for Information Security (2011), cloud interoperability is
related to the situation in which two or more cloud environment are working together.
There is no need to make any kind of agreements between the different platforms but,
it’s important that the interoperability scenario should be based on the usage of standard formats.
At the current time, there are many standards that allow to reduce portability and interoperability problems. As identified by Federal Office for Information Security (2011),
some of them are: the Open Cloud Computing Interface created by the Open Grid
Forum, the vCloud API by VMware and the Open Virtualization Format.
Recommendations
Some recommendations concerning cloud portability and interoperability can be listed,
considering what it’s written by Cloud Security Alliance (2009) and Federal Office for
Information Security (2011):
1. Before starting the portability operations, it’s important to understand the amount
of data that should be transferred in order to shorten the transition period. Some-
4. Best Practices
33
times, it’s faster to send physically hard drives instead of electronically transferring
data.
2. The security architecture of the system and components should be documented
in order to simplify the portability process.
3. It’s important to know and understand how virtual machines configurations can
be captured and transferred to the new cloud environment, especially if it uses
different technologies. Moreover, virtual machines extensions specific for a certain environment should be eliminated. Portability should be enabled by using, for
instance, the Open Virtualization Format.
4. Identify and understand any kind of dependencies related to applications and
data. Moreover, the presence of interfaces, APIs or functions that are not compatible with the new cloud provider should be determined.
5. If possible, standards applicable to virtual machines, applications and data should
be used in order to simplify the portability process and to avoid vendor lock-in
scenarios.
6. Identify the best tool to guarantee security of data when they are transferred and
backed up.
7. Identify and document, if present, the application components and features that
are specifically related to the current cloud provider. Then, try to develop some
interfaces or abstraction mechanisms, in order to limit the access to the specific
modules and components.
8. It’s important to know how the verification of the correct execution of applications
transfer is executed. Moreover, the responsibilities about testing for the cloud
providers should be documented and well explained and delimited.
9. Periodically data should be backed up by using a standard format.
10. If there are customized tools, it’s important to understand that, to allow portability,
they have to be redesigned and implemented again. A possible alternative is that
the new cloud provider provides these tools.
4.5. Privacy
According to Pearson (2009), privacy is one of the main concerns of companies when
considering the possibility to go into the cloud. Customers’ data, which are often sensitive or related to company’s private information, are usually stored into databases
4. Best Practices
34
containing also data of other customers. For this reason, as stated by Pearson (2009),
the focus in cloud computing is designing cloud services in a way to decrease the risk
related to privacy and to guarantee compliance with law.
Pearson (2009) has grouped this ”personal information” in different categories:
1. Personally identifiable information: which includes all the information that can
directly identify a person or that can be used, in addition to other information, for
the same purpose.
2. Sensitive information: which includes all the information related to job performance, religion, health status, relationship status, sexual orientation.
3. Information categorized as sensitive: which includes video of cameras in open
places.
4. Usage data: which includes all the information gathered by the usage of computer devices and information related to habits for digital materials.
5. Unique device identities: which includes other information like IP addresses,
hardware identifiers or RFID tags identifiers.
Recommendations:
Some recommendations concerning cloud privacy can be listed, considering what it’s
written by Centers for Medicare and Medicaid Services (2011) and Gellman & Dixon
(2009):
1. If the cloud service provider can change the terms of service unilaterally, that is
without an expressing agreement with the customer, the company should think
carefully about choosing it.
2. If possible, choose a cloud service provider which offers standards for confidentiality and integrity of data.
3. If the cloud service provider will own the data even after the deletion or transfer to
another provider, think carefully about choosing it.
4. It’s important to understand and to consider if the backup copies of data will
be sent to the customer, once the contract ends or if the provider goes into
bankruptcy.
5. It’s important that a procedure to handle breaches is carefully defined.
4. Best Practices
35
6. Attention should be paid in order to understand if the cloud provider has some
rights to use or make public the data stored in the cloud.
7. If there are some data that should not be seen by competitors, think twice about
storing them into the cloud.
8. Companies should check if they can store specific data into the cloud, that is if it’s
permitted by the law and regulations.
4.6. Security and disaster recovery
According to Cloud Security Alliance (2009), another challenge in cloud computing is
to identify possible risks and put in practice all the actions to prevent them like physical
security, business continuity planning and disaster recovery.
To guarantee a certain level of security, it’s necessary to plan security incidents and the
handling of them in advance, as described by Federal Office for Information Security
(2011). Moreover, cloud services should be monitored everytime, 24/7.
As stated by Somashekar (2010), disaster recovery plans can ensure that the data are
backed up but also virtual machines configurations can be included. It’s also important
to notice that collaborations between cloud service providers, allow data replication
between them.
Recommendations
Some recommendations concerning security and disaster recovery can be listed, considering what it’s written by Cloud Security Alliance (2009) and Federal Office for Information Security (2011):
1. Cloud customers should consider that the centralization of data could lead to the
risk of an insider abuse, from the service provider perspective.
2. Cloud customers should analyze periodically the disaster recovery plans and
business continuity plans of the service provider.
3. It’s important to identify the interdependencies in the cloud provider physical infrastructure.
4. Cloud customers should understand if the service providers adheres to any security industry standards.
4. Best Practices
36
5. Cloud providers should have a business continuity management system based
on existing standards, in order to react rapidly when emergencies occur and to
restore critical business processes.
6. Cloud providers should be able to give evidence regarding the changes made to
the service, the time when they have been made and by whom by logging all the
activities.
7. Cloud providers should make regular business continuity management exercises
in order to find out possible inconsistencies in the crisis plan and to train effectively
in case of emergency.
4.7. Service availability
National Institute of Standards and Technology (2011) defines the availability as the
degree to which applications and resources are accessible or usable. There are many
threats that can influence the availability, temporarily or permanently. Anyway, the outcome of these threats is common, since they can have effect on the mission of the
company and its business. In some cases, especially in the presence of prolonged or
permanent outages, the company could have serious problems related with losses or
even bankruptcy.
As described by National Institute of Standards and Technology (2011), service availability is related to its degree of reliability. The reliability is usually expressed in percentage and the hours of downtime can be easily determined. All this information should
be included in the Service Level Agreement.
Nevertheless, there are some cases in which service availability is threatened by intentional attacks, like Denial of Service, or by the lack of the needed resources. As an
example, consider the scenario in which a company has been outsourced a web service and the resources needed to run it. Considering a scenario in which the company
is a university, the purpose of the web service is to gather information - by using an
application form - about students and their preferences for the courses they would like
to attend during the next semester. The data of the students should be available in a
specific date, leading to the necessity to set a deadline to fill in the form. It’s possible to
hypothesize that there will be a heavy workload during the days immediately before the
deadline. This situation could threaten the availability of the service (in this case the
availability of the web service and related resources to gather information) if the cloud
vendor is not able to provide the amount of resources needed.
4. Best Practices
37
Recommendations
Some recommendations concerning service availability can be listed, considering what
it’s written by National Institute of Standards and Technology (2011) and Buck & Hanf
(2010). Moreover, some hypothesis are included.
1. The contingency planning of the company should include the degree of reliability
of the system and services and the capabilities for backup and recovery.
2. The SLA should include the provider of the service, the customer and all the
related information.
3. The SLA should define the time period of validity of the service.
4. The SLA should describe the services and capabilities offered and the metrics
used to evaluate their performance.
5. The SLA should describe the degree of reliability of the system, the time during
which the services are guaranteed and the accepted downtime due, for instance,
to maintenance.
6. The SLA should describe how the vendor will manage possible outages and the
related response time.
7. The SLA should define the penalties for the vendor when the service is not provided.
8. The SLA should define customer and vendor responsibilities.
9. The SLA should define the costs of the service
10. Companies dealing with real-time processes should analyze how risky is to go
into the cloud. This could be made considering the impact on profit if the system
or service is unavailable. Other alternatives could be the presence of a deadline
and if many people have to access a specific service.
11. Companies dealing with real-time processes should define a strong SLA in order
to have a security in the case of service unavailability.
38
As already explained in the previous chapters, to be able to evaluate if a company
is ready to go into the cloud, enterprise architecture frameworks need to be extended.
They need extensions in order to fully describe all the best practices described in Chapter 4 and to analyze all the relevant concepts related to the shift of the activities and
infrastructure in a cloud environment.
The extensions needed can be grouped in two main categories: graphical extensions
to allow to understand the requirements in an easy way - just looking at the architectural
description - and knowledge extensions to represent the semantic of the extension and
to relate the best practices to the graphical part. It’s also important to consider how
to represent Service Level Agreements in order to include them in the architectural
description of the company.
5.1. Graphical representations
Graphical representations are used to highlight particular features of the architectural
description of the company. Some matrices will be proposed and their meaning explained, in order to facilitate the understanding of the cloud potential of a company.
As already stated in Chapter 2, enterprise architecture is a holistic view of the enterprise which makes easier to understand the architecture of an enterprise. To help
companies to know what is needed to define the holistic view of the company, enterprise architects have created in the last 25 years several enterprise architecture
framework. The most important approaches are mainly four: the Zachman Framework
for Enterprise Architectures, The Open Group Architecture Framework (TOGAF), the
Federal Enterprise Architecture Framework (FEAF), and Gartner (formerly, the Meta
Framework).
As already mentioned, the goal is to build an extension from a generic framework, to
allow companies to understand what are the critical points to consider whether they
want to go into the cloud.
The enterprise architecture framework that has been taken into account for the extension is a generic enterprise architecture framework.
A first representation of the extension is proposed in Figure 5.1 through a three-dimensional
39
pyramid and it shows two facades. The first facade is composed by five elements that
usually characterize the structure of a generic enterprise architecture. In this side the
five elements are represented as building blocks that describe the whole enterprise and
they allow an high-level view of the system they describe. From the top it is possible to
distinguish the following layers: Strategy, Business, Data, Application and Technology
of the enterprise.
In the second facade, are respresented the seven areas of interest defined in Chapter 4, which are of fundamental importance for companies that want to move into the
cloud. On this side, the blocks are organized vertically, because each area of interest
can affect each one of the five elements that characterize the structure of the enterprise. Therefore, it is possible to distinguish the following layers: Application Security
and Encryption, Governance and Risk Management, Incident Management, Portability
and Interoperability, Security and Disaster Recovery, Privacy and Service Availability.
Figure 5.1.: Pyramid representation of the Enterprise Architecture Framework
Extended
The following step will help the understanding of the extension of the enterprise architecture framework. In the following sections, indeed, each area identified in Chapter 4
will be analyzed individually.
Some matrices will be proposed for each area of interest hereafter and their meaning
will be explained, in order to facilitate the understanding of the cloud potential of a com-
40
pany. For each area, the recommendations defined in the Chapter 4 are considered.
The best practices and the layers of the enterprise architecture are used in order to
produce a matrix.
The aim of the martrix is to express, for each recommendation considered, what are
the layers affected. The presence of a possible danger is shown by using a yellow
warning symbol.
5.1.1. Domains and generic framework
The graphical representations shown in the following sub-sections, aim to highlight
what are the levels of the enterprise architecture framework of a company that want to
go into the cloud, that must be carefully evaluated considering one by one all the areas
of interest.
In Chapter 4 some best practices and respective recommendations have been described for each domain. These recommendations have been, then, taken in account
to extend the architectural representation. The matrices proposed are composed on
the ordinate axis by the five layers that characterize the structure of a generic enterprise
architecture framework and on the abscissa axis by the most significant recommendations.
Each recommendation can involve one or more layers. In order to highlight the importance of the recommendations and, thus, the possibility that a danger might occur at
that level, the intersection of the two layers is emphasized by a particular yellow symbol
of warning.
Application security and encryption
After a careful analysis, we selected the most significant recommendations for the
application security and encryption area which are related to possible issues against
which a company may incur. These are the number 2, 5, 6, 9, 12 and 13. They deal
in particular with the management of credential and encryption keys, the need of encryption for particular data and files, as well as the compliance to existing encryption
standards.
As can be seen in the matrix in Figure 5.2, the first recommendation useful is the number 2: ”The management of application credentials is critic: they should be protected
and secured” and involves the ”Application” layer.
The recommendations number 5 ”It is important to use encryption to separate the storage and the usage of data”, number 12 ”Check if the data are encrypted also during
41
Figure 5.2.: Graphical representation for application security and encryption domain
the transit inside the cloud provider’s network. Cloud provider’s network is more secure
than the Internet but, anyway, it’s shared between different customers” and number 13
”It’s possible that in IaaS scenario, also virtual machines files and temporary data need
to be encrypted” involve, instead, the ”Data” layer.
The recommentations number 6 ”The chosen encryption system should conform to the
existing industry and government standards” and number 9 ”Keys used to encrypt data
must themselves be protected when they are stored, in transit or backed-up” in the end,
involve the ”Strategy” Layer.
Governance and risk management
After a careful analysis, the most significant recommendations for the governance and
risk management area, related to possible issues against which a company may incur
are the number 1 and 6. They deal in particular with activities that should be executed
no matter what is the cloud provider.
As is possible to see in the matrix in Figure 5.3, the first recommendation useful is the
number 1 ”To guarantee that fixed requirements are met, it’s necessary to perform security controls, assessment and audits. Audits are important to determine how data are
stored and used and, most important, how they are secured” and involves the ”Data”
layer.
The second recommendation useful is the number 6 ”The risk management procedure
should consider the identification and evaluations of assets, the identification and, consequently, the analysis of possible threats and vulnerabilities and the strength of the
42
Figure 5.3.: Graphical representation for governance and risk management domain
impact on the assets. Possible scenarios should be evaluated and different risk treatment plans should be analyzed and developed” and it involves, instead, the ”Strategy”
and the ”Technology” layers.
Incident management
A careful analysis, led to the choice of determined recommendations deemed the most
significants in order to understand possible issues against which a company may incur.
In this area the most significant recommendations are the number 1 and 6. Both of
them deal of the description of the enterprise architecture and of the important features
related to incidents and ways to minimize incidents consequences. As is possible to
see in the matrix in Figure 5.4, the first recommendation useful is the number 1 ”One
of the first things that a cloud customer should do before the service is deployed, is to
explicitly define what is considered an incident and what a mere event” and involves the
”Strategy” layer. The second recommendation useful is the number 6 ”If there are data
labeled as private, then they have to be encrypted in order to reduce the consequences
of a possible incident” and it involves, instead, the ”Data” layer.
Portability and interoperability
A careful analysis, led to the choice of determined recommendations deemed the most
significants in order to understand possible issues against which a company may incur.
43
Figure 5.4.: Graphical representation for incident management domain
This time, the most significant recommendations have been considered are the number 4, 6 and 10. They mainly deal with the applications interfaces and data formats
used, as well as security measures for transferring data and for storing them.
As is possible to see in the matrix in Figure 5.5, the first recommendation useful is the
Figure 5.5.: Graphical representation for portability and interoperability domain
number 4 ”Identify and understand any kind of dependencies related to applications
and data. Moreover, the presence of interfaces, APIs or functions that are not compatible with the new cloud provider should be determined” and this time, involves two
levels: both ”Data” and ”Application” layer.
44
The second recommendation useful is the number 6 ”Identify the best tool to guarantee
security of data when they are transferred and backed up” and it involves the ”Data”
layer.
In the end also another recommendation is useful: the number 10 ”If there are customized tools, it is important to understand that, to allow portability, they have to be redesigned and implemented again. A possible alternative is that the new cloud provider
provides these tools” and it involves the ”Data” layer as the previous recommendation.
Privacy
The most significant recommendations for the provacy area, related to possible issues
against which a company may incur are the number 5, 7 and 8. These recommendations deal in particular to the categorization of the data used by the company, security
procedures adopted by the company to handle data breaches and data requirements
defined by laws and regulations.
Figure 5.6.: Graphical representation for privacy domain
As is possible to see in the matrix in Figure 5.6, the first recommendation useful is
the number 5 ”It is important that a procedure to handle breaches is carefully defined.”
and involves the ”Business” layer. The second recommendation useful is the number
7 ”If there are some data that should not be seen by competitors, think twice about
storing them into the cloud” and it involves, instead, the ”Strategy” layer. As the recommendation already mentioned, also the recommendation number 8 ”Companies should
45
check if they can store specific data into the cloud, that is if it is permitted by the law
and regulations” is useful and involves the ”Strategy” layer.
Security and disaster recovery
Concerning the security and disaster recovery area is not shown any matrix. This because all the best practices described in Chapter 4, are related to the relation between
company and cloud provider. Since the choice of the cloud vendor is made a priori,
the extension, does not relate with the architectural description of the company made
a priori, does not affect this area.
Service availability
Regarding the service availability area, all the best practices described in Chapter 4,
are related to the SLA and the availability of web services and of resources by the clud
vendor. This means that the choice has depended on the cloud vendors. Also this
time it has already done a priori. However, it is still possible to make some important
considerations. Indeed, the exemplification of a possible scenario described in Chapter
4, made us understand that service availability is really important to do not impact the
mission of the company. As already stated there are threats that can influence the
availability, temporarily or permanently and thus they can have negative effects on the
mission of the company and its business.
All these considerations lead us to the inference that the level involved is the ”Business”
layer. Thus, how is possible to see in the matrix in Figure 5.7, it is marked with the
symbol of warning of yellow colour.
Final Framework Extended
Figure 5.8 shows a global vision of the framework. As is possible to see in that matrix,
this time we can find on the abscissa axis all domains of a company that must be taken
into account to understand if move into the cloud is or is not the right choise. On the
ordinate axis, instead, the matrix is composed by the five layers that characterize the
structure of a generic enterprise architecture framework. In this representation each
matches between the elements of the ordinate axis with the elements of the abscissa
axis produces different types of warning. The types of warning depend on how many
recommendations or factors (in the case of the service availability) of the differents domains, involve the architectural elements that represents a company.
If the recommendation to evaluate is only one the symbol of warning is yellow. If the
46
Figure 5.7.: Graphical representation for service availability domain
recommendations to evaluate are two the symbol of warning is orange and if the recommendations to evaluate are three or more the symbol of warning is red. As already
explaned in the paragraph above, concerning the security and disaster recovery, there
are no symbols of warning that involve the that domain.
Figure 5.8.: Graphical representation of the complete framework
47
48
5.1.2. Graphical representations applied to a generic framework
As already said at the beginning of the Chapter, this proposal is valid for a generic EA
framework composed by the levels technology, applications, data, business and strategy. Since a specific framework is not analyzed, it is not possible to state exactly what
are the modeling languages used in each level. Anyway, considering the definition of
each level, it is possible to identify some representations used. For each representation, it will be shown a possible way to extend it, in order to highlight the main issues
related to the shift in a cloud environment. The extensions we propose, appear in each
representation as icons of different colours. Each icon identifies one issue related to
the cloud readiness of the company.
A list describing each icon, follows.
Application Credential Protected: the credentials of the application must be protected.
Encryption System Conform to Standard: the encryption system used should conform to the existing standards.
Storage & Usage of Data Encryption: data must be secured
- that is, encrypted - during the storage and the usage.
Encryption of Keys: encryption keys must be protected - that
is, encrypted.
Assets Audits: assets should be subjected to periodical audits.
Risk Analysis: a risk analysis of the assets and applications
should be performed.
Encryption needed: encryption of data and applications
needed.
Redesign Needed: application redesign needed, to guarantee portability and interoperability.
Service Availability: service availability issues.
Compliance: compliance with existing privacy regulations.
Deadline: presence of a deadline within a process.
49
Multiple Access: presence of multiple access of a resource.
Customized: applications and data formats are customized,
that is not in accordance to any standardm or adapted from
a standard specification.
Standardized: applications and data formats are standardized, that is, they are in accordance to a specific standard.
Personally identifiable information: privacy type of a datum.
Sensitive information: privacy type of a datum.
Information categorized as sensitive: privacy type of a datum.
Usage data: privacy type of a datum.
Unique device identities: privacy type of a datum.
Technology
The technology level deals with the description of the infrastructure of the company.
Software and hardware elements that support the application layer are represented together with their interrelations, as shown in Figures 5.9 and 5.10 (adapted from Hinkelmann (2011)). The main elements that can appear in this level are physical devices,
networks or software, like operating systems, middleware or databases.
This level is mainly affected by the area of governance and risk management. In particular, the company has to be compliant to laws and internal regulations. For this reason,
the assets represented in this level, that need to be inspected should be marked. The
different types of inspection is strictly related to the company. In general terms, there
can be identified at least two different types of control. The former deals with the necessity to perform, periodically, assets audits. The latter deals with the analysis of the
risk associated to specific assets, considering different scenarios.
The presence of databases, anyway, could lead to the necessity to indicate that there
are data that must be managed carefully because of privacy concerns. If there is a
database which includes a datum that belongs to one of the category described in
Chap. 4, it has to be marked with a symbol expressing the presence of privacy issues.
50
Figure 5.9.: Graphical representation of the technology level adapted from Hinkelmann
(2011)
Concerning the applications, in the current level, they just inherit their features described in the application level. All the symbols used to mark a specific application will
be reported in this level.
Applications
The application level describes the applications used by the company. This includes
their internal behavior and structure, as shown in Figure 5.11 and 5.12 (adapted from
Hinkelmann (2011)), the interrelations between them, as well as how they are used by
other applications.
The main graphical extensions for this level deal with different issues. First of all, considering the area of application security and encryption, each application should be
marked in order to show their level of security should be increased, in order to go into
the cloud. It is also necessary to perform risk analysis determined by laws or internal regulations. Moreover, each application should be classified considering the level
of standardization. Applications can use interfaces which are standardized or customized. The type of the interface used by an application is reported in the graphic of
the application itself. If the interface is customized, then the application needs a re-
51
Figure 5.10.: Graphical representation of the technology level adapted from Hinkelmann (2011)
design. The necessity of a redesign is communicated by using a special icon. Please
notice that a scenario in which an application needs a redesign and it uses a standardized interface, must not happen.
In addition to that, it is also necessary to consider the need to encrypt the files used by
the applications. This can be done, for instance, by adding a symbol in the representation of the interactions of a specific application.
If an application deals with data considered as private, then the application itself should
be labeled with the privacy icon (see Figure 5.11).
Data
The data level, intuitively, aims to represent the data used by the company. They can
be represented in many ways, by using different models. Anyway, talking in general
terms – that is without considering a specific framework and, thus, a specific representation for the current level – the data used by the company and the relations between
them can be described, for instance, with a UML diagram. It can be hypothesized that
another alternative would be to use a terms and fact types representation or an E/R
diagram.
Nevertheless, each datum used by the company has some specific values considering
its sensitiveness. As already explained in Chapter 4, data can be grouped in different
categories, which are personally identifiable information, sensitive information, infor-
52
Figure 5.11.: Graphical representation of an internal behavior of an application adapted
from Hinkelmann (2011)
mation categorized as sensitive, usage data and unique device identities.
The graphic representation used in the current level, without considering the specific
language or standard chosen, will include some symbols expressing the features of a
specific data. There will be as many symbols as the number of the different categories
of data. In this way, it will be possible, for instance, to understand the type of a specific
datum that an employee is managing. If a datum is referenced by a model of another
level, all its features will be included in the representation. As an example, if a business
process description has a reference to a specific datum that is classified as “sensitive
information”, the business model will include the datum used, marked with the special
symbol expressing the category it belongs to.
Business
As can be seen in Figure 5.8, the business level is mainly affected by the service availability problem. A possible representation which deals with this layer is the description
of a business process. The representation proposed in Figure 5.14 is based on the
Business Process Modeling Language. Anyway, the approach used to mark specific
tasks or elements used in the process, is independent on the language used.
What it is important to notice in this level, is that the company should immediately see
53
Figure 5.12.: Graphical representation of a structure of one or more applications or
components adapted from Hinkelmann (2011)
if a specific process is at risk of service availability. For this reason, the overall process should be marked with a symbol expressing the degree of service availability that
should be guaranteed. The definition of the degree and a proposal of the symbols can
be found in the knowledge representation section. As explained later on, it’s important
to take into account that the problem of service availability is strictly related to a specific
cloud provider. This means that it is not possible to say if a process is highly risky or is
safe without considering the capabilities of the cloud vendor or the service offered by
it.
Nevertheless, there are some features of the process, still related with service availability, that can be represented in any case. As explained in the next section, these
features are related to the presence of a deadline and multiple access to a resource.
Each activity which requires multiple access to a resource, will be marked with a special
symbol. The same applies when an activity is managed by the presence of a deadline.
The description of business processes can include also some documents or data storage used during the activities described. Even if they are represented, in a more
detailed way, at different levels of the architectural description, it would be preferable
to add some indications of their characteristics – if necessary. This means that if a
business process uses a document that is considered as sensitive in the data level,
this information should be reported also in the description of the business process. It
is possible to hypothesize that, once the features of a specific datum are defined at the
data level, they can be automatically reported in the business process description, by
simply referencing that specific datum. This is why in Figure 5.14 the document used
54
Figure 5.13.: UML graphical representation for the data level
has a symbol showing that it’s sensitive.
Strategy
As is possible to see in the matrix in Figure 5.8, the strategy level is the unique level not
affected. It does not need a graphical extension. It can be hypothesized that possible
representation models would be the Business Motivation Model or organization models. In this level the company expresses which goals it would like to reach and what
are the actions needed to do it. Of course, the decision of the usage of an encryption
algorithm or the categorization of the data used, impact this level. Nevertheless, symbols expressing possible cloud computing issues don’t give any additional value in this
level, since it just describes the strategy that the company would like to have.
As already shown, the symbols used are quite specific and they express possible dangers related to assets, data or information used, features of the processes. This is the
reason why they are used in the lower levels of the generic framework considered.
5.2. Knowledge representations
Knowledge representations allow to express cloud computing best practices in a semantic way, in order to automatize their description and to relate them to the graphical
representation.
The automatization takes place by using, for instance, the business rules approach.
55
Figure 5.14.: BPMN graphical representation for the business level
Formal business rules need a previous definition of terms and fact types. In Appendix
A the main term and fact types used in each domain are listed. The main business rules
for each area are shown in the next section. Formal rules will consider an approach
similar to the Semantic of Business Vocabulary and Rules of the OMG.
5.2.1. Application security and encryption
In Chapter 4 some best practices related to this area are listed. Many of them can be
used to extend the architectural description of the company in order to mark important
features of the company scenario, like the need of encryption for specific data.
The recommendations that can be considered to extend the architectural representation deal in particular with the management of credential and encryption keys, the need
of encryption for particular data and files, as well as the compliance to existing encryption standards. The main best practices related to these issues are the number 2, 5, 6,
9, 12 and 13.
These guidelines deal with the architectural description of the company. This is the
main reason why it has been chosen to provide a knowledge and graphical extension.
The remaining best practices deal with different aspects of the company. As an example, the recommendations number 1 and 3 are really generic and are related to
the concept of encryption given in number 5. Recommendations number 4, 7, 10 and
11 refer to the cloud provider. They don’t deal with the enterprise architecture representation but they are guidelines to be followed after the architectural description is
improved.
56
These recommendations impact different views of the company. In particular, they deal
with the applications, data and scope perspectives.
Applications are affected by these best practices since they should use a method of
encryption in order to safely manage the information. For this reason, it’s important to
define this need on the application level of the company description.
Data, in this case, are viewed as the files used by the applications, and they need to
be encrypted during the storage and the usage. The data represented in the data level
of the company description should be marked, in order to say that they should be managed with attention if shifted into a cloud environment.
The scope level is affected in a more general way. The usage of a method of encryption
could be seen as a strategy of the company. It’s important to state that if the company
goes to the cloud, it should conform to an existing standard.
A formal description of terms and fact types is given in Appendix A. In general terms,
the main entities involved deal with the presence of applications and related credentials, files, encryption algorithms and related encryption keys as well as the standardization of the encryption method and all the relations between these entities. A graphical descritpion of the terms and fact types involved can be found in Figure 5.15.
After having described the main entities involved in this domain, it’s necessary to de-
Figure 5.15.: Graphical representations of terms and fact types involved in the domain
application security and encryption
fine the business rules. Business rules describe the extensions that can be added to
the architectural description, as well as how it should be done.
A proposal of some SBVR operative rules for the area ”application security and encryption” follows. They are derived by the related knowledge representation and entities
57
described in Appendix A.
1. It is obligatory that each Credential is encrypted if Application hasCredential Credential.
2. It is obligatory that each File hasEncryptionStorage EncryptionMethod if Application usesFile File.
3. It is obligatory that each File hasEncryptionUsage EncryptionMethod if Application usesFile File.
4. It is obligatory that the EncryptionMethod used for the storage of a File is different
than the one used for the usage of that File.
5. It is obligatory that each EncryptionMethod has Standard is true if Application
usesMethod EncryptionMethod or Credential usesEncryption EncryptionMethod
or EncryptionKey isEncryptedBy EncryptionMethod or File hasEncryptionStorage
EncryptionMethod or File hasEncryptionUsage EncryptionMethod.
6. It is obligatory that each EncryptionKey isEncryptedBy EncryptionMethod.
These rules should be strongly considered if the company is evaluating the possibility
to go into the cloud. In this case, the rules will be represented by using the operative
form. This choice is determined by the fact that the encryption is needed in a cloud
environment, but there could be the possibility of a violation of this approach. As an
example, if the method of encryption used is not working because of a downtime, then
the encryption of data won’t be available. Anyway, even if the usage of encryption can
be violated by many causes, it must be enforced in order to work in a safe cloud environment.
5.2.2. Governance and risk management
As already described in Chapter 4, governance and risk management deal with problems and risk evaluation related to the assets of the company. The main best practices
related to this issue that can be helpful in order to extend the architectural description
of the company are number 1 and 6. These are recommendations dealing with activities that should be executed no matter what is the cloud provider.
The remaining guidelines are not represented because they are not related to the enterprise architecture description (number 2) or they refer to something that has to be
done after the shift to the cloud scenario (3 and 7). Sometimes they refer to the definition of a service level agreement and to the involvement of the company in defining it (4
58
and 5). Finally, number 8 refers to the relations among the employees working inside
the company.
The architectural objects affected by the chosen recommendations and related extensions, are the applications, data, processes, elements of the infrastructure (e.g.
servers), as well as the company’s scope.
Applications, data, processes and the elements of the infrastructure can be considered
as assets of the company. Each of them, can be further described by adding the related threat or vulnerability, if present.
The scope of the company is affected since the company should extend its view in
terms of important procedure to execute for business’ sake. The new procedures that
should be considered deal with the security control of specific assets and the deployment of risk planning.
In order to describe the main business rules related to these issues, it’s necessary to
define the most important terms and fact types. A formal definition can be found in
Appendix A. In general terms, they include all the assets of the company, the possible
threats and vulnerability, risk plans, audit as well as the relation between all these entities. A graphic description of the terms and fact types involved can be found in Figure
5.16.
A proposal of some SBVR operative rules for this domain follows. They are derived
by the related knowledge representation described above and the terms and fact types
1. It is obligatory that Company executes SecurityControl if Company owns Asset.
2. It is obligatory that Company isAwareOfThreat Threat if Asset hasPossibleThreat
Threat.
3. It is obligatory that Company isAwareOfVulnerability Vulnerability if Asset hasPossibleVulnerability Vulnerability.
4. It is obligatory that Company plans RiskPlan and RiskPlan includesThreat Threat
if at least one Asset hasPossibleThreat Threat.
5. It is obligatory that Company plans RiskPlan and RiskPlan includesVulnerability
Vulnerability if at leat one Asset hasPossibleVulnerability Vulnerability.
6. It is obligatory that Company performs Audit and Audit involves Datum.
These business rules can be viewed as mandatory. The business and the operations
of the company are governed by company’s policies. Usually, a policy is something that
must be strictly followed. It is very likely that once a company has decided to go into
the cloud, its policies are extended to cover all the related issues of new risks. From a
59
governance and risk management
different perspective, the considered company, has to extend its policies in order to go
on with its business and to manage new risky scenarios.
Nevertheless, these business rules will be represented in an operative form. Even if
it’s really important to establish new policies, there could be the possibility that one
of these rules is violated. Consider, as an example, the case of security controls.
These have to be executed by the company - or, in other words, by some responsible
employee of the company - periodically. If the employee gets sick in the scheduled
day, the security control could not take place. Even if the occurrence of this situation
is really low, this is an unfavorable scenario that will violate the policy. This means that
the rule must be enforced but, as shown, can be violated. Considering the possibility
of rules and policies violation, it could be necessary to establish penalty measures but
also a secondary plan, allowing the security control to take place.
5.2.3. Incident management
As described in Chapter 4, incident management deals with all the practices to avoid
or to minimize the consequences of incident events.
The best practices that are considered to extend the knowledge and graphical repre-
60
sentation of this domain are number 1 and 6. Both of them deal with the enterprise
architecture description and with important features related to incidents, as well as the
ways to minimize incidents consequences. The recommendation number 2 is more
related with the choice of a cloud provider. Anyway, companies can determine which
incident response procedures would like to have, before considering any cloud vendor.
The remaining guidelines are not considered since they are related with the choice of
a cloud provider (3, 5, 7), or they are not related to the enterprise architecture representation (4, 8).
The architectural layers affected by these best practices are the data level and the
scope level. The first one is affected since it’s necessary to define which data are considered as private and which encryption algorithm is used. The scope level is affected
because the company has to define the events that must be considered incidents and
the incident response procedures it would like to have.
A formal definition of the terms and fact types needed to define the business rules for
this domain, is provided in Appendix A. A graphic description of the terms and fact
types involved can be found in Figure 5.17.
The business rules needed in this area can be considered as operative, since it can
incident management
happen that someone violates them. They are derived from the terms and fact types
1. It is obligatory that Datum usesEncryption EncryptionMethod if Company usesDatum Datum and Datum isPrivate private set true.
2. It is obligatory that each Event isIncident incident set true or false.
3. It is obligatory that Company usesIncidentProcedure IncidentResponseProcedure.
61
5.2.4. Portability and interoperability
As already discussed in Chapter 4, portability and interoperability issues deal with the
ability of the company to change cloud provider or to have, at the same time, more than
one cloud vendor.
The main best practices considered, in order to extend the architectural representation
of the company, are number 4, 6 and 10. They mainly deal with the applications interfaces and data formats used, as well as security measures for transferring data and for
storing them.
The recommendation number 6 is considered, in this case, as the necessity to use
an encryption method to secure the transfer of data and application. This means that
in the architecture representation, there will be added the need to use an encryption
method. The choice of the best method to be used is up to the company. There are no
guidelines to define the main requirements that let a method be the best one. For this
reason, the company is quite free to select the method it prefers.
The remaining best practices can’t be considered since they are related with control
measures and guidelines that should be considered, after having decided to go into
the cloud.
The enterprise architecture levels affected by the extensions are the data level, the
application level and the scope level. The first one is affected since it’s necessary to
describe the format of the data used, that is if they are standardized or not. The second one, is affected because it’s necessary to describe which application interfaces are
used. The last one is affected because of the involvement of security measures (e.g.
encryption methods) for the transfer of data.
The terms and fact types needed to define the main business rules for this domain,
can be found in Appendix A. A graphic description of this terms and fact types can be
found in Figure 5.18.
The business rules of this domain are handled as operative, since they can be violated in some ways (e.g. no encryption method defined for a specific datum, due to a
forgetfulness).
1. It is obligatory that each Application usesAppInterface ApplicationInterface and
each ApplicationInterface isApplicationStandard applicationStandardized set true
or false if Company usesApplication Application.
2. It is obligatory that each Datum usesDatumFormat DatumFormat and each DatumFormat isDatumStandard datumStandardized set true or false if Company
usesDatum Datum.
3. It is obligatory that each Application usesMethod EncryptionMethod if Company
usesApplication Application.
62
portability and interoperability
4. It is obligatory that each Datum usesEncryption EncryptionMethod if Company
usesDatum Datum.
5. It is obligatory that Application needsRedesign RedesignNeeded is true if Application usesAppInterface ApplicationInterface and each ApplicationInterface isApplicationStandard applicationStandardized is false.
The issue of standard applications is very important for the area of portability and interoperability. According to Federal Office for Information Security (2011), standards
allow to run the system in different cloud environments.
The National Institute of Standards and Technology (n.d.) has identified a set of standards important for cloud computing. A set of them, their purpose and additional notes
can be found in Table 5.1.
Considering the concept of standard formats, some hypothesis can be made. Even if
a company uses a certain standards to encode their documents, this doesn’t guarantee
that it will be possible to interoperate with another cloud provider. The main problem is
related to the personalization of standard formats. In reality, it’s really likely that companies adapt a standard to their needs, not being anymore able to exchange information
without specific efforts to map them. For this reason, cloud customers should take into
account that, before going into the cloud, it’s important to test if the standards they use
are compatible with the ones of the cloud vendor.
Name
XML (Extensible Markup
Language)
HTML (HyperText Markup
Language)
SOAP (Simple Object Access Protocol)
XML Signature
XML Encryption Syntax and
Processing
OVF (Open Virtualization
Format)
OCCI (Open Cloud Computing Interface)
CDMI (Cloud Data Management Interface)
63
Purpose
Translating documents in a
machine-readable form.
Markup language for web
pages.
Protocol to exchange structured data in the implementation of web services.
Used to sign data and documents of any type.
Encryption and decryption of
digital content.
Manages and addresses the
portability and interoperability of virtual machines.
API for the vendor’s management framework.
Interface used by applications to create, delete, update and retrieve data from
the cloud.
Notes
Used in web pages.
Used in web services.
Table 5.1.: Standards used in Cloud Computing
5.2.5. Privacy
Privacy issues and related guidelines have already been described in Chapter 4.
The main best practices that allow to extend the architectural representation of the
company are number 5, 7 and 8. These recommendations are related to the categorization of the data used by the company, the security procedures adopted by the
company to handle data breaches, as well as data requirements defined by laws and
regulations. All these issues can be added to the architectural representation of the
company, in order to keep explicit the main problems related to privacy.
The remaining best practices are related with the characteristics of the cloud provider.
These are guidelines that should be considered after having decided to shift the business to the cloud. Since they include concepts usually expressed into the SLAs and
not directly related to the architecture of the company, they won’t be included among
the extensions.
The architectural levels affected by these extensions are the data level and the scope
level. The former is affected since it’s necessary to categorize the data used by the
company. The latter, since it’s necessary to identify the laws and regulations that the
company must adhere to as well as to define the privacy security procedures adopted.
The terms and fact types needed for defining the business rules for this domain, can
64
be found in Appendix A. A graphic description of them can be found in Figure 5.19.
The business rules of this area are considered as operative. This choice is made
privacy
considering the possibility of violations of them. As an example, even if the company
must adhere some regulations, there is always the possibility that some of them are
not applied. This means that they can be violated, but must be enforced.
The business rules are derived from the terms and fact types defined in Appendix A.
1. It is obligatory that Company usesIncidentProcedure PrivacySecurityProcedure if
Company usesDatum Datum.
2. It is obligatory that each Datum generalizes exactly one PersonallyIdentifiableInformation or SensitiveInformation or InformationAsSensitive or UsageData or
UniqueDeviceIdentities if Company usesDatum Datum.
3. It is obligatory that Company adheresTo PrivacyLaw.
5.2.6. Security and disaster recovery
For this domain, no extensions can be provided. All the best practices described in
Chapter 4, are related to the relation with the cloud provider. This means that the
choice of the cloud vendor has already been done and that the extensions are not related with the architectural desription of the company made a priori.
Some advices for data security and disaster management are given, but they are still
related to the characteristics of the cloud provider (e.g. disaster recovery plans, security standards). This means that there is no general information that can be added
to the architectural representation of the company, helping the firm to evaluate its potential. In all the guidelines given, the choice of going into the cloud is already done.
These are the main reasons for not giving any business rules for this domain.
65
5.2.7. Service availability
In Chapter 4, we briefly described a possible scenario where service availability is really important not to impact the mission of the company. In general terms, service
availability is always important but it becomes very critical for companies dealing with
time constraints, that is dealing with processes and procedures that should be executed in real-time. It’s important to notice that problems with real-time processes can
impact not only the mission or profits of the company but also the well-being of people
(e.g. management of a nuclear power-plant).
The system availability problem is mainly related with the provision of a service but
also with the resources that allow the service to be executed. For this reason, when
a company evaluates the possibility to go into the cloud, it should be able to say if its
processes are risky in terms of service availability. Possible threats could be the presence of time constraints - they can also be seen as a deadline - and multiple access to
the same resource done by several applications or people. In the presence of a similar
scenario, if the number of resources that can be scaled up is limited and the process
is classified by the company as risky, there could be a problem of service availability.
To be able to evaluate if a process shifted to the cloud could be risky in terms of service availability, companies should define a way to measure its features. A possible
way would be to define some business rules that, after having considered the most
critical features of a process, are able to determine the existence of risks related to that
process. The process features that should be considered are different and are related
to the company and to the purpose of the process itself. It’s also important to consider
some characteristics of the service offered by the cloud provider.
To give an example of business rules and of a possible approach to this problem, it
will be considered the scenario of a university. The university has shifted into a cloud
environment a web service and has some resources available to run the service. The
purpose of the service is to gather information and data about students and their preferences in order to manage their enrollment to the courses of the next semester. The
enrollment procedure has a deadline and it’s possible to hypothesize that the students
will send the needed data few days before the last one available.
In this case, the most important features of the process that should be considered are:
• deadline: a specific time-limit for the enrollment procedure;
• number of multiple access: the number of people that will access the same service and, consequently, the same resources at the same time;
• number of risky task of the process: a risky task is a task, within a process, that
could be executed by many users at the same time and that will access a specific
resource.
66
It’s important to notice that, even if we are talking about a specific scenario of a university, these features can be considered for other scenarios too.
One possible way to group the features of the process in a schematic way, would be
to build up a decision table. This table will consider the different characteristics of the
process and their possible values. As an output, it will give some suggestions related
to the degree of risk of the process. It’s also possible to give different weights to the
different features, in order to value more the most important.
Table ?? shows the decision table for a scenario in which the features ”number of multiple access”, ”deadline” and ”number of tasks” are important. More precisely, the truth
value related to ”number of multiple access” should be considered as a comparison
with a threshold identifying the number of multiple access guaranteed by a cloud vendor. The same applies to the truth value for ”number of tasks”, where the value is
derived from a comparison between the total number of tasks of a process and the
number of tasks that will be, potentially, executed by many people at the same time.
Moreover, these three features are weighted in a different way. The deadline could be
considered the most important and its weight is 50%. This happens since the presence of a deadline triggers the most risk of system availability. The number of multiple
access is weighted as 30%. Finally the number of tasks executed by multiple users (or
applications) at the same time, is weighted as 20%.
The decision table shows different outcomes:
• Highly risky: really high probability that the process will be used by many users or
applications at the same time. There is a strong possibility that, if the capabilities
of the cloud provider are not good, there could be a service unavailability. The
customer company should choose a really good vendor, able to satisfy its needs in
terms of resources scalability. Additionally, the SLA should be examined carefully,
especially the part of vendor responsibilities, terms of the service and penalties if
the service can’t be provided.
• Risky: high probability that the process will be used by many users or applications at the same time. To avoid service unavailability, the customer company
should choose the appropriate service provider and should take care about the
definition of the SLA. Also in this case, the most important parts are the vendor
responsibilities, terms of the service and penalties if the service can’t be provided.
• Manager’s choice: the process is considered 50% risky and 50% safe. Managers
should choose the right service provider (that is, a service provider with the right
capabilities) and should define a good SLA in order to have securities if the vendor
is not able to provide an adequate service (as written in the contract).
67
• Standard: the probability that the process will be used by many users or applications at the same time is low. The need of resource scalability is low.
• Safe: the probability that the process will be used by many users or applications
at the same time is really low, almost zero. Usually there isn’t a particular need to
scale up many resources.
The next step would be to represent the decision table in form of business rules. In this
way, the main guidelines and related controls, could be automatized. To do that, it’s
necessary to define the main terms and fact types for this scenario. A formal description of them, can be found in Appendix A. In general terms, they involve processes,
tasks as well as the relations between them. They also consider important features of
tasks - like if it can be executed by many users at the same time - and processes like the presence of a deadline, the total number of tasks and how many of them are
considered as risky. A graphic description of the terms and fact types involved in this
domain, can be found in Figure 5.20.
A proposal for some business rules for the area ”service availability” follows. They
service availability
are derived by the related knowledge representation described above and the related
terms and fact types described in Appendix A. The approach proposed uses structural
business rules. The choice of structural rules is determined by the fact that these rules
68
define how the company defines its world - that is, defines the behavior related with
process and risk of service unavailability.
1. It is necessary that Process hasOutcome ”highly risky” if Process hasDeadline is
”true” and numberRiskyTask is greater than numberTasks and Company evaluates Vendor and numberMultipleAccess is greater than accessGuaranteed.
2. It is necessary that Process hasOutcome ”risky” if Process hasDeadline is ”true”
and numberRiskyTask is not greater than numberTasks and Company evaluates
Vendor and numberMultipleAccess is greater than accessGuaranteed.
3. It is necessary that Process hasOutcome ”manager’s choice” if Process hasDeadline is ”false” and numberRiskyTask is greater than numberTasks and Company
evaluates Vendor and numberMultipleAccess is greater than accessGuaranteed.
4. It is necessary that Process hasOutcome ”standard” if Process hasDeadline is
”false” and numberRiskyTask is not greater than numberTasks and Company evaluates Vendor and numberMultipleAccess is greater than accessGuaranteed.
5. It is necessary that Process hasOutcome ”risky” if Process hasDeadline is ”true”
and numberRiskyTask is greater than numberTasks and Company evaluates Vendor and numberMultipleAccess is not greater than accessGuaranteed.
6. It is necessary that Process hasOutcome ”manager’s choice” if Process hasDeadline is ”true” and numberRiskyTask is not greater than numberTasks and Company
evaluates Vendor and numberMultipleAccess is not greater than accessGuaranteed.
7. It is necessary that Process hasOutcome ”standard” if Process hasDeadline is
”false” and numberRiskyTask is greater than numberTasks and Company evaluates Vendor and numberMultipleAccess is not greater than accessGuaranteed.
8. It is necessary that Process hasOutcome ”safe” if Process hasDeadline is ”false”
and numberRiskyTask is not greater than numberTasks and Company evaluates
Vendor and numberMultipleAccess is not greater than accessGuaranteed.
It’s important to notice that to determine the extent of service unavailability, the company should have already identified some possible cloud vendors. This is an important
step for the evaluation of risk, since it’s necessary to know the number of multiple access guaranteed by the vendor. Anyway, in general terms, to evaluate if a service could
have availability problems, it’s necessary to know the characteristics of the possible solutions.
For the reasons cited above, this domain is considered as an exception since it’s strictly
69
related to the offer of a specific cloud provider. This means that the general features
related to the processes of the company (e.g. presence of a deadline, number of tasks
and risky tasks, number of multiple accesses) can still be described in the architectural
description. Nevertheless, it’s important to notice that it’s not possible to show the degree of risk of a specific process if there is no information about a possible cloud vendor
or about the number of multiple accesses guaranteed. This leads to the necessity to
identify possible cloud providers in order to determine the final risk of a process.
Number of
multiple
access
Deadline
Number of
risky tasks
Outcome
V
V
V
Higly risky
V
V
F
Risky
V
F
V
Manager’s choice
V
F
F
Standard
F
V
V
Risky
F
V
F
Manager’s choice
F
F
V
Standard
F
F
F
Safe
Symbol
Table 5.2.: Service availability decision table
5.3. SLA representation
In a cloud environment scenario, Service Level Agreements are really important in order to define responsibilities, requirements, guidelines and penalties. SLAs description
can be automatized and included in the architectural description of the company.
There are many languages used to describe the SLAs and their related entities. Koller
(2011) collected many of them, trying to describe the main features.
Among the ones presented, there is the Web Service Level Agreement proposed by
Keller & Ludwig (2003), which allows to describe and represent an SLA in a Web environment. The Open Grid Forum proposed the Web Services Agreement which allows
to desribe an SLA related to the usage of services between a service vendor and a
70
customer.
Nevertheless, Paschke & Bichler (2005) proposed a formal way to describe SLAs
based on logic programming. This approach has many strengths, as stated by Paschke
& Bichler (2005):
• agreements can be represented in a formal, reusable and extensible way;
• easy maintenance of the rules since they are separated from the service management application;
• it’s possible to detect contract violations and rule conflicts;
• complex policies and agreements can be automated by using logic programming.
SLAs need a knowledge representation too, in order to specify the relations between
the different actors and roles within the agreement. As shown for each domain, it’s
possible to describe the main terms and fact types involved in an SLA. As a possible
description of this structure, the Figure 5.21 provided by Koller (2011) can be considered.
The graph represented in Figure 5.21 is related with the Web Service Level Agreements language, but it can be take into account as a general representation since it’s
composed by many entities and relations used in the SLA definition. In a cloud computing scenario, where the architectural description of the company is extended by
using business rules, an SLA representation as the one proposed by Paschke & Bichler (2005) can fit well. Business rules are already used - as described in the previous
sections - and there is the possibility to automate the controlling of SLA constraints and
violations and rule conflicts. Moreover, it includes also a way to semantically describe
domain models. Rules and the semantic description of the concepts will be already
combined.
Figure 5.21.: Terms and fact types involved in an SLA
71
6. Conclusions
72
6. Conclusions
As shown in the previous chapters, the state of the art doesn’t provide a valuable way
for the evaluation of cloud readiness of a company. The classic architectural representations provide just information about the strategy of a company, its processes and
applications used, the data related to them as well as the infrastructure. This is a
generic information which doesn’t give any clue about company’s cloud potential.
To let companies make a conscious choice about going or not into the cloud, it’s necessary to externalize the main features dealing with security of data and applications,
governance, standardization of applications and data format as well as constraints set
by laws and regulations.
This paper has proposed a solution for this kind of evaluation. The main best practices
to be followed can be deducted by standard suggestions (that is for each kind of company), but also to specific needs derived by the business activities of the company, as
well as internal regulations or governmental laws. For this reason, the best practices
proposed can be extended and adapted to the specific needs of the company.
The knowledge representation is really important and should be as more precise as
possible. The proposal uses a representation made with terms and fact types and a
description of the constraints based on the business rules approach. This choice was
determined by the fact that companies work with processes. Processes are usually
described in a graphic way and they include a representation of the main terms and
fact types involved. Moreover, they are combined with business rules in order to set
specific constraints valid during the execution of the process. This means that companies should be already familiar with the solutions we used. In this way, they don’t need
to train employees to describe the knowledge representation.
The graphic representation is used to show in a direct way what are the levels of the
company affected by the shift in a cloud environment. Moreover, within the levels affected, is shown which diagrams are directly involved. This step needs just to add a
graphic sign to specific levels or diagrams and is based on the business rules previously defined.
Table 6.1 shows the mapping between the knowledge representation, graphic representation and the affected best practices. For each recommendation area described
in Chapter 5, the number of influenced best practice is shown. Please notice that the
6. Conclusions
73
recommendations dealing with the strategy level have no graphic representation. The
reason is that these best practices should be considered in order to set the strategy
and the principles of the company and it’s not so helpful to add specific icons in, for
instance, a Business Motivation Model since the goals and the vision of the company
have already been determined.
As explained in Chapter 5, it’s important to keep in mind that even if a specific icon
is related to a specific domain and a specific layer of the architectural description, it
can appear also in other layers. This happens since some representations include the
references to objects described in other representations of different layers.
Best
Practice
Knowledge
Representation
Graphic Representation
Application security
and encryption
2
Business rule 1
5, 12, 13
Business rules 2, 3, 4
6
Business rule 5
9
Business rule 6
Governance and risk
management
1
Business rules 1 and 6
6
Business rules
2, 3, 4, 5
Incident response
1
Business rule 2
-
2
Business rule 3
-
6
Business rule 1
Portability and
interoperability
6. Conclusions
74
4
Business rule 1, 2
6
Business rule 3, 4
10
Business rule 5
Privacy
5
Business rule 1
7
Business rule 2
8
Business rule 3
-
Service availability
10
Business rules
from 1 to 8
Table 6.1.: Mapping between knowledge representation, graphic representations and
best practices affected
Even if this approach helps the company to become conscious about its cloud potential, it makes sense to think about a real implementation of the extensions proposed.
First of all, there will be the necessity to have the right capabilities and competencies
to develop the proposal. This means having, among other things, skilled people - available in-house or to hire - or to outsource the development of the solution to an external
company.
Companies need other efforts to extend the set of best practices we proposed. They
need to add other important recommendations related to the way they see the world
and to the policies which govern their business. In a scenario where policies change
quite often, the company would need to define again and again the set of best practices. This will lead to the necessity to define also the terms and fact types that will
be used to describe new business rules. For this reason, this approach would not be
advisable for companies which need a high degree of agility, since updating the architectural representation takes much time and costs.
Anyway, as with other projects, companies should develop a business case. At first
sight, it’s possible to say that the implementation of this solution will lead to high costs
and high amount of time needed for its completion. Even if the benefits delivered would
6. Conclusions
75
be really high, it’s unlikely they will overcome all the efforts spent.
Moreover, it’s important to notice that there is still missing a good approach to represent SLAs in an automatized way, that could fit with an approach as the one proposed.
Thus, before starting the implementation of the solution, it would be advisable to find
possible solutions in the field of the automation of SLAs within enterprise architectures.
A. Business Rules
76
A. Business Rules
This appendix describes the main terms and fact types for the areas of best practices
described in chapter 4. These are the minimum number of entities and relations that
has to be considered, in order to extend the architectural representation.
A.1. Application security and encryption
In order to describe the rules related to this scenario, it’s necessary to define the main
terms and fact types involved.
Terms:
• Application: software tool used by the company.
• Credential: username and password used by the users to log into the application.
• File: data used by users and applications.
• EncryptionMethod: algorithm used to encrypt (and decrypt) the data.
• EncryptionKey: key used to encrypt the data.
• standard: express if the encryption method is standardized.
• encrypted: express if a specific credential is encrypted.
Fact Types:
• Application hasCredential Credential
• Application hasEncryptionKey EncryptionKey
• Application usesFile File
• Application usesMethod EncryptionMethod
• Credential usesEncryption EncryptionMethod
• Credential is encrypted
A. Business Rules
77
• EncryptionMethod usesKey EncryptionKey
• EncriptionMethod has standard
• EncryptionKey isEncryptedBy EncryptionMethod
• File hasEncryptionStorage EncryptionMethod
• File hasEncryptionUsage EncryptionMethod
A.2. Governance and risk management
The minimum number of terms and fact types needed to define business rules for this
domain, follows. Terms:
• Company: firm operating to create profit and/or to satisfy customer needs. In this
scenario, it’s the company that would like to go into the cloud.
• Asset: resource with economic value, owned by the company.
• Process: is a special type of asset. It’s composed by a set of activities which,
once executed, allow to reach a goal.
• Datum: is a special type of asset. It includes the data used by the company.
• SW : is a special type of asset. It can include applications and operating systems.
• HW : is a special type of asset. It includes system devices and networks.
• SecurityControl: special mechanisms chosen by the company to check the security of the assets.
• Threat: possible menaces related to the assets of the company.
• Vulnerability: possible exposures related to the assets of the company.
• RiskPlan: plans allowing the management of risks and risky scenarios.
• Audit: evaluation of the quality of the data and information.
Fact Types:
• Process specializes Asset
• Datum specializes Asset
• SW specializes Asset
A. Business Rules
78
• HW specializes Asset
• Asset hasPossibleThreat Threat
• Asset hasPossibleVulnerability Vulnerability
• Company owns Asset
• Company plans RiskPlan
• Company isAwareOfThreat Threat
• Company isAwareOfVulnerability Vulnerability
• Company performs Audit
• Company executes SecurityControl
• SecurityControl dealsAsset Asset
• RiskPlan includesThreat Threat
• RiskPlan includesVulnerability Vulnerability
• Audit involves Datum
A.3. Incident management
The minimum number of terms and fact types to describe the business rules needed
for this domain, follows. Terms:
• Event: is something that can happen during the normal business activities.
• incident: is an attribute that expresses if a particular event is seen as an incident.
• Datum: datum or information used by the company.
• private: is an attribute that expresses if a specific datum is sensitive or not.
• IncidentResponseProcedure: it includes the possible procedures to respond to
events considered as incidents. In particular, it includes the incident procedures
the company would like to have.
A. Business Rules
79
Fact Types:
• Company usesDatum Datum
• Company usesIncidentProcedure IncidentResponseProcedure
• Company hasEvent Event
• Event isIncident incident
• Datum isPrivate private
• Datum usesEncryption EncryptionMethod
A.4. Portability and interoperability
The minimum number of terms and fact types needed to define the business rules for
this domain, follows. Terms:
• DatumFormat: format used to represent the datum.
• datumStandardized: specifies if the format of the datum is standardized or not.
• Application: software tool used by the company.
• redesignNeeded: specifies if the application needs to be redesign in order to be
portable.
• ApplicationInterface: interface used for the application.
• applicationStandardized: specifies if the application interface is standardized or
not.
Fact Types:
• Company usesApplication Application
• Datum usesEncryption EncryptionMethod
A. Business Rules
80
• Datum usesDatumFormat DatumFormat
• DatumFormat isDatumStandard datumStandardized
• Application usesMethod EncryptionMethod
• Application needsRedesign redesignNeeded
• Application usesAppInteface ApplicationInterface
• ApplicationInterface isApplicationStandard applicationStandardized
A.5. Privacy
• PersonallyIdentifiableInformation: it’s a type of datum that can directly identify a
person.
• SensitiveInformation: it’s a type of datum that is related to job performance, religion and health status of a person.
• InformationAsSensitive: it’s a type of datum that includes video camera records
made in open places.
• UsageData: it’s a type of datum that includes information gathered by the usage
of computer devices.
• UniqueDeviceIdentities: it’s a type of datum that includes information related to
hardware identifiers or IP addresses.
• Law: laws and regulations that must be followed by the company during its business activities.
• PrivacyLaw: laws and regulations dealing with privacy issues.
• IncidentResponseProcedure: it includes the possible procedures to respond to
events considered as incidents. In particular, it includes the incident procedures
the company would like to have.
A. Business Rules
81
• PrivacySecurityProcedure: procedures used by the company to handle incidents
related to privacy issues.
Fact Types:
• PrivacySecurityProcedure specializes IncidentResponseProcedure
• Company usesIncidentProcedure PrivacySecurityProcedure
• Company adheresTo Law
• PersonallyIdentifiableInformation specializes Datum
• SensitiveInformation specializes Datum
• InformationAsSensitive specializes Datum
• UsageData specializes Datum
• UniqueDeviceIdentities specializes Datum
• PrivacyLaw specializes Law
A.6. Service availability
• Process: set of interrelated tasks that, when executed, allow to reach a goal.
• Task : atomic activity that allows to reach a sub-goal.
• Vendor : cloud provider offering some useful services to the company.
• multipleAccess: the task can be executed by many users or applications at the
same time.
• deadline: presence of a time limit within the process can be executed.
• numberRiskyTask: number of tasks that can be executed by many users or applications at the same time.
A. Business Rules
82
• numberTasks: total number of tasks of a process.
• numberMultipleAccess: average number of people or applications that can execute the process at the same time.
• outcome: degree of risk for service unavailability of a process.
• accessGuaranteed: number of multiple access to a specific service, offered by
the vendor to the company.
Fact Types:
• Process hasTask Task
• Process hasDeadline deadline
• Process hasRiskyTask numberRiskyTask
• Process hasMultipleAccess numberMultipleAccess
• Process hasNumberTasks numberTasks
• Process hasOutcome outcome
• Task hasMultipleAccessTask multipleAccess
• Company hasProcess Process
• Company evaluates Vendor
• Vendor hasAccessGuaranteed accessGuaranteed
The relation ”Company hasProcess Process” is a higher level definition. This is not
used for the evaluation of service availability. Nevertheless, this is a requirement
needed in order to determine some business rules for this area. The main reason
is that, to evaluate the risk of service unavailability, the company has to have at least
one process.
Bibliography
83
Bibliography
Allega, P. (2010), ‘Defining ea: Low barriers to entry (my mother has an ea definition,
too)’. http://blogs.gartner.com/philip-allega/2010/08/11/defining-ea-low-barriers-toentry-my-mother-has-an-ea-definition-too/.
Architectures for Enterprise Integration, I. T. F. (2003), Handbook on enterprise architecture, Springer-Verlag, Berlin;.
Buck, K. & Hanf, D. (2010), ‘Cloud SLA Considerations for the Government Consumer’.
Systems Engineering at MITRE. Cloud Computing Series.
Centers for Medicare and Medicaid Services (2011), ‘CMS Cloud Computing Standards’.
Cloud Security Alliance (2009), Security Guidance for Critical Areas of Focus in Cloud
Computing.
Continental Automated Buildings Association (2004), ‘Connecting Devices with Web
Services’.
Delaquis, R. S. & Philbin, G. (2011), ‘TO CLOUD OR NOT TO CLOUD?’, Issues in
Information Systems XII(1), 54–58.
Ebneter, D., Grivas, S. G., Kumar, T. U. & Wache, H. (2010), ‘Enterprise Architecture
Framework for Enabling Cloud Computing’. CLOUD ’10 Proceedings of the 2010
IEEE 3rd International Conference on Cloud Computing.
European
Network
and
Information
Security
Agency
(2009),
‘An
SME
perspective
on
Cloud
Computing’.
Available
at:
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-smesurvey/at download/fullReport.
Federal Office for Information Security (2011), ‘Security Recommendations for Cloud
Computing Providers’.
Gellman, R. & Dixon, P. (2009), ‘Cloud Computing Privacy Tips’.
Bibliography
84
Hinkelmann, K. (2011), ‘Enterprise Architecture Views and Viewpoints in ArchiMate’.
Enterprise Architecture Slides at FHNW.
Jarvis, R. (2003), Enterprise Architecture: Understanding the Bigger Picture - A Best
Practice Guide for Decision Makers in IT, The UK National Computing Centre,
Manchester.
Keller, A. & Ludwig, H. (2003), ‘The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services’. Journal of Network and Systems Management, vol. V11, pp. 57-88.
Koller, B. (2011), ‘Enhanced SLA management in the high performance computing
domain’. Ph.D Thesis - Institut für Höchstleistungsrechnen.
Lankhorst, M. (2009), Enterprise Architecture at Work: Modelling, Communication and
Analysis, 2. edn, Springer, Berlin.
Linthicum, D. (2010), ‘Relevance of enterprise architecture to cloud computing’.
http://www.ebizq.net/blogs/cloudsoa/2010/12/relevance-of-enterprise-architectureto-cloud-computing.php.
Marc Lankhorst, P. J. (2007), ‘Introduction to the second workshop on
trends in enterprise architecture research (tear 2007)’.
http://www.via-novaarchitectura.org/proceedings/tear-2007/introduction-to-the-second-workshop-ontrends-in-enterprise-architecture-research-tear-10.html.
National Institute of Standards and Technology (2011), ‘Guidelines on Security and
Privacy in Public Cloud Computing’.
National Institute of Standards and Technology (n.d.), ‘Inventory of Standards Relevant
to Cloud Computing’. Retrieved December 1st 2011, http://collaborate.nist.gov/twikicloud-computing/bin/view/CloudComputing/StandardsInventory.
Open Group (2008-2009), ‘ArchiMate 1.0 specification’. Retrieved January 24th 2012.
URL: http://www.opengroup.org/archimate/doc/ts archimate
OpenCrowd (2011), ‘Cloud taxonomy’. http://cloudtaxonomy.opencrowd.com/taxonomy/.
Retrieved January 25th 2012.
Paschke, A. & Bichler, M. (2005), ‘SLA Representation, Management and Enforcement’. Internet-based Information Systems, Technical Univeristy Munich. Published
at IEEE International Conference on e-Technology, e-Commerce, e-Service EEE05,
Hong Kong, 2005.
Bibliography
85
Pearson, S. (2009), ‘Taking Account of Privacy when Designing Cloud Computing Services’.
Perez, C. (2002), Technological Revolutions and Financial Capital”, Edward Elgar.
Somashekar, S. (2010), Opportunities for the Cloud in the Enterprise, Technical report,
CA.
The Business Rules Group (2000), ‘Defining Business Rules - What Are They Really?’.
Thorn, S. (2011), ‘Cloud Computing requires Enterprise Architecture and TOGAF9 Can
Show the Way’.
Toomas Tamm, Peter B. Seddon, G. S. & Reynolds, P. (2011), ‘How does enterprise
architecture add value to organisations?’. http://aisel.aisnet.org/cais/vol28/iss1/10.
Velte, T., Velte, A. & Elsenpeter, R. (2009), Cloud Computing, A Practical Approach.

Technical Report

Transcription

Similar documents

probabilistisches Record Linkage

Neue Hacker-Attacken in der "Cloud"