You are on page 1of 76

Oracle Practitioner Guide

Building Cloud Services


Release 3.1
E49942-01

January 2014
Building Cloud Services, Release 3.1

E49942-01

Copyright 2013, 2014 Oracle and/or its affiliates. All rights reserved.

Primary Author: Anbu Krishnaswamy Anbarasu and Mark Wilkins

Contributing Author: Dr. James Baty, Stephen Bennett, Scott Mattoon

Contributor: Cliff Booth, Dave Chappalle, Bob Hensle, Rob Reakes, Graham Mcmillan

This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it
on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data
delivered to U.S. Government customers are "commercial computer software" or "commercial technical data"
pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As
such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and
license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of
the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software
License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management
applications. It is not developed or intended for use in any inherently dangerous applications, including
applications that may create a risk of personal injury. If you use this software or hardware in dangerous
applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other
measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages
caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks
are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD,
Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced
Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle
Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your
access to or use of third-party content, products, or services.
Contents

Send Us Your Comments ....................................................................................................................... vii

Preface ................................................................................................................................................................. ix
Document Purpose...................................................................................................................................... ix
Document Scope .......................................................................................................................................... x
Related Documents ..................................................................................................................................... xi
Document Map .......................................................................................................................................... xiii
Audience..................................................................................................................................................... xiii
Document Structure .................................................................................................................................. xiii
How to Use This Document..................................................................................................................... xiv
Conventions ............................................................................................................................................... xiv

1 Introduction
1.1 Differentiating Cloud Services.................................................................................................. 1-2
1.1.1 Specific Considerations for SaaS........................................................................................ 1-5
1.2 Program Level v. Project Level Activities ............................................................................... 1-5
1.3 Cloud Service Development Phases......................................................................................... 1-7

2 Program Level Activities Overview


2.1 Cloud Service Analysis .............................................................................................................. 2-1
2.2 Requirements Analysis .............................................................................................................. 2-2
2.2.1 Classification of Cloud service requirements .................................................................. 2-4
2.3 Cloud Service Identification ...................................................................................................... 2-5
2.3.1 Basic steps in Cloud service identification....................................................................... 2-6
2.3.2 Detailed activities in the Cloud service identification process ..................................... 2-7
2.3.2.1 Applications .................................................................................................................. 2-8
2.3.2.2 Platforms........................................................................................................................ 2-8
2.3.2.3 Database......................................................................................................................... 2-8
2.3.2.4 Infrastructure ................................................................................................................ 2-8
2.3.2.5 Extension services......................................................................................................... 2-9
2.3.2.6 Capacity Planning ........................................................................................................ 2-9
2.3.2.7 Development Cloud ..................................................................................................... 2-9
2.3.2.8 Cloud candidate services stack................................................................................ 2-10
2.3.2.9 Defining the service boundaries.............................................................................. 2-11
2.3.2.10 Determining the sourcing model ............................................................................ 2-12

iii
2.3.2.11 Service justification.................................................................................................... 2-12
2.3.2.12 Workload validation ................................................................................................. 2-13
2.4 Cloud Service Portfolio Management and Release Planning ............................................ 2-13
2.5 Cloud Architecture Refinement............................................................................................. 2-14
2.5.1 Cloud Services and SOA.................................................................................................. 2-15
2.5.2 Providers and Consumers ............................................................................................... 2-16
2.5.3 Architectural Capabilities................................................................................................ 2-16
2.6 Other Program Level Considerations ................................................................................... 2-17
2.7 An Example............................................................................................................................... 2-17
2.7.1 Problem .............................................................................................................................. 2-17
2.7.2 Solution .............................................................................................................................. 2-17

3 Inception
3.1 Inception Phase Activities.......................................................................................................... 3-1

4 Elaboration
4.1 Cloud Service Definition............................................................................................................ 4-1
4.1.1 Defining Cloud Service Contracts ..................................................................................... 4-2
4.1.2 Defining Service APIs ......................................................................................................... 4-2
4.1.2.1 Characteristics of good Cloud APIs........................................................................... 4-2
4.1.2.2 IaaS API.......................................................................................................................... 4-3
4.1.2.3 PaaS API......................................................................................................................... 4-3
4.1.2.4 SaaS API ......................................................................................................................... 4-5
4.1.3 Defining service specifications........................................................................................... 4-6
4.1.3.1 Template for Cloud service definition....................................................................... 4-6
4.1.3.2 Defining Service metrics.............................................................................................. 4-7
4.2 Designing Cloud services .......................................................................................................... 4-8
4.2.1 Design Choices ..................................................................................................................... 4-9
4.2.2 Service Design Template ................................................................................................. 4-10
4.2.3 Service Assembly Template ............................................................................................ 4-11

5 Construction
5.1 Cloud Service Implementation ................................................................................................. 5-1
5.2 Packaging and Assembly........................................................................................................... 5-2
5.2.1 Defining Deployable Entities ............................................................................................. 5-3
5.3 Cloud Service Testing................................................................................................................. 5-4

6 Transition
6.1 User Acceptance Testing............................................................................................................ 6-1
6.2 Cloud Service Deployment........................................................................................................ 6-2

7 Operate
7.1 Operations Best Practices........................................................................................................... 7-2

8 Summary

iv
v
List of Figures
11 Cloud Service Development - Programs and Projects........................................................... 1-6
12 Focus Areas and Program/Project Scope................................................................................ 1-7
13 Cloud Service Development Process ....................................................................................... 1-8
21 Cloud Service Analysis Activities ............................................................................................ 2-2
22 Requirements Analysis .............................................................................................................. 2-3
23 Cloud Service Development Influencing Factors................................................................... 2-6
24 Cloud Service Identification Steps............................................................................................ 2-6
25 Cloud Service Identification Process........................................................................................ 2-7
26 Cloud Candidate Services Stack Model................................................................................ 2-10
27 Cloud Candidate Services Stack Example............................................................................ 2-11
28 Cloud Service Portfolio Management and Release Planning ............................................ 2-14
29 Cloud Architecture Refinement............................................................................................. 2-15
31 Inception Phase Activities (SaaS).............................................................................................. 3-2
32 Inception Phase Activities (IaaS and PaaS) ............................................................................. 3-2
41 Elaboration Phase Activities...................................................................................................... 4-1
42 Cloud Service Definition............................................................................................................ 4-2
43 PaaS API ....................................................................................................................................... 4-4
44 Cloud Application Integration.................................................................................................. 4-5
45 Cloud Service Design ................................................................................................................. 4-9
51 Construction Phase Activities ................................................................................................... 5-1
52 Cloud Service Implementation ................................................................................................. 5-2
53 Packaging and Assembly........................................................................................................... 5-3
54 Cloud Service Testing................................................................................................................. 5-4
61 Transition Phase Activities ........................................................................................................ 6-1
62 User Acceptance Testing............................................................................................................ 6-2
63 Cloud Service Deployment........................................................................................................ 6-3
71 Operate - OA&M Phase Activities............................................................................................ 7-1

vi
Send Us Your Comments

Building Cloud Services, Release 3.1


E49942-01

Oracle welcomes your comments and suggestions on the quality and usefulness of this
publication. Your input is an important part of the information used for revision.
Did you find any errors?
Is the information clearly presented?
Do you need more information? If so, where?
Are the examples correct? Do you need more examples?
What features did you like most about this document?

If you find any errors or have any other suggestions for improvement, please indicate
the title and part number of the documentation and the chapter, section, and page
number (if available). You can send comments to us at:
its_feedback_ww_grp@oracle.com.

vii
viii
Preface

Oracle Reference Architecture (ORA) is a product-agnostic reference architecture


based on architecture principles and best practices that are widely applicable and that
can be implemented using a wide variety of products and technologies. ORA does not
include any implementation artifacts for the prescribed architecture. Rather, ORA
addresses the building of a modern, consistent IT architecture while minimizing the
risk of product incompatibilities and obsolescence.
ORA is an extensible reference architecture that describes many facets of IT. It is
comprised of several documents that cover core concepts of technology, along with
other documents that build upon these core concepts to describe more complex
technology strategies.
The ORA Cloud documents present the ORA concepts from the perspective of Cloud,
highlighting the specific details of Cloud as an elaboration of the ORA core concepts.
In this way other technology strategies that follow ORA remain fully consistent and
compatible with the resulting Cloud architecture.
This document is part of a series of documents that describe IT Strategies from Oracle
(ITSO) Cloud strategy. Please consult the ITSO web site for documents pertaining to
Cloud and other technology strategies.

Document Purpose
This document describes a methodological approach to building Cloud services
spanning all the Cloud service models, from Software-as-a-Service (SaaS), through
Platform-as-a-Service (PaaS), to Infrastructure-as-a-Service (IaaS).
The word "software", in the context of SaaS, however, is a particularly broad term
covering a wide range of categories of machine instructions spanning the layers of the
traditional IT architecture stack. Typically, the term "SaaS" narrows the use of the
word "software", referring most of the time at least, to a Cloud based delivery model
for business applications. Such business applications commonly include financial
accounting software, customer relationship management (CRM), enterprise resource
planning (ERP), human capital management (HCM), and a plethora of custom
applications. This is not to say that SaaS is necessarily constrained to business
applications, however, software at the lower levels of the IT stack, in the context of
cloud, would typically belong to other cloud models. For example, operating system
software belongs to IaaS while middleware software falls into the category of PaaS.
Since SaaS generally refers to application software at the top of the IT stack, this
category of software will be referred to interchangeably as either "SaaS" or "application
services" for the purposes of this document.

ix
The approach presented in this document is intended to augment existing software
development strategies by focusing on the aspects of cloud service construction that
are distinct from existing engineering practices. In addition, this approach loosely
follows an enterprise-class variation of the Unified Process (UP) and as such lends
itself to integration with existing Iterative and Incremental Development (IID)
methods including the Oracle Unified Method (OUM) and Agile development
frameworks.

Document Scope
The focus of this document is engineering of Cloud services for delivery through any
of the Cloud service models i.e. SaaS, PaaS, IaaS. Little attention is given to
foundational cloud concepts since these are covered in other ITSO documents. For
example the definition of Cloud service models and associated sub-models can be
found in the Cloud Foundation Architecture document.
This document describes the practices specific to the engineering of cloud services in
the framework of a Software Development Lifecycle (SDLC). It identifies the primary
architecture and design concerns for engineering services for cloud (SaaS) and
identifies the key technical criteria for selection of the underlying layers e.g. SaaS on
PaaS, IaaS, or traditional IT environment (PaaS on IaaS, or traditional IT environment,
etc.). While this document focuses on the aspects of service engineering that are
unique to cloud it is intended only to augment, rather than replace, existing strategies
for engineering and associated SDLC methods.
In the context of Oracle Unified Method (OUM), this document describes the
activities within the Envision and Implement focus areas. As such, it encompasses
program and project level activities for building Cloud services. In addition to
covering all the project phases in the Implement focus area (Inception, Elaboration,
Construction, and Transition), Cloud Service Analysis and Cloud Architecture
Refinement (from the Initiate, and Maintain and Evolve phases) are introduced briefly
to show how analysis and architecture support service projects at the program level.
The broader subject of business justification for engineering Cloud services is beyond
the scope of this document; however, this subject is covered in the document Creating a
Roadmap to Cloud Computing. Creating a Roadmap to Cloud Computing also describes the
project methodology and implementation phases used in this document. Program
level Envision considerations in this document are limited to concerns that directly
impact implementation of Cloud service projects, such as, platform selection.
Similarly, the Operate focus area, describing processes and procedures for the effective
operation of Cloud services, is covered by the Cloud Operations document.
While the focus of this document is Cloud Service projects, the word "project" is used
to refer to a variety of different types of projects associated with Cloud. Some example
of different Cloud projects are "cloud platform services projects" (as in PaaS), "initial
cloud build project", and also projects that deploy applications to a cloud. Where the
specific type of project is not obvious from the context its description is expanded.
The diagram below shows how this document fits in the ITSO document set in relation
to other ETS topics.

x
While this document necessarily touches some broader topics, such as software
architecture or operations, these are included only insofar as they are concerns of any
Software Development Lifecycle (SDLC). Other topic areas, such as business and
strategy, are beyond the scope of this document.
The importance of cost and benefits of Cloud to both providers and consumers is
critical to the successful adoption of Cloud. However, what is measured will vary
greatly depending on many factors, such as, planning an enterprise wide cost savings
initiative or an application migration for agility. Given the complexity of the subject of
costing it is beyond the scope of this document. Some information on this subject can
be found in Creating a Roadmap to Cloud Computing which introduces the topic of how
to measure an allocate costs incurred.

Related Documents
IT Strategies from Oracle (ITSO) is a series of documentation and supporting
material designed to enable organizations to develop an architecture-centric approach
to enterprise-class IT initiatives. ITSO presents successful technology strategies and
solution designs by defining universally adopted architecture concepts, principles,
guidelines, standards, and patterns.

xi
ITSO is made up of three primary elements:
Oracle Reference Architecture (ORA) defines a detailed and consistent architecture
for developing and integrating solutions based on Oracle technologies. The reference
architecture offers architecture principles and guidance based on recommendations
from technical experts across Oracle. It covers a broad spectrum of concerns pertaining
to technology architecture, including middleware, database, hardware, processes, and
services.
Enterprise Technology Strategies (ETS) offer valuable guidance on the adoption of
horizontal technologies for the enterprise. They explain how to successfully execute a
strategy by addressing concerns pertaining to architecture, technology, engineering,
strategy, and governance. An organization can use this material to measure their
maturity, develop their strategy, and achieve greater levels of adoption and success. In
addition, each ETS extends the Oracle Reference Architecture by adding the unique
capabilities and components provided by that particular technology. It offers a
horizontal technology-based perspective of ORA.
Enterprise Solution Designs (ESD) are cross-industry (applicable to many industries)
and industry-specific (focused on a single vertical industry) solution perspectives
based on the Oracle Reference Architecture. They adhere to the ORA principles and
also draw on the best practices and guidelines provided in ETS collateral. They define
the high level business processes, business functions, and software capabilities that are
required to build enterprise-wide industry solutions. ESDs map the relevant
application and technology products against solutions to illustrate how capabilities in
Oracle's complete integrated stack can best meet the business, technical, and
quality-of-service requirements.
This document is a practitioner guide within the Cloud Enterprise Technology
Strategy.
Please consult the ITSO web site for a complete listing of ORA documents and
associated materials in the ITSO series.

xii
Document Map
The picture below shows the ITSO Cloud documents, their scope and relationships.

This document is part of a set of practitioner guides that includes the following:
Creating a Roadmap to Cloud
Building Cloud Services (this document)
Building Cloud Infrastructure - Implementation of Physical and Management
Infrastructure
Cloud Operations
Cloud Governance
Cloud Security
This document, Building Cloud Services Release 3.1, supersedes the original
document, Building Infrastructure and Platform Cloud Services Release 3.0.
Additional references can be found in the Appendices.

Audience
This document is intended for enterprise architects, application architects, project
managers and developers. The material is designed for a technical audience that is
interested in learning about Cloud architecture and how to develop an approach for
building enterprise class Cloud services.

Document Structure
This document is organized into chapters based on the lifecycle phases of the Cloud
service development methodology. The chapters are organized as follows:
Chapter 1, "Introduction," presents an overview of the Oracle methodological
approach for Cloud service development.
Chapter 2, "Program Level Activities Overview," outlines the more broadly
scoped activities concerned with the enterprise-wide architecture encompassing
all Cloud projects. In the context of OUM, this chapter highlights the

xiii
Cloud-specific activities with the Initiate / Maintain and Evolve phases (within in
the Envision focus area) for Cloud service development.
Chapter 3, "Inception," describes project start-up activities including requirements
analysis and verification of business objectives for a Cloud service development.
Chapter 4, "Elaboration," describes the elaboration phase of Cloud service
development.
Chapter 5, "Construction," describes the construction phase of Cloud service
development.
Chapter 6, "Transition," describes the transition phase of Cloud service
development.
Chapter 7, "Operate," provides an introduction to the operational activities
involved in Cloud development.
Chapter 8, "Summary," is a brief summary and concluding remarks.
Appendix A, "Further Reading," provides a lists of additional resources.
Appendix B, "References," provides a lists of additional resources.
Glossary provides a definition of the terms highlighted in bold throughout
document.

How to Use This Document


This document is designed to be read from beginning to end. However, each section is
relatively self contained and may be read independently from the other sections.
In order to make this document self-contained many ancillary topics are incorporated
without detailed explanations. These broader topics however, are expanded in related
documents which are listed in the appendix and cross-referenced in the text where
appropriate.

Conventions
The following text conventions are used in this document:

Convention Meaning
boldface Boldface type in text indicates a term defined in the text, the ORA
Master Glossary, or in both locations.
italic Italics type in text indicates the name of a document or external
reference.
underline text Underline text indicates a hypertext link.

xiv
1
Introduction
1

Most organizations have recognized Cloud Computing as a key strategy for enabling
business agility and organizational efficiency. Successful adoption of Cloud
Computing requires a) clearly defined roadmap and b) well-defined development and
operational processes for building and operating Cloud infrastructure and Cloud
services. Building business applications as Cloud services provides many benefits to
the corporations as well as Cloud service providers. At the same time, Cloud
Infrastructure and Platform services present new ways of developing, deploying, and
managing applications. This kind of a paradigm shift is hard to achieve without
changes to traditional organization structure and development processes.
Organizations that are already using Service Oriented Architecture (SOA) will
typically find it easier to adopt Cloud, since SOA and Cloud require several
organizational and engineering discipline changes that are similar. Other organizations
may need to look at the way they develop IT capabilities and make necessary changes
to take advantage of Cloud. This doesn't mean that existing methodologies need to be
replaced, but some adjustments may be needed to accommodate this shift.
The process of developing Infrastructure as a Service (IaaS), Platform as a Service
(PaaS), and Software as a Service (SaaS) are somewhat different from traditional IT
engineering practices. This guide focuses on the methodology for building Software
(applications), Infrastructure, and Platform Cloud services where they are distinct
from traditional software engineering.
The methodology described in this document is intended to be customized for the
needs of your organization. "One size fits all" approach may not be suitable for Cloud
due to the variety of different forms and magnitudes that it can take. This
methodology provides general guidance on what needs to happen, but it is flexible
enough to be customized if needed. For example, the order in which Cloud services
are identified and built may depend on the specific strategy of the organization. What
should be determined first? Is it the service model or the deployment model? Each
approach has its own merits and pitfalls, so organizations should make the choice of
whichever approach works better for them.
The ITSO document Creating a Roadmap to Cloud Computing defines the process of
creating a pragmatic roadmap for Cloud. The roadmap activity typically spins off
several projects that include service development and infrastructure build out projects.
The intention of this document is not to provide a comprehensive end-to-end process
that replaces the existing software development methodology used in enterprises but
rather to highlight the variations required to successfully build Cloud services so that
existing development process can be modified accordingly. However, if you do not
currently use a formal process for software development, this process can be adopted
in conjunction with any Iterative and Incremental Development (IID) method, such as
the Oracle Unified Method (OUM), as the primary development process.

Introduction 1-1
Differentiating Cloud Services

1.1 Differentiating Cloud Services


The idea of hosting business applications to sell as a service has been around for a long
time. As far back as the 1960s mainframe computers were used to share computing
resources to run applications for multiple customers. This form of centralized
computing was called "time-sharing" or "utility computing". The rapid growth of the
Internet in the 1990s presented broader opportunities for centralized computing and
the Application Service Provider (ASP) concept was created. ASPs typically host
third-party applications on behalf of their customers relieving them of the burden of IT
maintenance, providing application specialisms, and offering rental-style pricing
models over traditional hardware and license acquisition.
In general, ASPs have had little or no influence over the software architecture of the
third party applications they host for their customers. For this reason, they commonly
run separate instances of an application for each customer. This approach is unable to
fully optimize the use of resources and lacks scalability. This is just the first of a
number of differences between the ASP and SaaS provider.
Before embarking on a Cloud service development program it is necessary to address
the question "how cloudy do we want to be?". In other words it is important to decide
in advance, what characteristics of Cloud Computing will be most beneficial (and
potentially which ones are not needed). This approach helps an organization decide on
its goals for Cloud and starts the formation of an enterprise-wide architecture
definition. To this end we start by looking at the characteristics of Cloud and what
they mean in the context of Software, Platform, and Infrastructure services.
In order to qualify under the general heading of "cloud", a service must exhibit some
or all of the characteristics of the widely accepted definitions of the National Institute
of Standards and Technology, Information Technology Laboratory (NIST). At the
highest level NIST offers the following definition of cloud computing:

"Cloud computing is a model for enabling convenient, on-demand network


access to a shared pool of configurable computing resources (e.g., networks,
servers, storage, applications, and services) that can be rapidly provisioned and
released with minimal management effort or service provider interaction."

NIST definitions and other broader characteristics are described in more detail in the
ITSO Cloud Foundation Architecture document. In order to develop Cloud services it is
necessary to consider what these differentiating characteristics mean in the context of
the various tiers of cloud services. The following lists outline the ways in which the
cloud characteristics manifest in services, starting with the NIST characteristics:
On-demand self-service: a consumer should be able to acquire Software, Platform,
or Infrastructure services, select appropriate service levels, administer its
capabilities, and manage service consumption with little or no involvement from
the provider's personnel.
Resource pooling: services should be provided from shared platform and
infrastructure resources (compute, network, storage) that may be allocated from a
pool as needed and released back to the pool when demand subsides. Ideally this
growth and contraction of resource allocation occurs automatically within
parameters agreed in advance between provider and consumer. Resource pooling
is primarily a capability of the underlying Cloud infrastructure, however,
architectural strategies must be established across the service tiers in order to
make use of this capability by ensuring the resources can be consumed effectively
and managed accordingly.

1-2 Building Cloud Services


Differentiating Cloud Services

Rapid elasticity: service capabilities may be rapidly scaled up and down as needed
(ideally automatically). Resources available to the service consumer should appear
unlimited (within the constraints of service level agreements). In general, rapid
elasticity is provided at the infrastructure level, but, as with the closely related
resource pooling, this capability must link architecturally across the service tiers.
Measured service (metering): Types of metrics vary widely across Software,
Platform, and Infrastructure services, but it is important to establish the
relationships between them when multiple tiers of services are being deployed.
This enables consistent, end-to-end accounting of resource utilization.
Broad network access: ideally the application service should be available
anywhere (that matters to the consumer) on any device. Naturally some
real-world constraints should be applied, but the general implication is that the
service should be accessible using widely adopted, standard network protocols
(i.e. Internet Protocols) using thin client (such as freely available browsers or other
"thin" applications) fixed and mobile devices. Specifically, this precludes legacy
telecoms communications technologies and heavy-client applications commonly
tied to a specific type of device (typical of the ASP model) and thus avoids the
need for end-point maintenance by the provider. In some cases, regulatory or
policy constraints may require that network access be quite narrow (e.g. a highly
secure environment supporting consumers via a private network), however, part
of this capability can still be achieved through the use of browser-based solutions
and the essence of Rich Internet Applications can still be provided without the
"Internet".
The ITSO Cloud Foundation Architecture document extends the list of characteristics
with:
Multi-tenancy: multiple, separate user communities may be accommodated by
cloud application services. While accommodating disparate groups of users
requires great attention to security and governance, some level of harvesting of
intelligence about user behavior, sharing of reference data, and mechanisms for
cooperation, etc. may offer benefits for the provider and consumers.
Scale and velocity: in this combined characteristic, scale of course refers to the
potential for great scalability in a cloud environment, not just in terms of raw
computing resources, but also the capabilities associated with business growth in a
cloud environment. Closely connected to scale is velocity, the greatly improved
speed of getting things done in the cloud. In terms of application services scale
and velocity might include the ability to rapidly expand the use of an application:
this has many implications ranging from the basic scalability of service through
removal of technical constraints, to elimination of friction in human processes
through automation and abstraction. In some ways scale and velocity is merely a
summary result of achieving other cloud characteristics, but in Software, Platform,
or Infrastructure service terms, the requirements for this characteristic should be
carefully assessed at an early stage. Many architecture and design decisions will be
critical to achieving scale and velocity, while the long-term success of Cloud in any
given environment may hinge on this characteristic: the need for scale and velocity
will help define the meaning and importance of the five NIST and other
characteristics.
Automation: automation is a cornerstone of cloud computing, without it many of
the characteristics mentioned here would be impractical. Through automation
many of the mundane, time-consuming operational tasks required to support
Software, Platform, or Infrastructure service development can executed by the
developer as needed thus applying the cloud self-service strategy. Self-service
through automation and abstraction in software development is commonly called

Introduction 1-3
Differentiating Cloud Services

"dev-ops". By shifting certain controls to the developer and eliminating operator


intervention the development cycle is transformed from a reactive one to a
just-in-time approach in which the coordination of resource allocation (e.g. test
environment build-out and deployment) is all but eliminated. To work effectively,
automation requires great attention to standardization and governance. The
following characteristics are also tightly linked to automation and/or abstraction.
Declarative configuration: where possible the end-user / consumer experience
aspects of Software, Platform, or Infrastructure services should be highly
configurable. For example, in Cloud application service development, aspects such
as the look-and-feel, branding, flexible data elements, etc. should be configurable
without the need for programmatic code changes. This is another form of
abstraction ultimately enabling transfer of control to other participants.
Programmatic control: Software, Platform, and Infrastructure services should
provide a programmatic interface (API) for integration between service tiers and
with management and security infrastructure.
Process and rules abstraction: processes control should be abstracted to the highest
appropriate level and should be managed through suitable process tooling. In this
way processes at all levels from cloud component assembly, through development
concerns such as packaging, to end user business processes can be most effectively
monitored, improved, integrated, and adapted.
Administrative functions: consumer concerns, such as user provisioning and
maintenance should be transferred, through automation and abstraction, to the
users that manage them most effectively. This is largely equivalent to the NIST
"self-service" characteristic when it is applied in the context of Software, Platform,
or Infrastructure services.
Management capabilities: all cloud services must enable the consumer to take
responsibility for application management of concerns, such as consumption, cost
control & accounting, performance monitoring & reporting.
It is important to understand the context when considering cloud characteristics:
Dev-ops (an aspect of self-service), for example, while potentially very useful to the
cloud application service development project, is actually a function of cloud service
tiers IaaS and/or PaaS, and is not a result of SaaS. Achieving such efficiencies in an
application services project, along with non-functional requirements of the application
(such as those concerned with scale and velocity), depends heavily on the underlying
service tiers and/or infrastructure environment.
These characteristics must be evaluated by every potential provider wishing to
develop cloud services. Some of these characteristics may be viewed as business
drivers while others should be established as architecture principles, typically at the
enterprise / program level and reviewed during the inception phase of each project.
Some finer-grained details may be determined at the elaboration phase within a
project and may become widely accepted design patterns. Some may not be required
at all (permitted by the earlier statement "a service must exhibit some or all of the
characteristics"), but the case for rejecting (or deferring) specific characteristics should
be clearly recorded. It is worth mentioning that the evaluation of a characteristic
should assess the benefits from point of view of both the provider and the consumer.
Many characteristics (and architectural principles) from Service Oriented Architecture
(see SOA Foundation document) are also relevant in the development of cloud services.
This is explained in more detail in Chapter 2, "Program Level Activities Overview".
Other details specific to a particular application architecture, such as support for
transactions, are typically found in design detail (Elaboration phase).

1-4 Building Cloud Services


Program Level v. Project Level Activities

It is worth noting at this point that the use of the word "functional" when referring to
Cloud service requirements or capabilities takes on a slightly different meaning from
that of traditional software engineering, particularly when used in the context of
Infrastructure and Platform services. In software engineering "functional
requirements" distinguish the business purpose of an application (e.g. "transfer funds")
from the technical ("non-functional") implementation needs (e.g. "apply level 3
transaction consistency"). In the case of IaaS and PaaS the consumer is no longer the
end-user of an application. Instead, Infrastructure and Platform service consumers
considers more technical capabilities (such as database consistency and concurrency)
to be the function of the service.

1.1.1 Specific Considerations for SaaS


Application architectural requirements, whether they are enterprise-mandated Cloud
strategy manifesting from the Cloud characteristics (above) or specific non-functional
requirements of the application, commonly involve some dependency on the platform
and infrastructure capabilities. Emerging platform and infrastructure requirements
must be evaluated at the earliest possible stage (Inception phase) so as not to be
derailed by deficiencies in the environment later in a project.
Of particular concern are the choices of environment in which the Cloud application
services will be developed, executed, and operated. These concerns are covered in
more detail in Chapter 2, "Program Level Activities Overview".

1.2 Program Level v. Project Level Activities


As explained already this document focuses primarily on project level concerns.
Projects represent discrete units of work that come together to create coordinated
services. However, Cloud application services invariably rely on platform and
infrastructure services (whether they are Cloud based or not), while separate
application projects must typically also be built to work together. This is where
program level activities are critical for structure, standards, and coordination. Program
level activities are typically strategic initiatives that benefit multiple business units and
projects. These include roadmap creation, reference architecture development, Cloud
governance, Cloud method development, Cloud service portfolio management etc.
Cloud services projects should be initiated using project identification strategies
defined and coordinated by the program level. This is described in the document
Creating a Roadmap to Cloud Computing. Architectural strategies for integration should
follow the enterprise-wide reference architecture while platform and infrastructure
projects typically take requirements from applications and associated Cloud
application service projects. All these are program level concerns and can be found in
other ITSO documents listed in the glossary.
The motivation for Cloud services may originate from a variety of sources. An
enterprise is typically a provider and consumer with very clear and specific needs,
while a Commercial Cloud Service Provider (CCSP) is a provider-only and must
develop more broadly applicable Cloud service offerings based on market analysis
and commercial considerations.
An enterprise SaaS project may simply identify Cloud services based on business
requirements and a mandate that all new development should adhere to Cloud
strategies. Technical requirements arising from such application projects have a major
impact on the design of Infrastructure and Platform Cloud services. These
requirements must be coordinated at the program level.

Introduction 1-5
Program Level v. Project Level Activities

The significant requirements emerging from enterprise level strategic planning will
drive the determination of (1) service model layering and (2) the SaaS deployment
model and (3) the degree to which the enterprise will be a provider of SaaS. This is
outlined in Chapter 2 of this document while further guidance on this subject can be
found in the ITSO document Creating a Roadmap to Cloud Computing.
Cloud development is supported by multiple projects. Figure 11 illustrates three
types of projects -
Cloud services project,
Business delivery project, and
Cloud infrastructure project
Cloud infrastructure projects may be required to support the other types if it is not
already established; however, infrastructure is out of scope for this document and is
covered separately in Building Cloud Infrastructure.

Figure 11 Cloud Service Development - Programs and Projects

Figure 11 shows multiple entry points into Cloud service development. Enterprises
are typically both consumers (public Cloud services directly consumed by business or
brokered by IT) and providers (private Cloud services built and operated by IT). This
use case is slightly different from a Commercial Cloud Service Provider (CCSP) as
Commercial Cloud Service Providers predetermine commercial Cloud services based
on the market drivers and their own business strategy. So identifying services is
relatively straight forward in this case. The service boundaries still need to be
validated by the process and may result in further breakdown of services.
In addition to defining business functionality, an enterprise business delivery project
identifies Cloud services based on the Infrastructure and Platform requirements of an
application project. Non-functional (non-business functional, to be precise) and
technical requirements have a major impact on the design of Infrastructure and
Platform Cloud services.
IT initiatives such as modernization, consolidation, and rationalization may result in
the identification of IT capabilities that could be implemented with new or existing
Cloud services. For example, existing servers may be consolidated and migrated to a
private Cloud for agility and cost reduction reasons.

1-6 Building Cloud Services


Cloud Service Development Phases

Another entry point shown in the diagram is from the program scoped activities such
as road map creation where Cloud services are strategically identified based on the
business drivers, strategy, and roadmap. These requirements are further refined and
implemented by the Cloud services project as well.
Cloud services should be designed to be "future proof", that is, to handle spikes in
future load requirements, to provide modular capabilities to facilitate alternative
configurations, new assurance and security requirements, etc. The service
development should be aligned with portfolio management activities to ensure that
Cloud services can support the needs of current and near-future projects. Cloud
services must be designed to elastically scale on demand, however, a Cloud Provider
must ensure that there are sufficient resources available to support the scalability
requirements of the Cloud. The "Building Cloud Infrastructure" document covers this
topic in more detail.
Due to the high start-up costs for Cloud and the inability to predict all requirements
from the outset, it is generally a good idea to plan for a phased roll-out. This also
reduces the problem of overlapping costs of providing large-scale services before
consumers are able to migrate. These planning and cost management issues are
covered in more detail in the document Creating a Roadmap to Cloud Computing.

1.3 Cloud Service Development Phases


The activities for building Cloud services are categorized under three major focus
areas - Envision, Implement, and Operate. These focus areas are described in the
Creating a Roadmap to Cloud Computing document. This document focuses primarily on
the Implement focus area in which the services are developed. Some program level
activities in Envision are particularly important to the coordination of services projects
and are briefly described in this document.

Figure 12 Focus Areas and Program/Project Scope

The Envision focus area deals with development and maintenance of enterprise level
IT strategy, architecture, and governance. This is explained in more detail in Creating a
Roadmap to Cloud Computing. Envision also assists in the transition from
enterprise-level planning and strategy activities to the identification and initiation of
specific projects. It is this part of Envision that is of particular interest in the initiation
and coordination of Cloud services projects. Envision activities span both "Initiate" and

Introduction 1-7
Cloud Service Development Phases

"Maintain and Evolve" phases. While the Initiate phase provides strategic guidance in
the creation of Cloud projects, it is the later Maintain and Evolve phase that enables
the incorporation of feedback as new Cloud service requirements emerge from the
projects themselves.
The Implement focus area provides an Iterative and Incremental Development (IID)
framework to develop and implement business solutions with consistency and
predictability combined with rapid deployment. The project level phases are
Inception, Elaboration, Construction, and Transition.
Cloud Operations is such a significant topic that it has a separate focus area (Operate)
and a separate ITSO document, Cloud Operations. Cloud Operations is also introduced
in Chapter 7.
The primary areas of interest in this document are indicated by the dotted line in
Figure 12. While Envision activities are mostly beyond the scope of this document,
they are shown here in order to identify key inputs (however, this is not intended to be
an exhaustive list). The key process of interest in building Cloud services is Enterprise
Architecture. This process creates and maintains an enterprise-level view of both the
application and technical architecture of the systems.
Figure 13 shows the relationship between program scoped analysis and architecture
activities and the various types of projects (Cloud services and Cloud infrastructure)
that follow them.

Figure 13 Cloud Service Development Process

At the program scope, the key activities of interest are Cloud Service Analysis and
Cloud Architecture Refinement. Cloud Service Analysis provides service identification
and requirements for the initiation of projects. Cloud Architecture Refinement assumes
that a Cloud Reference Architecture already exists and provides a mechanism for
maintaining it. An outline of the program scoped activities, Cloud Service Analysis
and Cloud Architecture Refinement, can be found in Chapter 2.
At the project level Figure 13 shows four phases of Cloud service development -
Inception, Elaboration, Construction, and Transition. These phases closely align with
Oracle Unified Method (OUM) and Unified Process (UP).

1-8 Building Cloud Services


Cloud Service Development Phases

The remainder of the document covers Cloud service project scoped activities by
OUM/UP phase:
The Inception phase focuses on start-up concerns, such as, project feasibility,
requirements review, and building the project team.
The Elaboration phase focuses on design details, such as, service interfaces.
The Construction focuses on the development of the Cloud service. One of the
main concerns addressed in this phase is packaging and assembly of Cloud
services into deployable entities that allow rapid provisioning and
decommissioning. Cloud service testing is performed in this phase.
The last phase of the Implement focus area is Transition in which User Acceptance
Testing (UAT) and production deployment activities occur. UAT of Cloud services
is somewhat different from the traditional UAT. This topic is discussed in more
detail in.Section 6.1, "User Acceptance Testing"
It is important to remember that this method is intended to be implemented following
Iterative and Incremental Development (IID) practices. While the "focus" of these
phases is outlined here, there is no intention to perform only a subset of the project
disciplines. Indeed, the goal of IID is to involve every discipline to create a tangible,
incremental result in each iteration of each phase. The statements in the foregoing list
merely identify the focus of this document, in particular the parts that are unique to
Cloud service development, within the context of the OUM or UP framework.

Introduction 1-9
Cloud Service Development Phases

1-10 Building Cloud Services


2
Program Level Activities Overview
2

The activities and work-products at the program level (Initiate, Maintain and Evolve
phases described in the Envision focus area in OUM) typically include the following:
Roadmap planning
Business analysis
Enterprise architecture
Cloud service candidate identification
Portfolio management
Governance
While most of these activities are beyond the scope of this document it is important to
ensure that projects are adequately supported by coordinated, program level Cloud
Service Analysis and Cloud Architecture Refinement. These work-products, Cloud
Service Analysis and Cloud Architecture Refinement, fall into the categories of
"business analysis" and "enterprise architecture" respectively, both during the Initiate
phase and iteratively through the Maintain and Evolve phase.
The OUM Envision Focus Area encompasses all the activities of the Initiate and
Maintain & Evolve phases and provide a coordinated mechanism, not only for driving
business analysis and concrete Cloud architecture definition into projects, but also a
mechanism to refine these assets using feedback from projects and new requirements
from business leadership.
As with traditional software engineering, Cloud service development also begins with
requirements. However, Cloud service development differs from traditional
engineering in a couple of ways. In most cases, Infrastructure and Platform services
are enterprise scoped services shared by multiple projects within the enterprise, which
means that the method should support identifying common requirements and
isolating or refining them into enterprise requirements that can further be built as
Cloud services.

2.1 Cloud Service Analysis


Figure 21 shows the high level activities in Cloud Service Analysis. The benefits of
Cloud increase with scale. It is an investment that provides increasing returns as more
applications are deployed to it, just as SOA did. Cloud requirements should primarily
be driven by business requirements for cost reduction and agility. In addition, the
needs of the existing application portfolio must be considered, although not all
applications will be suitable candidates for Cloud migration. Some service
requirements will be identified based on common requirements across multiple

Program Level Activities Overview 2-1


Requirements Analysis

in-flight projects. In all cases, Cloud services should be built with reuse in mind, so
future projects can use the Cloud service with little or no change.

Figure 21 Cloud Service Analysis Activities

The key activities in Cloud Service Analysis are listed below.


Requirement Analysis: Business and IT requirements are analyzed and in conjunction
with the Cloud Reference Architecture and existing application portfolio. The result is
a refined set of enterprise-wide Cloud requirements for and requirements for Cloud
service projects.
Cloud Service Identification: Cloud services are identified based on the requirements
and justified for development by the Cloud service creation team.
Cloud Service Portfolio Management and Release Planning: Cloud services
identified are aligned with the migration of applications to the Cloud and Cloud
service catalog is kept up to date. The Cloud Portfolio Management and Release
Planning activity shown in the diagram covers these details.

2.2 Requirements Analysis


As shown in Figure 22, requirements analysis begins by gathering requirements.
These inputs include project requirements, IT requirements, reference architecture,
application portfolio, and existing capabilities:
Cloud Reference Architecture: Even before the iterative process of cloud
architecture refinement can begin some form of reference architecture must
pre-exist. The Oracle Cloud reference architecture should be used as a starting
point in the absence of a more refined model. In any case the cloud reference
architecture describes the basic cloud services and their requirements.
Existing application portfolio: Many of the platform and infrastructure
requirements can be determined from an analysis of the existing application
portfolio.
Current and planned IT capabilities: IT will be aware of the capabilities provided
not only for direct application support but also for crosscutting concerns such as
security, management and monitoring, etc.
Requirements from current and planned projects: The requirements for existing
projects must also be considered. Many will be similar to those capabilities
determined by the existing application portfolio and IT capabilities. However, in
order to minimize future re-work it is important to look for unique needs arising
in these projects.

2-2 Building Cloud Services


Requirements Analysis

Figure 22 Requirements Analysis

In the case of an enterprise, business delivery projects receive requirements from the
line of business for implementing specific business functionality. Commercial Cloud
Service Providers define their requirements based on market demand and their
business strategy.
One of the first steps in the Cloud service development process is to identify the
common / shared requirements and refine them into enterprise Cloud requirements.
These requirements are to become enterprise assets and should be maintained at the
enterprise scope. Typically an enterprise asset management or metadata management
repository is used for this purpose.
The requirements that are common across multiple projects are identified and
classified into SaaS and PaaS/IaaS requirements. Infrastructure and Platform services
are primarily influenced by non-functional or technical requirements and architecture
standards. In this context, "non-functional" requirements mean that they are not
functional-business requirements.
IT requirements also drive the need for Infrastructure and Platform Cloud services.
These requirements typically stem from the IT cost reduction efforts that result in data
center modernization, consolidation, and application rationalization initiatives. For
example, IT may decide to modernize the infrastructure to the latest hardware and
storage technologies. In order to minimize impact to the business, IT would perform
this upgrade using a phased approach. Some organizations choose to rollout
virtualization first, and then replace the underlying hardware. By moving to Cloud,
these organizations can build the virtualization layer, and Cloud capabilities first, and
then can migrate all the applications to the Cloud running on modernized hardware.
The resource requirements that come out of this analysis are fed back into the
infrastructure project analysis. This process is explained in more detail in the Building
Cloud Infrastructure document.
The following types of Cloud service requirements, most of which are related to the
Cloud characteristics, are important while identifying the Cloud services.
Cloud service scalability requirements - current and future demands, anticipated
spikes in load
Cloud service Availability requirements - up time, business criticality, business
impact, business continuity, and disaster recovery

Program Level Activities Overview 2-3


Requirements Analysis

Service invocation requirements (API) - How the users (mostly the application
developers) are going to use and manage the service.
Elasticity requirements - Does the service require dynamic scaling up and scaling
down? How fast does the service need to change capacity in response to demand?
Security requirements - includes a definition of the security entities, how data and
application will be secured, authentication, authorization, and audit requirements.
Integration requirements - internal and external integration requirements.
Self service provisioning needs - this is typically not a directly stated business
requirement but rather derived from the agility requirements such as time-to-deploy.
Self service management needs - If the development team or "devops" team can
manage certain aspects of the application, what would they be? Typically application
management is performed by the business owners (or their IT delivery teams) while
the operations of the platform and infrastructure are performed by the operations
team. "Devops" typically falls between these opposite ends of the process,
encompassing packaging and promotion of releases to testing environments for
example.
Metrics - What metrics need to be collected?
Service business metrics - usage, reuse, ROI, number of business units supported
etc.
Service operational metrics - up time, health, utilization metrics etc.
Many of the items listed here have inherent security requirements. While security is
called out on its own, it is also a consideration within self-service provisioning,
management, etc. Cloud security is covered in more detail in the document Enterprise
Strategy for Cloud Security.

2.2.1 Classification of Cloud service requirements


Business requirements are categorized into one or more of the following:
Green-field requirements that require brand new "business" capabilities to be
built. To deliver these requirements, new business services and IT capabilities
need to be developed. Green-field requirements stem from business initiatives
such as introduction of new products, entry into new markets, and enhancing
competitive advantage through time-to-market or agility improvements.
This is a top-down scenario where new Cloud services are identified to enable
the business capabilities.
Application or Service components are not known initially in this case. So,
initial analysis must be done to learn enough about the components to
determine Cloud fit and to decide which kind of Cloud they should be
deployed to.
Requirements that aim to reduce cost or improve customer experience of existing
business interactions (not by introducing new features or capabilities).
These requirements do not require new "business" capabilities to be delivered
but are geared towards reducing overall IT cost and improving the
performance of IT and business applications.
While these projects might aim to reduce IT costs, this will still need
engagement with business users because at the very least they may need to be
involved in a regression testing effort after a migration.

2-4 Building Cloud Services


Cloud Service Identification

Note that this case may require new "IT" capabilities to be built to deliver cost
reduction or to improve performance.
This is a bottom-up scenario, where existing IT capabilities are re-architected
and migrated to Cloud architecture through IT consolidation, rationalization,
or modernization initiatives.
Migration efforts may identify new Cloud services to be created using existing
assets or existing Cloud services to be discovered for the migration of
applications.
Application or Service components are already known in this case and the key
task is to identify if they are suitable for Cloud deployment and the type of
Cloud based on the business requirements and architecture constraints.
The third classification is where pre-built new services are added to the existing
Cloud service portfolio. This is a common scenario for Commercial Cloud Service
Providers who often add new Cloud services through M&A.
Some level of standardization is required to re-brand the acquired services and
integrate with the common Cloud management infrastructure.
Possibly migrate the services to run in the base Cloud.
Integration of these acquired Cloud services into the Cloud service catalog.
Note that the benefits of the cloud need to be experienced by both the cloud provider
(e.g. lower cost to manage and maintain) and cloud consumer (e.g. lower cost of using
or flexibility and agility of the cloud). If only one party is benefiting then tensions are
likely to arise in the adoption of cloud. For example, IT might benefit from cost
savings while consumers see only constraints (either by IT dictating what application
services are available or what applications can be deployed to the cloud). In this case,
if the IT department, as cloud provider is reducing costs then this cost saving must be
shared with the cloud consumer in the form of lower usage charges. Alternatively, if
the consumer is getting the benefits of better customer experience then the IT provider
may have to be paid for the improved level of service because they might need to
provide more hardware etc.
For this reason, it might be useful to split this category of benefits into requirements
that reduce cost (clarifying who gets the cost saving) from requirements that improve
customer experience (clarifying who benefits and who pays for that improvement).

2.3 Cloud Service Identification


The three key dimensions that influence Cloud service development are a) the service
model b) the deployment model and c) the role, as shown in Figure 23.

Program Level Activities Overview 2-5


Cloud Service Identification

Figure 23 Cloud Service Development Influencing Factors

The service model determines which layer or layers of the architecture will support the
requirements. An enterprise may decide to build SaaS Cloud on custom platform or
deploy business applications on a PaaS Cloud. The choice of architecture depends on
the enterprise guiding principles, perceived benefits, and architecture factors.
The deployment model determines where the Cloud service is going to reside and
how it will be managed. The requirements may be fulfilled by custom in-house
development or off the shelf Cloud offerings from external providers. This choice has
a major impact on Cloud service development.
Another aspect that has a major impact on how Cloud services are built is the role of
the organization building the Cloud services. A commercial Cloud provider may
gather requirements, build and manage services differently than an enterprise that is
building the Cloud for its own use. Similarly, an Intermediation Cloud broker plays
the role of both consumer and provider, which makes their Cloud service
development lifecycle unique. What happens in the development of Cloud services
depends on roles such as builder, consumer, and operator.

2.3.1 Basic steps in Cloud service identification


Once Cloud service requirements are documented, Cloud service candidates can be
identified. Figure 24 illustrates the high level steps in the Cloud service identification
process.

Figure 24 Cloud Service Identification Steps

The deployment model could be determined either before identifying the service
candidates or after. The roadmap planning process would normally determine the
deployment model of applications to be migrated to Cloud. Enterprises define guiding

2-6 Building Cloud Services


Cloud Service Identification

principles on choosing deployment models. For example, some corporations favor


public Clouds, while some discourage their use. Given the requirements, public Cloud
suitability is assessed based on architecture standards and principles. Deployment
model decision made during the roadmap process is further validated and refined in
this phase.
Service model and service candidate identification is explained in detail in the next
section. Business requirements may drive the need for Infrastructure, Platform, or
Application services, or any combination. Building PaaS does not require IaaS, but
either a PaaS or a traditional platform can be deployed on IaaS. For example, a Java
application server platform may be identified as a potential PaaS. This Cloud service
may be designed to run on a "Compute" node that's offered as IaaS. Alternatively, you
may decide to run the Java application server on dedicated hardware that is not
exposed as IaaS.
The final step in the process is identifying the workloads and their characteristics.
Workload requirements validate the Cloud service definitions and ensure that the
Cloud services being built are suitable for deploying the workload.

2.3.2 Detailed activities in the Cloud service identification process


As shown in Figure 25, Cloud service identification deals with the procedures and
guidelines that an enterprise adopts to identify new Cloud service candidates.

Figure 25 Cloud Service Identification Process

As described in the Section 2.2, "Requirements Analysis", Cloud service requirements


are identified based on the requirements of the project and are refined to the enterprise
scope. These requirements are further analyzed by the service creation project team for
validity before identifying services for implementation.
In most cases, non-functional requirements and architecture standards drive the
platform, technology, and information decisions. These decisions drive the choice of
the platforms (PaaS), databases, and Infrastructure (IaaS).
Functional requirements primarily drive SaaS decisions. Functional requirements are
implemented as SOA services or application components. SOA services can be

Program Level Activities Overview 2-7


Cloud Service Identification

deployed as Cloud SaaS offerings. Application components may be custom developed


or acquired as a COTS product, if available commercially.
There is no clear-cut and prescriptive method to identify cloud services. The following
sections provide some general ideas and guidelines to help identify the Cloud services.
The applicability of each of the following services is dependent upon the specific
requirements.

2.3.2.1 Applications
Application requirements have traditionally been divided into "functional" and
"nonfunctional". Functional refer to the business activities performed by the
application. This is the applications primary purpose, but functional application
requirements analysis is a well-established discipline and is beyond the scope of this
document. Understanding nonfunctional application requirements on the other hand
are critical to successful cloud adoption.
Nonfunctional application requirements must be specified in generic high-level terms
using categories such as, Reliability, Availability, Scalability, and Performance (RASP).
In this way the business needs can be specified first without regard for technological
constraints or simply operating within existing capabilities. Once these business level
statements of nonfunctional requirements is established they may be considered in the
context of the underlying platform and infrastructure and what capabilities can be
offered to meet these requirements.

2.3.2.2 Platforms
The platform on which the application will be run is determined based on the
technical requirements and architecture standards. For example, latency and
availability requirements may lead to the selection of a Java based application server
and the architecture standards may narrow it down to Oracle WebLogic server
platform.
If the project has reliability or store-and-forward requirements, there is most likely a
need for a queuing platform.

2.3.2.3 Database
Database presents another opportunity to leverage Cloud services. Most applications
require a database of some kind and architectural standards typically dictate the use of
a standardized database version across the enterprise. Making the database available
as a Cloud service is one way of enforcing these standards. In addition it provides
automated provisioning and self service benefits that are inherent to a Database as a
Service (DBaaS) cloud.
A number of key issues need to be considered while identifying database services.
These include data availability, data redundancy, backup and restore, and
performance.

2.3.2.4 Infrastructure
The next step is to identify the infrastructure needs of the project. Infrastructure
includes compute capacity, storage capacity, and network components. A ballpark
estimate of the resource requirements with an understanding of the low and high
usage marks is helpful in deciding the infrastructure services. If an organization
chooses multiple numbers of smaller compute nodes, it will be necessary to make sure
that the workload can scale horizontally.

2-8 Building Cloud Services


Cloud Service Identification

The requirements also drive the type and size of the storage service. To determine the
best suitable storage service, it is essential to understand the nature of the workload.
The design of the storage service is influenced by factors such as:
Is the data mostly read-only or read-write?
Is data access "chatty" (small chunks of data accessed frequently) or is it large
amounts of data accessed infrequently?
Performance requirements for data access that may further drive the physical
characteristics of the storage technology
Monitoring and management needs
Network components such as load balancers and routers also need to be considered.
Security requirements drive the need for one or more firewalls in the architecture for
example (Cloud security is covered in more detail in the document Enterprise Strategy
for Cloud Security). Network components are typically shared across multiple Cloud
services and multi-tenancy is a key consideration when identifying such services.

2.3.2.5 Extension services


Consumers of Cloud services often find a need to customize the functionality offered
by the service. Since Cloud services are typically shared across multiple tenants,
providers are restrained from allowing the consumers to modify them; instead they
allow the consumers to extend them with additional services in the layers below. For
example, a SaaS service provider may offer a platform Cloud service so that the
consumer could extend the functionality of the SaaS offering.
The ITSO Cloud Foundation document describes the layering of Cloud services. It also
explains that it is not required to build a Cloud service on top of a lower layer Cloud
service. For example, it is not required to build a Platform service on an Infrastructure
service.

2.3.2.6 Capacity Planning


Once the Cloud service candidates are identified, they need to be sized to ensure that
they can operate within the model for scaling the Cloud. Ideally the services should
scale linearly as more resource is made available to them. If not, their constraints must
be clearly understood. Capacity planning should take into account the peak load and
future growth requirements of all projects using the service. Capacity planning for
Cloud is a very detailed topic in itself and is not covered in this document. What's
important to understand is that capacity planning must be performed as part of the
Cloud method to ensure that the resources are sized appropriately. For infrastructure
services, it must be ensured that there are sufficient compute resources available to
handle current requirements and future growth. For platform services, in addition to
ensuring that sufficient compute capacity is available, the design must allow for
horizontal scale out and scale back.

2.3.2.7 Development Cloud


Development platform is another area where there is a great opportunity to utilize
Cloud services. Many organizations use a type of hybrid Cloud in which application
development is performed on Cloud platforms and infrastructure, even if production
is not. Since most organizations standardize their development technologies, it is a
good idea to make the development platform available as a Cloud service for quick
deployment of the development environment. If development will be done on a
platform Cloud service, the needs are identified in this step.

Program Level Activities Overview 2-9


Cloud Service Identification

2.3.2.8 Cloud candidate services stack


A useful exercise is to build a Cloud candidate services stack model by identifying the
Infrastructure and Platform services needed to support the applications and the
dependencies between them. Figure 26 shows a conceptual view of the Cloud
candidate services stack model.

Figure 26 Cloud Candidate Services Stack Model

An example of the Cloud candidate services stack is shown in Figure 27. It illustrates
that the JMS and Java platform services are running on a 2CPU/16GB RAM compute
service while the database service is running on a dedicated Exadata node. The red
arrows illustrate the request flow across these services.

2-10 Building Cloud Services


Cloud Service Identification

Figure 27 Cloud Candidate Services Stack Example

This model serves multiple purposes. It shows how the services (or service candidates)
are stacked up and the dependencies between them. It also shows which services are
built on other services and which ones are extension services. Finally, it can be used to
identify new services, existing services, and modified services.

2.3.2.9 Defining the service boundaries


The service candidates identified can now be reviewed further to define or refine the
service boundaries. It is necessary to fully define a services boundaries to ensure that
it is a fully encapsulated, autonomous unit that does not have unnecessary
dependencies on other entities. The following list captures some of the considerations
for defining service boundaries.
Does the service candidate need to be redefined into two or more services based
on architecture constraints or performance benefits?
Should the service be deployed on a dedicated hardware or a compute service?
For example, Oracle WebLogic service may be deployed on an Exalogic
engineered system or a generic compute node. If WebLogic is deployed on a
generic compute node, then the service will be split into a WebLogic platform
service (PaaS) and a compute infrastructure service (IaaS); conversely, when
deployed with dedicated hardware the combined single PaaS service may provide
greater scalability and performance.
Is it necessary to combine two or more service candidates into one for
performance, security, or deployment reasons?
Should we impose any restrictions on the service candidate for security or
scalability reasons?
Is the service candidate based on the principles defined by the reference
architecture and governance framework?
What are the principles governing the Cloud strategy? Does the enterprise favor
public SaaS services over building the services in house? Does the enterprise build
SaaS over PaaS or over dedicated platforms?
Is there a difference in approach between core strategic functions and commodity
support functions?

Program Level Activities Overview 2-11


Cloud Service Identification

How will the service support multi-tenancy? In the extreme case of Public SaaS,
the mechanism for providing isolation between services (and tenants) is of critical
importance.

2.3.2.10 Determining the sourcing model


After identifying application components, the appropriate sourcing model should be
determined. Sourcing model determines how the services are selected to match the
requirements in hand. The requirements are validated against the following:
Deployment Guiding Principles state the preference of deployment model. Some
organizations prefer public Cloud services while some discourage the use of them.
These policies affect how the services are eventually sourced.
Enterprise standards narrow it down to selected group of services. Technology
standards drive the vendor and technology selections.
A Private Cloud Services Catalog maintains the list of Cloud services developed
and operated internally. These services may be operational or in development.
A Public Cloud Services Catalog maintains the list of approved public Cloud
services that are brokered by IT or available for direct consumption. If the
requirements are available as a third party commodity service offered by a public
Cloud provider, it could be acquired as a subscription based service.
The requirements are checked for a match in the private and public Cloud service
catalogs. These requirements may fall into one of the following categories.
Full Match - the requirements are matched to an existing Cloud service within the
enterprise or in the public domain
No Match - the requirements do not match with any existing services in the
catalogs. A new Cloud service needs to be built in this case.
Partial Match - Part of the requirements are matched to an existing service or part
of the service matches the requirements. In this case an existing Cloud service has
been discovered but it requires modifications before it could be used for this
project. In some cases, the existing service could be used as part of a new
composite service without modifications.
The Oracle Cloud Candidate Selection Tool (CCST) assists with the process of
identifying the deployment model for specific components. It takes into account
several factors including architectural characteristics and affinity between services and
highlights the best fit deployment model for application components.
CCST is used to evaluate the architectural characteristics of components to determine a
suitable deployment model.
One of the critical evaluation metrics in deciding the deployment model is data
sensitivity. This applies to consideration of external deployment models, but also
applies to internal enterprise Clouds which often utilize a multi-zone security model.
For example, critically sensitive data may have a requirement to be hosted in the
'Restricted' security zone, which affects infrastructure and platform.

2.3.2.11 Service justification


The Cloud service repository plays a key role in discovering existing Cloud services
based on the need of the project in question. If the chosen deployment model is Public,
then public Cloud services from multiple vendors are compared to determine the best
fit for the project requirements.

2-12 Building Cloud Services


Cloud Service Portfolio Management and Release Planning

New Cloud services or modifications to the existing services need to be justified before
taken up for delivery by the Cloud service creation team. Resource constraints,
architecture constraints, and economic rationale are some of the factors influencing
this justification. If the Cloud service creation team decides not to build the Cloud
service, it is passed back to the project team for localized implementation.
If the discovered service requires modifications, an impact analysis should be
performed to assess how the change will affect the existing consumers. A well-defined
versioning approach is required to ensure that the new version is fully functional and
the old versions are phased out. Service versioning is also essential to isolating and
tracking modifications, and facilitating roll back to older versions.

2.3.2.12 Workload validation


The final step in the identification process is to identify the various types of workloads
to be supported and ensure that the service can support the workload requirements.
Following are some example workload characteristics that need to be considered in
service validation.
Batch processing workload that is going to be run at specific times of the day.
Transaction processing workload
Business continuity workload that is active only when the primary site goes down
Burst workload that is created as a result of peak load distribution
Development or test workload that is non-critical
Production workload that is mission-critical or business-critical
The examples of questions to ask about workload are as follows:
Is the workload permanent or transient?
Is it a batch program or OLTP application?
Is the workload going to have sudden spikes?
What business processes are run on the workload? This is important to identify
the business unit, criticality etc. of the workload.
Who has organizational ownership of the workload? This is important because
often cloud adoption is driven within organizations by a 'champion' - so can
directly affect the cloud service identification process.
Are there any constraints or restrictions on the workload? The service may not
support some of the features of the underlying service platform. For example, a
Java service provider may exclude the use of RMI and thread management.
What are the costs and charging models for different workload profiles?

2.4 Cloud Service Portfolio Management and Release Planning


Figure 28 shows the high level steps in Cloud Service Portfolio Management and
Release Planning. Cloud services and their dependencies should be maintained in a
catalog so that they can be discovered. The catalog also assists in synchronizing
projects release schedules and Cloud service delivery schedules.

Program Level Activities Overview 2-13


Cloud Architecture Refinement

Figure 28 Cloud Service Portfolio Management and Release Planning

Cloud projects often suffer the dilemma of whether to create the services first and wait
for the business units to start using them or build Cloud services as the need arises in
the first project. Cloud release planning ensures that services are planned and
developed in support of evolving business requirements.
Cloud service metadata should be managed in an enterprise asset management tool
such as an Enterprise Metadata Repository with associated dependencies. This goes a
long way in ensuring that services are planned in line with the demand and the project
teams utilize the services for effective cost control and maximal agility. A taxonomy to
describe Cloud services may include metadata elements such as:
Projects using the Cloud service
Lifecycle environments the Cloud service is deployed on (e.g. Dev, Test, Prod)
Business units using the Cloud service
Cloud service template associated with the service
Assembly or topology
Another aspect of Service Release Planning is to prioritize the service development
based on available resources.
Not all services identified by the Service Release Planning process are built in-house.
IT may decide to broker some of the services from a public Cloud provider based on
cost and time-to-deploy factors.
Service creation and project delivery need to be synchronized such that Cloud services
are ready and available for consumption when the business projects need them.
Sometimes a private Cloud would have the necessary infrastructure built already;
hence the deployment of Cloud services would be fast. However, there may be
instances where a service that doesn't currently exist is just identified for the needs of a
particular project.

2.5 Cloud Architecture Refinement


The Cloud architecture refinement activity assumes a reference architecture has
already been developed and provides means to maintain and evolve it. The scope of
the architecture is a definition of Cloud for the enterprise, including guidelines and
principles for all service tiers. As new Cloud service projects arise, new architectural

2-14 Building Cloud Services


Cloud Architecture Refinement

requirements are likely to emerge, but since these affect the enterprise architecture for
Cloud they must be considered at the enterprise level.

Figure 29 Cloud Architecture Refinement

Figure 29 depicts a simple sequence of steps in the architecture refinement activity. In


addition the existing reference architecture, inputs include the proposed changes from
the project and the application portfolio (in order to consider the impact of proposed
changes). If a change is adopted a refined reference architecture is produced. This may
also involve new infrastructure requirements to support the architectural change.
Some of the key considerations for Cloud architecture are explained in the following
sections.

2.5.1 Cloud Services and SOA


Organizations that are already adept at Service Oriented Architecture (SOA) will find
it easier to adapt to Cloud architecture and practices since SOA and Cloud rely on
similar principles and require many of the same disciplines.
Monolithic applications are difficult to integrate with other applications, constrain
scalability, and are inflexible when functionality needs to be changed. When
application functions are modularized, as they are in the case of SOA these concerns
are much more easily addressed. In a cloud environment many of the principles of
Service Oriented Architecture apply equally to Infrastructure and Platform services as
they do to SaaS.
SOA characteristics (and architectural principles) are as follows:
isolation (loosely coupled)
autonomy (atomicity, self-contained)
robustness/durability (not so relevant in cloud)
abstraction (getting the right granularity)
discoverable - yes but don't do it with centralized configuration management
reusable (infrastructure for example becomes more readily reusable when services
are standardized - unlike traditional data center finding leftover servers unsuitable
for the next project)
composable, modular, inter-operable
Al the about characteristics should be considered when creating or refining the
architecture for Cloud services.

Program Level Activities Overview 2-15


Cloud Architecture Refinement

2.5.2 Providers and Consumers


Enterprises are typically both consumers (public Cloud services directly consumed by
business or brokered by IT) and providers (private Cloud services built and operated
by IT). This scenario is slightly different from a Commercial Cloud Service Provider
(CCSP) as these are exclusively service providers that determine commercial Cloud
services needs based on the market drivers and their own business strategy.
This document focuses primarily on the service provider, rather than the consumer,
since service implementation details should not be visible to a consumer: the only
consumer considerations relevant to this document are concerned with what the
service should look like to a consumer, collecting and delivering functional and
nonfunctional requirements, and User Acceptance Testing (UAT).
The term "consumer" also encompasses a number of different roles. Unlike the case of
Infrastructure and Platform services where the consumer is another IT layer, the
application (SaaS) consumer is typically the end user (this is not always the case
however, since software services may be brokered or merely providing support to
other software systems).
Another consideration specific to SaaS is whether the service provider is developing
(or converting) in-house applications in a private cloud model or a commercial service
provider (SaaS equivalent of an ASP) is developing services for a broader range of
consumers. In general this should not make great deal of difference to the method for
building services, however, it does typically have some significance in the approach to
gathering requirements, a greater need for isolation, more attention to location and
regulatory differences, a greater emphasis on scale and, of course, charging
mechanisms. In reality none of these are unique to commercial providers and while
perhaps initially less important to in-house SaaS builders these concerns should be
addressed by all providers. In particular governance, security, monitoring and
measurement should never be afterthoughts. Ultimately the only differences should lie
in the nuances such as the order in which things happen, for example, an in-house
development team is given service level requirements directly from the business,
whereas a commercial provider publishes a standard service level agreement (or menu
of agreements) which the consumer can choose to accept or decline, but typically with
little scope for negotiation.

2.5.3 Architectural Capabilities


The following is a list of examples of architectural capabilities that may be required, in
varying degrees, to be consumed (typically by SaaS applications) or provided
(typically by IaaS and PaaS).
Abstraction, Automation, Self-Service, Visibility, Transparency
Reliability, Availability, Scalability, Performance (RASP)
Transactions: ACID, 2PC, BASE
Identity and Access Management: centralized, distributed, synchronized,
federated, or brokered
Guidance must be provided at a high level, potentially with options for selecting
options from within these categories to enable decisions to be made at project level.
For example, a credit card processing application may require the highest level of
transaction support, while a customer survey application does not need to incur the
overhead and complexity of Two-Phase-Commit (2PC).

2-16 Building Cloud Services


An Example

2.6 Other Program Level Considerations


The following topics are out of scope for the purposes of this document. However, it is
important to consider these subjects in the context of the service development method.
IT demand management - how IT demand is managed and channeled into the
Cloud service development process.
Funding model - how Cloud service development and operations will be funded.
Is funding coming from the central budget or is it based on a cost allocation
model?
Architecture development methodology - how enterprise architecture is
developed at the enterprise and how it influences Cloud service development.
More broadly how an Enterprise Architecture framework would be used in
concert with the Cloud service development method.
Application migration - migration of existing applications to the Cloud services
being built.
IT portfolio management - management of the portfolio of Cloud services in the
broader context of IT portfolio management.
Cloud Governance - Gates and check points in the process, definition of roles and
responsibilities (typically by means of a RACI chart or something similar), policy
exceptions and escalations, Cloud migration policies and guidelines.

2.7 An Example
This section shows a simplified example of Cloud service identification.

2.7.1 Problem
ABC Bank is expanding into new markets and is introducing an options trading
product. ABC Bank is already offering customers equity and Forex trading. Quotes
must be provided really fast with less than 50ms delay. This low latency requirement is
consistent across all three business lines (Equity, Forex, and Options/Derivatives). The
business units have also dictated that the application must be up 99.999% on trading
days and the system should be able to accommodate additional load seamlessly as the
quote volume varies widely. ABC Bank has presence in over 20 countries and different
regions use the platform at different times. The traders of the bank use remote trading
desks.
A number of smaller banks have also contacted ABC Bank in the recent months to ask
if they could use the quoting engine platform for their customers. The management
has taken a strategic decision to run their IT as a business and offer the quotes engine
as a Service to the external consumers.
ABC Bank is investigating whether Cloud is the right deployment option and if so,
how the Cloud services can be identified.

2.7.2 Solution
As part of a multi-year initiative, ABC Bank had started building a private Cloud two
years ago. IT had built the necessary Cloud management infrastructure and a few
Cloud services over the last two years. The private Cloud embodies all essential
characteristics of Cloud, including self-service, elasticity, broad network access,
measurement, and resource pooling. The elasticity and resource pooling are important
because the different regions use the platform at different times, the broad network

Program Level Activities Overview 2-17


An Example

access is important for remote trading desks, the measurement and monitoring is
important for checking the QoS.
ABC Bank's IT has determined that one of the key components of the architecture is
the Quotes Engine that provides option quotes. This component is the same as the one
used in the equity and Forex trading applications. IT has also determined that this
functionality can be offered as a service to external consumers based on the
requirements they have received from the smaller bank partners.
The architecture team determines that these requirements can be fulfilled by a
Complex Event Processing (CEP) product deployed on a hardware that supports low
latency and high availability requirements. The architecture team has established
middleware standards. Oracle Event Processing (OEP) has been standardized as the
preferred platform for Event Driven Architecture.
Based on the initial requirements analysis the project team identifies one SaaS
candidate and two PaaS candidates and passes the requirements on to the Cloud
service creation team.
The functional requirements did not have a match with existing services, so a new
Quotes Engine service needs to be built. This new service should support the internal
customers, the three business units and the external customers, the small banks.
Based on the non-functional requirements of the project the architecture team
identifies OEP as a service candidate. The availability and low latency requirements
also drive the need for a high performance database as a service.
The Cloud service creation team further analyzes the requirements and identifies an
OEP service and an Oracle NoSQL database as a service. Further boundary analysis
suggests that OEP deployed on Oracle Exalogic can better satisfy the business
requirements.
The Cloud service creation team also determines that the Oracle NoSQL database can
be deployed on an existing Infrastructure cloud service without any modifications.
Since there is significant reuse of the OEP platform service and Oracle NoSQL
database service, these services are easily justified and accepted by the service creation
team.
The service creation team also evaluates the workload requirements and ensures that
the service can handle the load patterns.

2-18 Building Cloud Services


3
Inception
3

In traditional software engineering methods, Inception is largely concerned with


establishing a cohesive team and validating the requirements, identifying risks, scope,
and cost of the project. As with the rest of the document, this chapter focuses on
elements of the process that are specific to building Cloud services. The goals of the
Inception phase directly relevant to building Could services are:
analyze Cloud service project requirements
confirm business objectives
identify Cloud specific requirements
define the scope and boundary conditions
As with traditional software engineering, Cloud service development also begins with
requirements. However, Infrastructure and Platform service development differs from
traditional engineering in a couple of ways. In most cases, Cloud services are
enterprise scoped and shared by multiple IT projects within the enterprise, which
means that the method should support identification of common requirements and
isolating or refining them into enterprise requirements that can further be built as
Cloud services. In addition, the Infrastructure and Platform services are more
appropriate to be developed by the operations team or "DevOps team" as opposed to
the development teams in the case of Software. On the other hand, Cloud applications
service development has many similarities to traditional software development, but
SaaS specific concerns are also identified in the following sections.

3.1 Inception Phase Activities


Figure 31 shows the high level activities of the Inception phase. Cloud benefits arise
largely from the economies of scale and velocity, and migration to a Cloud service
model is an investment that provides increasing returns as more services are
deployed, just as in the case of SOA. The majority of service requirements will have
been identified already based on common requirements across multiple in-flight
projects and/or based on existing portfolio capabilities.
The inception activities are only slightly different for Software services v.
Infrastructure or Platform services when view from a high level.
In the case of SaaS, application requirements are analyzed to separately identify
functional requirements and application architectural requirements. Traditional
software engineering methods refer to functional and non-functional requirements,
however, the term "non-functional requirements" is no longer sufficient to encompass
our needs in the Cloud environment (furthermore, the distinction, functional v.
non-functional, leads to great confusion resulting from inconsistent definitions across
service tiers). While the functional requirements for the application, and the process of

Inception 3-1
Inception Phase Activities

gathering and validating them, is no different from traditional software development


practices, the application architectural requirements become much more significant in
a Cloud environment. The application architecture must specify the capabilities
expected from the underlying platform and infrastructure (regardless of whether they
are provided as-a-service or by traditional means) and determine whether or not
sufficient support exists.

Figure 31 Inception Phase Activities (SaaS)

Figure 31 shows the two primary inputs to this phase for SaaS: the application
requirements and the Cloud service capabilities available from the Cloud architecture.
The process shows the requirements being split into traditional "functional"
requirements and the application architecture specification that determines the
capabilities required from the underlying Platform and Infrastructure.
Some examples of architectural capabilities were given in Section 2.5.3 and these are
the types of capabilities that must be matched to the application requirements.
The outputs from this phase are (1) traditional use cases and (2) Cloud specific
application architecture.

Figure 32 Inception Phase Activities (IaaS and PaaS)

A number of differences arise in the Inception phase for Infrastructure and Platform
services. These are shown in Figure 32. The primary input to this activity is the
requirement for either a Platform or Infrastructure service. While most of these
requirements should be established at the program level from an analysis of the
application portfolio for architectural requirements, these may also arise from
additional discoveries during the inception phase of SaaS projects. New requirements
arising from application projects in this way must be considered at the program level
with a number of possible outcomes, including (1) the Cloud service project fails
feasibility checks, (2) an alternative architectural strategy is proposed by EA, (3) a new
Infrastructure and Platform service project is identified to fill the gap.
The outputs for this phase are (1) technical architecture describing the required
capabilities of the service, its APIs, etc. and (2) use cases describing how the service
should be used.

3-2 Building Cloud Services


4
Elaboration
4

Elaboration phase of Cloud service development includes definition and design


activities as shown in Figure 41. A key input to this phase is the Cloud reference
architecture. The output from the Inception phase forms the input for the Elaboration
phase.

Figure 41 Elaboration Phase Activities

4.1 Cloud Service Definition


The next step in the process is to define the Cloud service identified in Section 2.3,
"Cloud Service Identification" and further validated in the Inception phase in
Chapter 3. Figure 42 outlines the activities in the Cloud definition step of the process.

Elaboration 4-1
Cloud Service Definition

Figure 42 Cloud Service Definition

4.1.1 Defining Cloud Service Contracts


Contracts define what the service offers and the SLA for the service from the
consumer's view point. It is the business definition of the Cloud service that is likely to
appear in the consumer-facing service catalog. Contracts are the agreements between
the consumer and provider. Service providers typically provide a master contract that
covers the terms between the provider and all the consumers of the service.
Even for private Clouds, contracts should be defined between the IT department and
users (business or IT) of Cloud services. Commercial Cloud service providers must
define the internal Quality of Service (QoS) requirements to meet the SLAs published
to the consumers.
A Cloud service contract must also indicate how consumer's data and assets will be
protected and what happens to the data when the consumer terminates the
subscription.

4.1.2 Defining Service APIs


APIs are an important component of Cloud services. For Infrastructure and Platform
Cloud services, APIs specify how the service will be provisioned, managed, and
accessed.
As IT deployments are becoming more complex, an abstraction of the infrastructure
resources become more relevant to address concerns of compliance and configuration.
Furthermore, such abstractions enable consumers to both self serve and to
operationally control these services without any significant administrator
involvement.
API specification is a key part of both Cloud services across all service tiers. APIs are
made available for the consumers to interact with the Cloud provider. Although there
are no dominant standards at this point, providers must make their best effort to
create and support standards based APIs for the management of infrastructure and
platform.

4.1.2.1 Characteristics of good Cloud APIs


The following list captures the characteristics of good Cloud APIs
Minimalistic design
Simple but complete

4-2 Building Cloud Services


Cloud Service Definition

Standards support
Good documentation
Abstract
Encapsulate multiple Cloud resource management tasks into one

4.1.2.2 IaaS API


An IaaS API enables an infrastructure provider to service their customers by allowing
them to
Browse templates that contain definitions and metadata of a logical unit of service
Deploy a template into the cloud and form an IT topology on demand
Perform operations on the resources
Take backups of the resources
The specification of an IaaS Cloud API should include:
Common behaviors that apply across all requests and responses, error messages,
common resource attributes
Resource models, which describe the data structures used in requests and
responses
The requests that may be sent to cloud resources, and the responses expected.
Which communication protocols to support, e.g., REST, SOAP, WS-*

4.1.2.3 PaaS API


PaaS APIs are required to manage the building, running, administration, monitoring
and patching of applications in the cloud. Figure 43 shows PaaS consumers managing
their PaaS instances using the self service PaaS APIs. The platform implementation is
responsible for translating the API request and orchestrating the underlying resources.

Elaboration 4-3
Cloud Service Definition

Figure 43 PaaS API

The following is a non-exhaustive list of common PaaS use cases which PaaS providers
may choose to support. These are application oriented use cases that assume an entire
application is deployed to the platform. This may not be the case, where the platform
is just a queuing service or data warehouse service, for example.
Building and packaging an application in a local development environment
Building an application in a development environment running in the cloud
Importing a platform deployable entity into the cloud
Uploading application artifacts into the cloud
Run, stop, suspend, snapshot, and patch an application instance
While patching an application instance is mentioned here, it is noteworthy that
patching is at odds with the a common Cloud principle of application versioning and
simple migration between older or newer versions: you do not patch in place in this
model as it makes it significantly more difficult to test, recover, etc.
A standardized PaaS management API has the following benefits from the consumer
point of view.
Portability - By standardizing the management API for the use cases around
deploying, stopping, starting, and updating applications, the standardized API
increases consumers' ability to port their applications between PaaS offerings.
Popular development environments could use the APIs to create plug-ins. Over
time, such generic implementations are likely to be of higher quality than the

4-4 Building Cloud Services


Cloud Service Definition

implementations written for solitary, proprietary application management


interfaces.
For PaaS providers a standardized management API would bring the following
benefits:
Because the strength and features of a PaaS offering's application management
API are unlikely to be perceived as key differentiators from other PaaS offerings,
the existence of a standardized management API allows providers to leverage the
experience and insight of the specification's contributors and invest their design
resources in other, more valuable areas.
By increasing the portability of applications between PaaS offerings, the
management API helps "grow the pie" of the PaaS marketplace by addressing one
of the key pain points for PaaS consumers.
Ultimately, there may exist both provider APIs and consumer APIs. Further examples
of provider APIs might enable the provider to move resources around their
infrastructure, change resource priorities, increase or decrease capacity/capability.

4.1.2.4 SaaS API


When developing SaaS applications, API considerations focus on two main areas of
concern: interfacing with management systems and integration between applications.
Many of the management systems considerations for SaaS have been mentioned in the
foregoing PaaS discussion (packaging, deployment, start/stop, etc.). More unique to
SaaS is the need for integration between applications and in a Cloud environment
where the need for standardized API for this purpose becomes more important than
ever before. This is because Cloud application services are more likely to be highly
distributed and even hosted by separate providers, all demanding greater isolation.
Figure 44 depicts these application integration considerations for SaaS.

Figure 44 Cloud Application Integration

The need to eliminate point-to-point integrations between applications was


established well before the emergence of Cloud (refer to Service Oriented Architecture
in ITSO). Under a Cloud model however, much more formal interactions between
architectural layers (and service tiers) must be defined. A suitable architectural
strategy forces application interactions through orchestration and mediation
capabilities provided by the Platform layer. This is not only required for interaction
between applications within an enterprise, but must also ensure secure, effective
integration with externally provided SaaS applications.

Elaboration 4-5
Cloud Service Definition

4.1.3 Defining service specifications


The service specification referred to in this step is a technical definition of the Cloud
service which typically includes the technology attributes. The following are the key
service definition activities.
Boundary analysis - identify the Cloud service boundaries by analyzing various
influencing conditions against the Cloud service Candidate. Factors such as
service scope, security policies, and QoS requirements may affect service
boundaries.
Identify IaaS, PaaS, and SaaS services - break down services if necessary
Define the SLA for the service
Define the security aspects
Size the service
E.g. Compute - CPU size/RAM size, # of CPUs
E.g. Storage - storage capacity, mirroring etc.
Platform - # of platform instances or cluster size, memory/heap size
Define HA and elasticity requirements
Define any self service interfaces
User Interface specifications (primarily for SaaS, but some UIs are also necessary
for PaaS and IaaS)
In addition to the technical specifications, functional specifications will also be
necessary for SaaS.

4.1.3.1 Template for Cloud service definition


A sample template for capturing the Cloud service definition is provided below.

Cloud Service Name Name of the Cloud service


Type of Service e.g. IaaS/PaaS/SaaS
Sub-Type of Service e.g. Compute/Storage/Java/DB/Queue
Description <define what the service is intended to do>
Deployment Model Public/private/hybrid
Dependencies <list the service dependencies>
Elasticity How the service capacity is managed based
on demand variations?
Security Security provisions and compliance
statements
Workload Define what workload is supported by this
characteristics service
Metrics Define the metrics used to measure this
service
(e.g. CPU utilization, bandwidth, space used
etc.)
Sizing Service sizing using the service-specific
parameters

4-6 Building Cloud Services


Cloud Service Definition

Access Method How the service will be accessed? Routing


information and load balancing
Isolation Define isolation strategy - data level,
container level, application level, process
level etc.
Multi-tenancy How would this service handle multiple
consumers? What level of multi-tenancy will
be used?
Resource Pool Describe the underlying resource pool (e.g.
virtualized infrastructure hosting VM's, a
large VM hosing multiple Weblogic JVM's, a
Database hosting multiple schemas)
Service Class/Tiers These are typically the operational
characteristics (e.g. backup frequency,
retention period, etc.) or service quality
metrics (e.g. overprovisoining ratio) that
form SLA's and are wrapped up into
business language (e.g. Gold, Silver, Bronze)
Deployment Zones This is a logical concept but can represent
business units, data centers, infrastructure
pods, security zones, etc. (configurable to the
enterprise within the management tooling)
Unit of provision What is the consumer getting when this
service is turned on? (e.g. a VM with OS
pre-installed, a Weblogic JVM, a Database
schema)
Provisioning How is this service provisioned? What level
of automation will be implemented?
Subscription What's the best way to monetize this service?
What subscription model is best suited?
(business may choose to use a different
model but this is the builder perspective of
the subscription model)
Monitoring and How is this service going to be monitored?
diagnostics What kind of instrumentation and
diagnostics will be provided?
Scaling How is this service going to be scaled?
Horizontal or vertical? Does the architecture
support automation to provide elastic
scaling capabilities?
Language support What localized languages will be supported?

4.1.3.2 Defining Service metrics


One of the essential characteristics of Cloud services is the ability to be measurable.
Service definitions should identify which metrics will be used to measure the cost as
well as the usage of the service. Metrics may be simple or composite, but composite
will be typical for most services. This section presents some sample metrics for IaaS
and PaaS.

4.1.3.2.1 IaaS Metrics


IaaS services are specified broadly based on the fundamental resources such as
compute capacity and storage capacity
CPU - CPU utilization %

Elaboration 4-7
Designing Cloud services

CPU - configured CPU Count #


Memory Usage GB
Memory - configured Memory GB
Storage Disk space GB
Bandwidth Mbps
Other Costs System Count
Facility Base Facility charge $$
Facility Base Utility Charge $$
HA multiplier Times X

4.1.3.2.2 PaaS Metrics


DB Usage
DML Operations, DB Connections, Data transfer characteristics
DML Statements, Average/Max DB, pool Size, GB
DDL requirements
Deployed Entities
# of .ear, # of services
Number of Deployed Apps, Exposed Services
Service Consumption - Service Invocations, # of invocations
Usage Cost - Transaction Cost, # of transactions

4.1.3.2.3 SaaS Metrics


Number of users
Service Consumption - business metrics based on the functions performed by the
application
Usage Cost - based on business functions of the application
Additional operational metrics common across the service models include service
availability (vs. SLA), number of dropped operations (i.e. transactions, packets, etc.),
number of open security findings, average time it took to close security findings or
recovery from an outage, overall SLA compliance, etc.

4.2 Designing Cloud services


Cloud service design should include detailed static and dynamic behavior models that
show how the services are provisioned, managed, and self-serviced. Figure 45 shows
the key activities in Cloud service design.

4-8 Building Cloud Services


Designing Cloud services

Figure 45 Cloud Service Design

For all Cloud services, service templates are created from reference configurations. In
the case of Infrastructure or Platform services, assembly templates are instantiated to
create deployable entities. SaaS templates for service instantiation may not involve
deployable entities, but may simply identify the elements needed to describe the
consumers configuration. This could be as little as configuration data in a database.
APIs and service integration components are designed next. Some Cloud services need
workflows that are specific to those services. These service specific workflows are to be
designed as well. In a Test Driven Development (TDD) environment, test cases and
test scripts are also created during the Elaboration phase.

4.2.1 Design Choices


Cloud service design needs to consider several design choices and some of them are
listed below.
If IT is going to build the service, what will be procured and what will be custom
developed? Guiding principles around Buy vs. Build vs. Lease need to be
developed.
Service model choices may change during the design process. For example,
detailed design may identify the need for additional cloud services that were not
previously anticipated. In such a case it may be necessary to reconsider and
application development in favor of a SaaS from an external provider, for
example.
Multi-tenancy is another key consideration. How does the design support multiple
consumers? For example, in the case of a DBaaS, how is multi-tenancy handled? Is
data isolation handled at the database level, schema level, table level, or row level?
Security considerations - Is security infrastructure shared across multiple
consumers and multiple service types (e.g. SaaS and PaaS)? How will the security
identity domains be designed? Will the internal operators and administrators get
their own identity domain?
How is the service going to be packaged and deployed? Can the packaging
approach support the scale, velocity, and elasticity requirements of the Cloud?

Elaboration 4-9
Designing Cloud services

Scalability - Scale and velocity are two of the key design considerations for Cloud.
How is the service going to be scaled over long term? What are the capacity
requirements? What is the strategy for long term scaling?
High Availability - How do we ensure that the service is highly available? How is
redundancy handled? How are load distribution and failover accomplished?
Elasticity - How is the service going to scale up and scale down as the workload
requirements change? Does the infrastructure support automatic scale up and
down? Does the service design support the elasticity requirements?
Self Service - Does the service design satisfy the self service requirements? How
does it interact with the management infrastructure?
Metering and monitoring - How will the service metrics be collected and pushed
to the Cloud management and monitoring framework? Application service
consumption by the consumer is measured and reported in terms of usage of the
service (rather than consumption of underlying infrastructure metrics such as I/O,
CPU, storage, etc.). Service usage metrics might include, for example, the number
of users using the service, the number of business transactions performed, the
number of employees managed in a HR system, etc.
In the case of SaaS, an important consideration would be integration (both
business process and data). How is this SaaS process/application interoperate
with other enterprise applications? How is the data going to be shared
(considering security and data transformation) and how would this process
integrate with the other in-house business processes?
The location of the equipment can be different from the location of its owner
which in turn may be different from who manages it. For example, a private
Cloud might be located in a building owned by a hosting company providing
services that are managed by someone else.

4.2.2 Service Design Template


This template captures the key elements of the Cloud service design.

Cloud Service Name <name of the Cloud service>


Design Overview <high level overview of the design>
Static behavior <static diagrams of the service - e.g state change>
Dynamic Behavior <dynamic behavior diagrams - e.g. UML activity
diagrams, flow diagrams>
Elasticity Design Design that supports scale up and scale down of
resources
Security Design Security design aspects
Metrics Collection Design of how metrics are collected
Access Design Design details on how the service will be accessed
Isolation design Design details on isolation strategy - data level,
container level, application level, process level etc
Multi-tenancy Supporting multiple tenants/consumers at various
design levels of architecture. This should cover design issues
such as how tenant data will be organized, how security
infrastructure is shared, how the requests from different
tenants are routed, and how the critical components of
architecture are isolated.

4-10 Building Cloud Services


Designing Cloud services

Provisioning design How the services will be provisioned and managed.


Integration design Service integration design details including ecosystem
integration points like DNS, DHCP, monitoring, etc.
Scaling design How the services will be scaled.
HA design High availability and redundancy design.
Declarative Cloud services, particularly SaaS, should be configurable
Configuration via documents external to the code.
Programatic Control Design for programatic control rather than traditional
human operations.
Transaction Control SaaS in particular must specify its needs for transaction
management, consistency, and concurrency.

4.2.3 Service Assembly Template


A Service Assembly Template (SAT) is a collection of interrelated software
components that are automatically configured to work together upon deployment.
They are deployed onto a pool of hardware resources with minimal user input.
From the user's perspective, a SAT represents the definition of a deployable entity.
Users can create cloud resources by specifying a Service Template in a deployment
request. The cloud provider instantiates the resources and their configurations as
specified in the SAT. SAT lists the components of the deployable entity and how they
are packaged.

Elaboration 4-11
Designing Cloud services

4-12 Building Cloud Services


5
Construction
5

Figure 51 shows the high level activities in the Construction phase of Cloud service
development method. These activities are Cloud service implementation, Packaging
and assembly, and Cloud service testing.

Figure 51 Construction Phase Activities

Each of the activities in service construction is elaborated in the following sections.

5.1 Cloud Service Implementation


Figure 52 shows the key activities in Cloud service implementation.

Construction 5-1
Packaging and Assembly

Figure 52 Cloud Service Implementation

Hardware and software installations are usually covered as part of the


infrastructure setup. This step verifies that the necessary hardware and software
resources are installed and configured. If the hardware and software are already in
place the necessary resources may be instantiated from existing resource pools. If
not, they are installed and the necessary resources and resource pools are created.
Provisioning infrastructure is installed and configured. Provisioning infrastructure
is necessary for deploying the service when consumers subscribe to the service.
Verify the network components and configure them if necessary. For example, the
load balancers may need to be configured to route the consumer traffic to the
respective service instances.
Configure security infrastructure and create security identity domains. Create
security entities.
Build integration and functional components. Most services require integration to
databases or other services. SaaS services invariably require coding of business
functional requirements.
Build provisioning workflow components that are specific to the service.
In the case of SaaS the coding of application functionality is also required, but as in the
case of business functional requirements gathering, the Cloud environment should not
change activities. Traditional software engineering strategies still apply and are
therefore not elaborated here.

5.2 Packaging and Assembly


Figure 53 shows the activities in the Packaging and Assembly step.

5-2 Building Cloud Services


Packaging and Assembly

Figure 53 Packaging and Assembly

Assembly templates are created from a reference configuration. The assembly


template is a collection of interrelated software components that are automatically
configured to work together upon deployment. Assemblies (logically called as
deployable entities) are deployed onto a pool of hardware resources with minimal
user input.
The Cloud service catalog is updated with the information about the new Cloud
service.
The Cloud service is deployed in the test environment for testing.

5.2.1 Defining Deployable Entities


The primary goal of the deployment infrastructure is to completely automate the
actions required to deploy the functional components needed for a new service
instance. In order to achieve this automation a virtualization solution is typically used,
in which the service instance of a subscriber is created by deploying a set of
deployable entities that embodies the topology needed. Each service in the Cloud will
require a set of deployment entities that will be used to create each type of instance
needed to provide the service.
A deployable entity is typically a set of virtual machine templates along with a set of
metadata describing the interrelationships between these templates as well as
surrounding IT artifacts such as volumes, Virtual IP addresses (VIPs), Load Balancers
(LBRs), Firewalls, etc. Each deployable entity describes the complete topology for a
service so that a new instance of the service can be brought into being by assembling
the deployable entity for that service.
The deployment Infrastructure relies on a set of pooled IT resources such as a pool of
hardware incorporated into a virtual machine pool and a Network Attached Storage
(NAS) for shared storage.
Deployable entities must provide a set of capabilities in order to be useful in a
production environment, including:
Allow for the composition of components as well as external systems
Externalize configuration in the form of metadata that can easily be customized
Optionally define the start order of components to reflect interdependencies
Provide a management domain which integrates into existing management
infrastructure allowing for metadata definition, deployment, oversight and
diagnostics

Construction 5-3
Cloud Service Testing

The notion of being able to create pre-built templates for deployment is extremely
powerful and has a number of advantages that drive down operational costs and
complexity. These include:
Ability to easily replicate deployable entities in production, even allowing for
variations of the them without adding complexity
Reduced risk of configuration errors as deployable entities are moved between
development, test and production environments
Replicated environments facilitate high-level standardization and consistency
across application infrastructures, allowing for simple implementation of best
practices.
Accelerated deployment of new infrastructures and applications
In order to realize these benefits, a simple means of composing deployable entities of
the components is required. Specifically what is needed is tooling that allows for the
composition of components as well as endpoint mapping of externalized systems and
other larger non-virtual systems such as databases and identity management servers.
Tools that enable introspection of a running system in order to capture a metadata
description of a known good configuration are especially valuable in making the
process of defining deployable entities simple and reliable.

5.3 Cloud Service Testing


Cloud service testing process is illustrated in Figure 54. The goal of this step is to test
the platform and infrastructure Cloud services. This is not to be confused with Cloud
Testing, which refers to the use of Cloud services for software testing. The focus of
Cloud service testing is to test the concerns specific to Cloud enablement.

Figure 54 Cloud Service Testing

Following list captures some of the key tasks involved in Cloud service testing.
Test the provisioning of Cloud services beginning from discovering the service in
the service catalog, ordering, and deployment of the service. Provisioning process
orchestrates several resources behind the scenes and the test cases should cover
validation of each of the resources provisioned.
Test the service usage with test workloads that are similar to the anticipated
consumer workloads.
Test service scalability, elasticity, and fault tolerance to ensure that the service
level agreements can be met.

5-4 Building Cloud Services


Cloud Service Testing

Test multi-tenancy and security of services. This is a key concern for most
consumers and testing these capabilities and publishing the results will provide
the necessary assurance to the consumers.
Test monitoring and management of the Cloud service. This includes both
operational monitoring and self-service monitoring. Test all the self-service
management capabilities made available to the consumers.
Test service termination and cleanup with particular focus on what happens to the
consumer data after service termination.
Regression test the pieces as new services or capabilities are introduced to the
cloud. The cloud will be evolving especially since initially it may not have all the
cloud capabilities because it may take time to set up.
SaaS development will also be accompanied by a list of traditional software
engineering activities related to the application functional testing (business logic), such
as System Integration Testing (SIT), User Acceptance Testing (UAT), etc. Once again,
these activities have been omitted from the diagram because they are unchanged by
the Cloud environment.

Construction 5-5
Cloud Service Testing

5-6 Building Cloud Services


6
Transition
6

The transition activities are a) User Acceptance Testing and b) Cloud Service
Deployment. These high level activities are shown in Figure 61.

Figure 61 Transition Phase Activities

6.1 User Acceptance Testing


The concept of UAT is another transformation triggered by Cloud, although not a
"key" transformation. UAT typically suggests a closed cycle with control over access,
and usually implies structured testing designed to poke at all features in a service and
test data is "throw-away". UAT is still suitable for a private Cloud service, but public
Cloud services frequently rely on an open-beta testing phase. This testing phase
usually comes after functional testing / regression testing, and before revenue release.
It's also a means to determine viability and works best for those applications where the
consumer has a choice to not use the application (this is the "ROI Runway" criteria in
CCST). Figure 62 shows the User Acceptance Test (UAT) activities.

Transition 6-1
Cloud Service Deployment

Figure 62 User Acceptance Testing

UAT, in the traditional sense, is applicable more to the enterprise than a Commercial
Cloud Service Provider (CCSP). A CCSP may allow a trial period during which the
consumer may try the services and provide feedback. The following issues must be
considered with respect to this kind of trial or open-beta testing.
What part of the lifecycle precedes and follows this testing?
What happens to the data? Is it retained and rolled forward to the next phase in
the lifecycle, or thrown away? Or, more generally, are there any service level
objectives, and if so, what are they?
What is the feedback mechanism? Is it active and formal, or passive and informal?
Cloud application builders may test the service to ensure that the applications they
build will run on the Cloud service. Enterprise UAT steps are similar to Testing steps
in the construction phase but are performed by the users of the service.
Test the provisioning of services beginning from discovering the service in the
service catalog and ordering the service.
Test service consumption by provisioning the service and testing its functionality.
Test service scalability, elasticity, and fault tolerance.
Test service multi-tenancy and security.
Test monitoring and management of the Cloud service
Test service termination and cleanup from the user's perspective. The user might
want to test data recovery after termination.

6.2 Cloud Service Deployment


Cloud service is deployed to production next. The activities involved in this
deployment are shown in Figure 63.

6-2 Building Cloud Services


Cloud Service Deployment

Figure 63 Cloud Service Deployment

The deployment activities are listed below.


Deploying the Cloud service is different from provisioning the Cloud service.
Deployment deals with preparing the Cloud service for provisioning, which is
really instantiating the Cloud service for the use of the consumers. One of the first
steps is to deploy the deployable entities to production environment and to ensure
that all the infrastructure and process components of the service are in place. If the
platform services require software infrastructure to build and manage the
workloads, that infrastructure needs to be deployed as well.
Configure the service catalog and publish the service. This requires defining
appropriate taxonomy for the services. The service catalog is integrated with the
order management system to ensure that the latest service information is
displayed to the subscribers.
Perform a final testing of the Cloud service in the production environment.
During the Transition phase, minor revisions or changes to the software system
may cause updates to any or all of the documentation work products.
Ongoing throughout the project, change and communication events targeted to
specific audiences with the goal of mitigating identified risks and challenges are
conducted. In addition, during Transition an IT Alignment is conducted and the
transition plan is implemented.
Continue to conduct user learning events to ensure that the operations and
support staff are trained to perform their duties.
Production go-live event to make the Cloud service available to the consumers.

Transition 6-3
Cloud Service Deployment

6-4 Building Cloud Services


7
Operate
7

Operation is an important aspect of Cloud Computing. For that reason, Operate is a


separate focus area in our method. Operate focus area has a phase called "Operations,
Administration, and Management (OA&M)". Figure 71 shows the key activities in
this phase.

Figure 71 Operate - OA&M Phase Activities

Production Performance Management is an extension of Performance Management


techniques and approaches identified and implemented prior to production
implementation. Performance metrics should be regularly collected and reviewed for
all components. Although the basic strategy may be in place, variations in both
requirements and performance are likely to be encountered. Proactive evaluation of
variations to the baseline will help to identify potential performance issues before the
user community notices the impact.
Ongoing throughout the project, change and communication events targeted to
specific audiences with the goal of mitigating identified risks and challenges are
conducted. In addition, during Production, you conduct an effectiveness assessment to
capture the efficiency of the work done during the project and highlight the change
management work to continue after the Go Live to enable a shorter transition, as well
as the IT Transition Plan prepared during Transition is implemented.
Service management activities such as upgrades and patching are done by updating
the deployment entities and redeploying them as opposed to patching the running
instances. Since the services are shared across multiple consumers, the providers must
develop policies around when the services can be upgraded and how the changes will
be communicated to the consumers.

Operate 7-1
Operations Best Practices

Services must be continually monitored to ensure that the SLAs are met. Any
violations to the SLA must be automatically detected and escalated.
Metrics are constantly collected and passed on to the respective systems for analytics
or billing purposes. The underlying Cloud infrastructure must provide ways of
collecting and conveying the service specific metrics. The principle of charge-back or
at least show-back is a powerful transformational lever in the deployment of a cloud
when the aim is cost reduction. The cloud will constrain consumers because they have
to share these resources with other stakeholders and cost is an important driver to
move them from dedicated kit and applications to a shared platform.
The consumers monitor the service they deploy using the self-service management
capabilities. The provider is responsible for monitoring the platform components on
which the service is running.
Diagnostics and troubleshooting also happens at multiple levels. Consumers have
access to the self-service logs, hence can diagnose any issues related to the payload. If
the issue is in the underlying infrastructure, it is diagnosed by the Cloud provider
operations team or support analyst groups.
Backup and recovery capabilities are essential for any Cloud. Data and other assets
must be backed up periodically and recovered when necessary.
Cloud services may need to be retired at the end of their useful life. Cloud services
may be retired for a variety of reasons such as technology obsolescence, market shift,
changes in business priorities, and migrations. Older versions of Cloud services are
typically retired to make way to new versions of services. In a multi-tenant subscriber
environment, Cloud service retirement should be well planned and the subscribers
must be provided with sufficient notice to migrate to the newer versions if applicable.
Cloud Operations is covered in detail in the ITSO document, "Operating a Cloud".

7.1 Operations Best Practices


Following list captures some of the Cloud operations best practices.
Automated Provisioning - Provisioning must be automated through self-service
capabilities
Patch Management - Applying patches is not done the traditional way with Cloud.
Any upgrades or patches are applied to the service template (deployable unit) and the
service is redeployed.
Self Service Administration - Consumers must be provided with a self-service
administration interface to manage their services.
Self healing - common issues must be automatically detected and systematically fixed
using knowledge management techniques.
Capacity management - Capacity must be proactively managed by taking into account
the current and future demand for services. Additional capacity may be required to
support the spikes in load.

7-2 Building Cloud Services


8
Summary
8

Cloud is quickly becoming a key strategy for business and IT alignment and is starting
to dominate architecture roadmap discussions. Most enterprises have either adopted
or have plans to adopt Cloud as a strategic choice in support of their business and
technology goals. Most Cloud implementations are going to involve some kind of a
hybrid approach where enterprise private Clouds are integrated with either other
private Clouds or public Clouds. Understanding both provider and consumer
perspectives of the Cloud is necessary to successfully implement complex and
highly-scalable Cloud infrastructures that support internal and external needs.
Cloud services are differentiated from traditional IT applications by the scale and
velocity, and the level of automation required. Building successful Cloud services
requires well defined method, extensive planning, and precise execution to ensure that
the services meet and support the business goals.
The Cloud service development process for Application, Infrastructure, and Platform
Cloud services defined in this document is intended to augment the existing
methodologies or to serve as a starting point where no methodologies are currently
being used. This process can be used with a variety of development methodologies
including a flavours of UP and Agile methods. In all cases, primary concerns should
be ensuring Cloud Computing strategies are appropriate to providing expected
benefits and that service development follows a architecture-led, structured approach
for effective and consistent results.

Summary 8-1
8-2 Building Cloud Services
A
AFurther Reading

The IT Strategies From Oracle series contains a number of documents that offer
insight and guidance on many aspects of technology. In particular, the following
Oracle Reference Architecture (ORA) documents may be of interest:
ORA Cloud Foundation - This document presents a conceptual architecture for Cloud,
specifying architectural characteristics and expectations of Cloud at a business and
operational level. Also included are architectural principles, standards, and concepts.
ORA Cloud Infrastructure - This document relates the Cloud characteristics and
requirements, as defined by the conceptual architecture, to the Oracle infrastructure
and provides a number of technical architecture views.
ORA Security - This document describes important aspects of security including
identity, role, and entitlement management; authentication, authorization, and
auditing (AAA); and transport, message, and data security required to secure the
modern IT environment.
ORA SOA Foundation - This document is suggested pre-reading for those wishing to
get a deeper background to the SOA aspect of this document. It presents important
basic concepts of SOA that are instrumental to building applications for a SOA
environment. It covers topics including the components of a service, service layering,
service types, the service model, composite applications, invocation patterns, and
standards that apply to SOA.
ORA SOA Infrastructure - Infrastructure plays a key role in a successful enterprise
SOA environment. The SOA Infrastructure document describes the role of
infrastructure and the capabilities it provides. It offers an array of views to define
infrastructure for SOA, including logical and physical views, as well as technology
and product mapping.

Further Reading A-1


A-2 Building Cloud Services
B
BReferences

IT Strategies from Oracle (ITSO)


http://www.oracle.com/goto/ITStrategies
Oracle Unified Method (OUM) -
http://www.oracle.com/partners/en/products/applications/oracle-u
nified-method/get-started/index.html
Database Consolidation onto Private Clouds, Oracle Whitepaper. By Vengurlekar et al.
ITIL Best Practices with Oracle Enterprise Manager 10g and Oracle PeopleSoft Help
Desk, Oracle Whitepaper, By Sharma, et al.
Billing and Revenue Management for Cloud Computing, Oracle BRM datasheet.
Service Oriented Cloud Computing Infrastructure, The Open Group -
http://www.opengroup.org/projects/soa-soi/
Oracle Cloud Computing, June 2011, Oracle whitepaper, Rex Wang.
Oracle Cloud Resource Model API -
http://www.oracle.com/technetwork/topics/cloud/oracle-cloud-reso
urce-model-api-154279.pdf
Oracle ExaLogic Elastic Cloud - A brief introduction, Oracle Whitepaper, By Piech,
Palmeter, Lehman

References B-1
B-2 Building Cloud Services
Glossary

The following Cloud specific terms and abbreviations are included here for easy
reference. Please see the ORA Master Glossary for other terms used in the various
ORA documents.

CAPEX
A common business term meaning capital expenditure. A capital expenditure occurs
when a business spends money on tangible assets.

COTS
Abbreviation for "commercial, off-the-shelf", referring to t a commercial product as
opposed to a custom built one.

Infrastructure-as-a-Service (IaaS)
A Cloud service model in which consumers deploy and run arbitrary software, and
provisions processing, storage, networks, and other fundamental computing
resources. The IaaS provider manages or controls the underlying physical Cloud
infrastructure (i.e. everything below the operating system layer).

Oracle Unified Method (OUM)


The engineering method used by Oracle and its partners for all Oracle product
implementations. OUM is an Iterative and Incremental Development approach
similar to Unified Process.

OPEX
A common business term meaning operational expenditure. Operational expenditure
refers to the running costs of a business.

Iterative and Incremental Development (IID)


An engineering approach that enables its practitioners to develop a system through
repeated cycles (iterative) and in small portions at a time (incremental).

Unified Process (UP)


A popular Iterative and Incremental Development engineering process.

Software-as-a-Service (SaaS)
A Cloud service model in which consumers use applications in a computing
environment exhibiting Cloud characteristics. A SaaS provider manages or controls
the underlying software and infrastructure regardless of whether it is a traditional
computing environment or some other PaaS/IaaS combination.

Glossary-1
Platform-as-a-Service (PaaS)

Platform-as-a-Service (PaaS)
A Cloud service model in which consumers use programming languages and tools
supported by the provider and then control the deployed application. The PaaS
provider manages or controls the underlying Cloud platform, which includes
everything below the run-time execution environment.

Glossary-2

You might also like