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............2................................1 Cloud Services and SOA..................12 Workload validation ... 2.......... 4-9 4...............................................................................................................................................1 Defining Cloud Service Contracts .....................................................................................................1...........2 Designing Cloud services ................2...... 6-1 6..................................................... 2-17 2....................... 2-16 2..........7 An Example.....................................................4 Cloud Service Portfolio Management and Release Planning ..2 Solution ........................3.......3 Architectural Capabilities....................................................................................1 Design Choices ....................................2 IaaS API.................................................. 5-4 6 Transition 6.......2........4 SaaS API .................................................1...7..................... 4-5 4................................................................2 Cloud Service Deployment.....................2.............5 Cloud Architecture Refinement...................... 3-1 4 Elaboration 4..................... 2-13 2........ 5-1 5.................................................................3 PaaS API........... 6-2 7 Operate 7..............................1.....................................................11 Service justification.................................................................2 Defining Service metrics..... 4-10 4....2 Defining Service APIs ..................................1 Cloud Service Definition..............1..... 4-8 4................. 2-12 2............1........................................1..............................................................................................................1 User Acceptance Testing............................ 2-14 2............................... 4-7 4...................................3 Cloud Service Testing....................... 2-13 2......................................................................................................................................... 2-17 2................................................................ 5-2 5............................2........ 4-11 5 Construction 5...........................1 Defining Deployable Entities .................................... 2-15 2.......................................................................... 4-6 4.........1 Inception Phase Activities............................................................5..........2 Providers and Consumers ... 4-1 4..........2....................................... 7-2 8 Summary iv ........................3 Defining service specifications........................ 4-2 4....................................................................................7.........................................................2.............................. 4-3 4........................................................2.. 5-3 5.............................................................................1..............1 Template for Cloud service definition.............3................ 4-3 4..........3.... 4-6 4...........................................................................2 Service Design Template ...........1 Problem ...... 2-17 2.................. 4-2 4................................................................1 Operations Best Practices....... 2-16 2.............................................1.....................................................................5................................................................1 Characteristics of good Cloud APIs...........................2 Packaging and Assembly.........................................................5.................................................................1...................................1 Cloud Service Implementation ...................6 Other Program Level Considerations ...................... 2-17 3 Inception 3...............................................................2...................................... 4-2 4..........................3...............................................................................................................................................................3 Service Assembly Template .................................................................................

v .

................................................................................................................... 4-2 4–3 PaaS API ................................................................. 6-3 7–1 Operate ...............Programs and Projects................ 5-1 5–2 Cloud Service Implementation ...................................................... 7-1 vi ................................................................................................ 5-3 5–4 Cloud Service Testing........................................................................................................................................................................................................................................................................................................................................ 6-2 6–3 Cloud Service Deployment........................... 1-6 1–2 Focus Areas and Program/Project Scope................................................................................................ 2-6 2–5 Cloud Service Identification Process...................................................................................................................................................... 6-1 6–2 User Acceptance Testing...................................................................................................................................................................................................................................................................................................................................... 2-11 2–8 Cloud Service Portfolio Management and Release Planning ............................................................... 2-14 2–9 Cloud Architecture Refinement....................................................................................................................................................... 3-2 4–1 Elaboration Phase Activities............................ 4-9 5–1 Construction Phase Activities ............................................................................................ 5-2 5–3 Packaging and Assembly............................................................................ 2-15 3–1 Inception Phase Activities (SaaS).................. 3-2 3–2 Inception Phase Activities (IaaS and PaaS) .................................................................... 2-2 2–2 Requirements Analysis ......................................................................................................... 4-1 4–2 Cloud Service Definition............ 5-4 6–1 Transition Phase Activities .... 1-7 1–3 Cloud Service Development Process ......................................................................... 4-4 4–4 Cloud Application Integration...............................................List of Figures 1–1 Cloud Service Development .................................. 2-10 2–7 Cloud Candidate Services Stack Example.............................................................................................................................................................................................................................. 1-8 2–1 Cloud Service Analysis Activities ............................................................. 4-5 4–5 Cloud Service Design .......................................OA&M Phase Activities.................................. 2-7 2–6 Cloud Candidate Services Stack Model................................................ 2-3 2–3 Cloud Service Development Influencing Factors................................. 2-6 2–4 Cloud Service Identification Steps..........................

section.1 E49942-01 Oracle welcomes your comments and suggestions on the quality and usefulness of this publication. Release 3. Send Us Your Comments Building Cloud Services. ■ Did you find any errors? ■ Is the information clearly presented? ■ Do you need more information? If so. and page number (if available). 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. You can send comments to us at: its_feedback_ww_grp@oracle. Your input is an important part of the information used for revision. vii .com. please indicate the title and part number of the documentation and the chapter.

viii .

software at the lower levels of the IT stack. referring most of the time at least. 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. the term "SaaS" narrows the use of the word "software". this category of software will be referred to interchangeably as either "SaaS" or "application services" for the purposes of this document. from Software-as-a-Service (SaaS). however. customer relationship management (CRM). This document is part of a series of documents that describe IT Strategies from Oracle (ITSO) Cloud strategy. Since SaaS generally refers to application software at the top of the IT stack. The word "software". ORA addresses the building of a modern. ix . and a plethora of custom applications. would typically belong to other cloud models. Typically. Document Purpose This document describes a methodological approach to building Cloud services spanning all the Cloud service models. 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 is an extensible reference architecture that describes many facets of IT. operating system software belongs to IaaS while middleware software falls into the category of PaaS. For example. in the context of cloud. In this way other technology strategies that follow ORA remain fully consistent and compatible with the resulting Cloud architecture. however. ORA does not include any implementation artifacts for the prescribed architecture. enterprise resource planning (ERP). in the context of SaaS. human capital management (HCM). Such business applications commonly include financial accounting software. Rather. to a Cloud based delivery model for business applications. through Platform-as-a-Service (PaaS). Please consult the ITSO web site for documents pertaining to Cloud and other technology strategies. is a particularly broad term covering a wide range of categories of machine instructions spanning the layers of the traditional IT architecture stack. consistent IT architecture while minimizing the risk of product incompatibilities and obsolescence. highlighting the specific details of Cloud as an elaboration of the ORA core concepts. to Infrastructure-as-a-Service (IaaS). This is not to say that SaaS is necessarily constrained to business applications.

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

such as software architecture or operations. planning an enterprise wide cost savings initiative or an application migration for agility. ITSO presents successful technology strategies and solution designs by defining universally adopted architecture concepts. xi . principles. and patterns. Given the complexity of the subject of costing it is beyond the scope of this document. While this document necessarily touches some broader topics. 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. Other topic areas. guidelines. 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. standards. 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. such as. such as business and strategy. what is measured will vary greatly depending on many factors. these are included only insofar as they are concerns of any Software Development Lifecycle (SDLC). However.

technical. and quality-of-service requirements. 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. It offers a horizontal technology-based perspective of ORA. including middleware. and governance. and services. and software capabilities that are required to build enterprise-wide industry solutions. business functions. 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. each ETS extends the Oracle Reference Architecture by adding the unique capabilities and components provided by that particular technology. xii . strategy. They define the high level business processes. They adhere to the ORA principles and also draw on the best practices and guidelines provided in ETS collateral. In addition. Please consult the ITSO web site for a complete listing of ORA documents and associated materials in the ITSO series. database. An organization can use this material to measure their maturity. and achieve greater levels of adoption and success. engineering. hardware. processes. It covers a broad spectrum of concerns pertaining to technology architecture. This document is a practitioner guide within the Cloud Enterprise Technology Strategy. technology. develop their strategy. They explain how to successfully execute a strategy by addressing concerns pertaining to architecture. Enterprise Technology Strategies (ETS) offer valuable guidance on the adoption of horizontal technologies for the enterprise. 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. The reference architecture offers architecture principles and guidance based on recommendations from technical experts across Oracle.

"Program Level Activities Overview. 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. their scope and relationships.0. this chapter highlights the xiii .Document Map The picture below shows the ITSO Cloud documents. Building Infrastructure and Platform Cloud Services Release 3. Building Cloud Services Release 3. application architects.1." presents an overview of the Oracle methodological approach for Cloud service development. Audience This document is intended for enterprise architects. 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 . The chapters are organized as follows: ■ Chapter 1. supersedes the original document. project managers and developers. Additional references can be found in the Appendices. Document Structure This document is organized into chapters based on the lifecycle phases of the Cloud service development methodology. "Introduction. ■ Chapter 2. In the context of OUM.Implementation of Physical and Management Infrastructure ■ Cloud Operations ■ Cloud Governance ■ Cloud Security This document." outlines the more broadly scoped activities concerned with the enterprise-wide architecture encompassing all Cloud projects.

How to Use This Document This document is designed to be read from beginning to end. "References. ■ Chapter 6. ■ Appendix A. Conventions The following text conventions are used in this document: Convention Meaning boldface Boldface type in text indicates a term defined in the text. "Elaboration." provides an introduction to the operational activities involved in Cloud development. xiv . ■ Chapter 5. ■ Chapter 8. or in both locations. the ORA Master Glossary. However. italic Italics type in text indicates the name of a document or external reference. ■ Appendix B." provides a lists of additional resources." provides a lists of additional resources. underline text Underline text indicates a hypertext link. "Operate. In order to make this document self-contained many ancillary topics are incorporated without detailed explanations. "Summary." describes the construction phase of Cloud service development. Cloud-specific activities with the Initiate / Maintain and Evolve phases (within in the Envision focus area) for Cloud service development. These broader topics however." is a brief summary and concluding remarks. ■ Chapter 7. "Construction. ■ Glossary provides a definition of the terms highlighted in bold throughout document." describes the transition phase of Cloud service development. "Inception." describes the elaboration phase of Cloud service development. "Transition. "Further Reading. ■ Chapter 3. are expanded in related documents which are listed in the appendix and cross-referenced in the text where appropriate. each section is relatively self contained and may be read independently from the other sections." describes project start-up activities including requirements analysis and verification of business objectives for a Cloud service development. ■ Chapter 4.

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

on-demand network access to a shared pool of configurable computing resources (e. 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?". applications. Ideally this growth and contraction of resource allocation occurs automatically within parameters agreed in advance between provider and consumer. Platform. and manage service consumption with little or no involvement from the provider's personnel. In other words it is important to decide in advance. 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. administer its capabilities. The rapid growth of the Internet in the 1990s presented broader opportunities for centralized computing and the Application Service Provider (ASP) concept was created. At the highest level NIST offers the following definition of cloud computing: "Cloud computing is a model for enabling convenient. select appropriate service levels. Platform. servers. and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. providing application specialisms. however. network. 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. Resource pooling is primarily a capability of the underlying Cloud infrastructure. starting with the NIST characteristics: ■ On-demand self-service: a consumer should be able to acquire Software. ■ Resource pooling: services should be provided from shared platform and infrastructure resources (compute.. networks. storage) that may be allocated from a pool as needed and released back to the pool when demand subsides. To this end we start by looking at the characteristics of Cloud and what they mean in the context of Software.g. they commonly run separate instances of an application for each customer. This form of centralized computing was called "time-sharing" or "utility computing". 1-2 Building Cloud Services . The following lists outline the ways in which the cloud characteristics manifest in services. or Infrastructure services. and offering rental-style pricing models over traditional hardware and license acquisition.Differentiating Cloud Services 1. ASPs have had little or no influence over the software architecture of the third party applications they host for their customers." NIST definitions and other broader characteristics are described in more detail in the ITSO Cloud Foundation Architecture document. This approach is unable to fully optimize the use of resources and lacks scalability. In general. As far back as the 1960s mainframe computers were used to share computing resources to run applications for multiple customers. what characteristics of Cloud Computing will be most beneficial (and potentially which ones are not needed). For this reason. 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). storage. ASPs typically host third-party applications on behalf of their customers relieving them of the burden of IT maintenance.1 Differentiating Cloud Services The idea of hosting business applications to sell as a service has been around for a long time. This approach helps an organization decide on its goals for Cloud and starts the formation of an enterprise-wide architecture definition. and Infrastructure services.

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

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

These include roadmap creation. 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. The motivation for Cloud services may originate from a variety of sources. Instead. Introduction 1-5 . 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. and coordination. Project Level Activities As explained already this document focuses primarily on project level concerns.1.1 Specific Considerations for SaaS Application architectural requirements. Cloud services projects should be initiated using project identification strategies defined and coordinated by the program level. 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. and operated. "Program Level Activities Overview". Technical requirements arising from such application projects have a major impact on the design of Infrastructure and Platform Cloud services. "transfer funds") from the technical ("non-functional") implementation needs (e. In software engineering "functional requirements" distinguish the business purpose of an application (e. Cloud application services invariably rely on platform and infrastructure services (whether they are Cloud based or not). whether they are enterprise-mandated Cloud strategy manifesting from the Cloud characteristics (above) or specific non-functional requirements of the application.g.g. These requirements must be coordinated at the program level. 1. This is where program level activities are critical for structure. particularly when used in the context of Infrastructure and Platform services. Of particular concern are the choices of environment in which the Cloud application services will be developed. 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. Cloud governance. This is described in the document Creating a Roadmap to Cloud Computing. Program level activities are typically strategic initiatives that benefit multiple business units and projects. executed. "apply level 3 transaction consistency"). 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. However. These concerns are covered in more detail in Chapter 2.2 Program Level v. In the case of IaaS and PaaS the consumer is no longer the end-user of an application. Cloud service portfolio management etc. Projects represent discrete units of work that come together to create coordinated services. Cloud method development. 1. An enterprise is typically a provider and consumer with very clear and specific needs. reference architecture development. while separate application projects must typically also be built to work together. Program Level v. All these are program level concerns and can be found in other ITSO documents listed in the glossary. Infrastructure and Platform service consumers considers more technical capabilities (such as database consistency and concurrency) to be the function of the service. standards. commonly involve some dependency on the platform and infrastructure capabilities.

IT initiatives such as modernization. 1-6 Building Cloud Services . existing servers may be consolidated and migrated to a private Cloud for agility and cost reduction reasons. consolidation. to be precise) and technical requirements have a major impact on the design of Infrastructure and Platform Cloud services. and rationalization may result in the identification of IT capabilities that could be implemented with new or existing Cloud services.Programs and Projects Figure 1–1 shows multiple entry points into Cloud service development. an enterprise business delivery project identifies Cloud services based on the Infrastructure and Platform requirements of an application project. 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. infrastructure is out of scope for this document and is covered separately in Building Cloud Infrastructure. Figure 1–1 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). however. Cloud development is supported by multiple projects. In addition to defining business functionality. 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. Non-functional (non-business functional. ■ Business delivery project. 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. 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. and ■ Cloud infrastructure project Cloud infrastructure projects may be required to support the other types if it is not already established. For example.Program Level v. Figure 1–1 illustrates three types of projects - ■ Cloud services project.

It is this part of Envision that is of particular interest in the initiation and coordination of Cloud services projects. These requirements are further refined and implemented by the Cloud services project as well.3 Cloud Service Development Phases The activities for building Cloud services are categorized under three major focus areas . to provide modular capabilities to facilitate alternative configurations. and Operate. that is. 1. 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. Implement. and governance. This is explained in more detail in Creating a Roadmap to Cloud Computing. Some program level activities in Envision are particularly important to the coordination of services projects and are briefly described in this document. architecture. however. Cloud services must be designed to elastically scale on demand. a Cloud Provider must ensure that there are sufficient resources available to support the scalability requirements of the Cloud. etc. Due to the high start-up costs for Cloud and the inability to predict all requirements from the outset. Envision also assists in the transition from enterprise-level planning and strategy activities to the identification and initiation of specific projects. Figure 1–2 Focus Areas and Program/Project Scope The Envision focus area deals with development and maintenance of enterprise level IT strategy. strategy. The "Building Cloud Infrastructure" document covers this topic in more detail. to handle spikes in future load requirements. new assurance and security requirements. Cloud services should be designed to be "future proof". Envision activities span both "Initiate" and Introduction 1-7 . and roadmap. This also reduces the problem of overlapping costs of providing large-scale services before consumers are able to migrate. it is generally a good idea to plan for a phased roll-out. 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. These planning and cost management issues are covered in more detail in the document Creating a Roadmap to Cloud Computing. 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.Envision.

These phases closely align with Oracle Unified Method (OUM) and Unified Process (UP). Elaboration. Elaboration. The project level phases are Inception. and Transition. Construction. Figure 1–3 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 1–3 Cloud Service Development Process At the program scope. The key process of interest in building Cloud services is Enterprise Architecture. and Transition. Cloud Architecture Refinement assumes that a Cloud Reference Architecture already exists and provides a mechanism for maintaining it. the key activities of interest are Cloud Service Analysis and Cloud Architecture Refinement. The primary areas of interest in this document are indicated by the dotted line in Figure 1–2. can be found in Chapter 2. this is not intended to be an exhaustive list). 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. Construction. it is the later Maintain and Evolve phase that enables the incorporation of feedback as new Cloud service requirements emerge from the projects themselves. they are shown here in order to identify key inputs (however. While Envision activities are mostly beyond the scope of this document. Cloud Operations is also introduced in Chapter 7. Cloud Service Analysis provides service identification and requirements for the initiation of projects. Cloud Operations. An outline of the program scoped activities. This process creates and maintains an enterprise-level view of both the application and technical architecture of the systems. At the project level Figure 1–3 shows four phases of Cloud service development - Inception. Cloud Operations is such a significant topic that it has a separate focus area (Operate) and a separate ITSO document.Cloud Service Development Phases "Maintain and Evolve" phases. Cloud Service Analysis and Cloud Architecture Refinement. While the Initiate phase provides strategic guidance in the creation of Cloud projects. 1-8 Building Cloud Services .

project feasibility. the goal of IID is to involve every discipline to create a tangible. in particular the parts that are unique to Cloud service development. "User Acceptance Testing" It is important to remember that this method is intended to be implemented following Iterative and Incremental Development (IID) practices. requirements review. incremental result in each iteration of each phase. ■ The last phase of the Implement focus area is Transition in which User Acceptance Testing (UAT) and production deployment activities occur. 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. This topic is discussed in more detail in.Section 6. The statements in the foregoing list merely identify the focus of this document. Indeed. 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. While the "focus" of these phases is outlined here. such as. such as. and building the project team. UAT of Cloud services is somewhat different from the traditional UAT. Introduction 1-9 . service interfaces. there is no intention to perform only a subset of the project disciplines. within the context of the OUM or UP framework. Cloud service testing is performed in this phase. ■ The Construction focuses on the development of the Cloud service.1. ■ The Elaboration phase focuses on design details.

Cloud Service Development Phases 1-10 Building Cloud Services .

Cloud service development differs from traditional engineering in a couple of ways. both during the Initiate phase and iteratively through the Maintain and Evolve phase. As with traditional software engineering. not only for driving business analysis and concrete Cloud architecture definition into projects. although not all applications will be suitable candidates for Cloud migration. just as SOA did. However. In addition. fall into the categories of "business analysis" and "enterprise architecture" respectively. Infrastructure and Platform services are enterprise scoped services shared by multiple projects within the enterprise. Some service requirements will be identified based on common requirements across multiple Program Level Activities Overview 2-1 . 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. These work-products. the needs of the existing application portfolio must be considered. 2. Cloud service development also begins with requirements. It is an investment that provides increasing returns as more applications are deployed to it. 2 Program Level Activities Overview 2 The activities and work-products at the program level (Initiate. The benefits of Cloud increase with scale. program level Cloud Service Analysis and Cloud Architecture Refinement. Cloud Service Analysis and Cloud Architecture Refinement. The OUM Envision Focus Area encompasses all the activities of the Initiate and Maintain & Evolve phases and provide a coordinated mechanism. but also a mechanism to refine these assets using feedback from projects and new requirements from business leadership. In most cases.1 Cloud Service Analysis Figure 2–1 shows the high level activities in Cloud Service Analysis. Cloud requirements should primarily be driven by business requirements for cost reduction and agility. 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.

2. so future projects can use the Cloud service with little or no change.Requirements Analysis in-flight projects. etc. IT requirements. The Cloud Portfolio Management and Release Planning activity shown in the diagram covers these details. Cloud Service Identification: Cloud services are identified based on the requirements and justified for development by the Cloud service creation team. requirements analysis begins by gathering requirements. The result is a refined set of enterprise-wide Cloud requirements for and requirements for Cloud service projects. application portfolio. The Oracle Cloud reference architecture should be used as a starting point in the absence of a more refined model. 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. Figure 2–1 Cloud Service Analysis Activities The key activities in Cloud Service Analysis are listed below. In all cases. in order to minimize future re-work it is important to look for unique needs arising in these projects. reference architecture. 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. However.2 Requirements Analysis As shown in Figure 2–2. Many will be similar to those capabilities determined by the existing application portfolio and IT capabilities. These inputs include project requirements. 2-2 Building Cloud Services . management and monitoring. Requirement Analysis: Business and IT requirements are analyzed and in conjunction with the Cloud Reference Architecture and existing application portfolio. 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. Cloud services should be built with reuse in mind. ■ Requirements from current and planned projects: The requirements for existing projects must also be considered. ■ 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.

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

What metrics need to be collected? ■ Service business metrics . Elasticity requirements .If the development team or "devops" team can manage certain aspects of the application. Cloud security is covered in more detail in the document Enterprise Strategy for Cloud Security. authentication. – While these projects might aim to reduce IT costs. and enhancing competitive advantage through time-to-market or agility improvements. utilization metrics etc. how data and application will be secured. Many of the items listed here have inherent security requirements. number of business units supported etc.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 . Self service management needs . 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. management. etc. health. new business services and IT capabilities need to be developed. So. – Application or Service components are not known initially in this case.usage. – 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. To deliver these requirements.2. Green-field requirements stem from business initiatives such as introduction of new products. ■ Service operational metrics . ROI. While security is called out on its own.this is typically not a directly stated business requirement but rather derived from the agility requirements such as time-to-deploy. entry into new markets.How the users (mostly the application developers) are going to use and manage the service. it is also a consideration within self-service provisioning.up time. encompassing packaging and promotion of releases to testing environments for example. and audit requirements. 2-4 Building Cloud Services . Self service provisioning needs . 2. reuse.internal and external integration requirements. – This is a top-down scenario where new Cloud services are identified to enable the business capabilities.Requirements Analysis Service invocation requirements (API) . 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. Metrics . authorization.includes a definition of the security entities. Integration requirements . 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.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. ■ Requirements that aim to reduce cost or improve customer experience of existing business interactions (not by introducing new features or capabilities).

as cloud provider is reducing costs then this cost saving must be shared with the cloud consumer in the form of lower usage charges.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. 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). – Some level of standardization is required to re-brand the acquired services and integrate with the common Cloud management infrastructure. In this case.g. 2. – Integration of these acquired Cloud services into the Cloud service catalog. lower cost of using or flexibility and agility of the cloud). – This is a bottom-up scenario. Program Level Activities Overview 2-5 . – 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. For this reason. – Possibly migrate the services to run in the base Cloud. – 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. as shown in Figure 2–3. Alternatively. Note that the benefits of the cloud need to be experienced by both the cloud provider (e. if the IT department. lower cost to manage and maintain) and cloud consumer (e. If only one party is benefiting then tensions are likely to arise in the adoption of cloud. 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). or modernization initiatives. 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. This is a common scenario for Commercial Cloud Service Providers who often add new Cloud services through M&A.g. where existing IT capabilities are re-architected and migrated to Cloud architecture through IT consolidation. For example. rationalization. Cloud Service Identification – Note that this case may require new "IT" capabilities to be built to deliver cost reduction or to improve performance.

build and manage services differently than an enterprise that is building the Cloud for its own use. What happens in the development of Cloud services depends on roles such as builder. Figure 2–4 Cloud Service Identification Steps The deployment model could be determined either before identifying the service candidates or after. Similarly. The deployment model determines where the Cloud service is going to reside and how it will be managed. consumer. Figure 2–4 illustrates the high level steps in the Cloud service identification process. The requirements may be fulfilled by custom in-house development or off the shelf Cloud offerings from external providers. The choice of architecture depends on the enterprise guiding principles. 2. which makes their Cloud service development lifecycle unique. This choice has a major impact on Cloud service development. and operator. and architecture factors. An enterprise may decide to build SaaS Cloud on custom platform or deploy business applications on a PaaS Cloud. an Intermediation Cloud broker plays the role of both consumer and provider.1 Basic steps in Cloud service identification Once Cloud service requirements are documented. A commercial Cloud provider may gather requirements. The roadmap planning process would normally determine the deployment model of applications to be migrated to Cloud. perceived benefits.3.Cloud Service Identification Figure 2–3 Cloud Service Development Influencing Factors The service model determines which layer or layers of the architecture will support the requirements. Enterprises define guiding 2-6 Building Cloud Services . Another aspect that has a major impact on how Cloud services are built is the role of the organization building the Cloud services. Cloud service candidates can be identified.

or Application services. some corporations favor public Clouds.2 Detailed activities in the Cloud service identification process As shown in Figure 2–5. while some discourage their use. Functional requirements primarily drive SaaS decisions. a Java application server platform may be identified as a potential PaaS. and Infrastructure (IaaS). SOA services can be Program Level Activities Overview 2-7 . Alternatively. These requirements are further analyzed by the service creation project team for validity before identifying services for implementation. non-functional requirements and architecture standards drive the platform. Figure 2–5 Cloud Service Identification Process As described in the Section 2. technology. This Cloud service may be designed to run on a "Compute" node that's offered as IaaS. The final step in the process is identifying the workloads and their characteristics. In most cases. you may decide to run the Java application server on dedicated hardware that is not exposed as IaaS. or any combination. Functional requirements are implemented as SOA services or application components. "Requirements Analysis". Service model and service candidate identification is explained in detail in the next section. Business requirements may drive the need for Infrastructure. Platform. Deployment model decision made during the roadmap process is further validated and refined in this phase. public Cloud suitability is assessed based on architecture standards and principles. and information decisions. but either a PaaS or a traditional platform can be deployed on IaaS. Cloud service requirements are identified based on the requirements of the project and are refined to the enterprise scope.2. databases. For example. 2. These decisions drive the choice of the platforms (PaaS). Given the requirements. Cloud Service Identification principles on choosing deployment models. For example.3. Cloud service identification deals with the procedures and guidelines that an enterprise adopts to identify new Cloud service candidates. Workload requirements validate the Cloud service definitions and ensure that the Cloud services being built are suitable for deploying the workload. Building PaaS does not require IaaS.

For example.3.1 Applications Application requirements have traditionally been divided into "functional" and "nonfunctional".3. Functional refer to the business activities performed by the application. and network components.3. 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. and performance. 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. In this way the business needs can be specified first without regard for technological constraints or simply operating within existing capabilities. If an organization chooses multiple numbers of smaller compute nodes. The following sections provide some general ideas and guidelines to help identify the Cloud services. 2-8 Building Cloud Services . If the project has reliability or store-and-forward requirements. Availability.3. 2. but functional application requirements analysis is a well-established discipline and is beyond the scope of this document. Most applications require a database of some kind and architectural standards typically dictate the use of a standardized database version across the enterprise. This is the application’s primary purpose. Understanding nonfunctional application requirements on the other hand are critical to successful cloud adoption.2 Platforms The platform on which the application will be run is determined based on the technical requirements and architecture standards. data redundancy. Infrastructure includes compute capacity. Scalability.2. there is most likely a need for a queuing platform. 2.2. Application components may be custom developed or acquired as a COTS product. Nonfunctional application requirements must be specified in generic high-level terms using categories such as. it will be necessary to make sure that the workload can scale horizontally. These include data availability. In addition it provides automated provisioning and self service benefits that are inherent to a Database as a Service (DBaaS) cloud. and Performance (RASP). backup and restore. The applicability of each of the following services is dependent upon the specific requirements. if available commercially. Reliability.4 Infrastructure The next step is to identify the infrastructure needs of the project. 2.3 Database Database presents another opportunity to leverage Cloud services. storage capacity. Making the database available as a Cloud service is one way of enforcing these standards. A number of key issues need to be considered while identifying database services.2. There is no clear-cut and prescriptive method to identify cloud services. 2.2.Cloud Service Identification deployed as Cloud SaaS offerings. A ballpark estimate of the resource requirements with an understanding of the low and high usage marks is helpful in deciding the infrastructure services.

5 Extension services Consumers of Cloud services often find a need to customize the functionality offered by the service. Ideally the services should scale linearly as more resource is made available to them. even if production is not. Since Cloud services are typically shared across multiple tenants. the design must allow for horizontal scale out and scale back.2. Capacity planning for Cloud is a very detailed topic in itself and is not covered in this document. If not. For infrastructure services. providers are restrained from allowing the consumers to modify them. If development will be done on a platform Cloud service. it is a good idea to make the development platform available as a Cloud service for quick deployment of the development environment. Capacity planning should take into account the peak load and future growth requirements of all projects using the service.3. Cloud Service Identification The requirements also drive the type and size of the storage service. Program Level Activities Overview 2-9 . 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. Many organizations use a type of hybrid Cloud in which application development is performed on Cloud platforms and infrastructure. For platform services. instead they allow the consumers to extend them with additional services in the layers below.7 Development Cloud Development platform is another area where there is a great opportunity to utilize Cloud services. they need to be sized to ensure that they can operate within the model for scaling the Cloud. 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. 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. it is not required to build a Platform service on an Infrastructure service. For example. a SaaS service provider may offer a platform Cloud service so that the consumer could extend the functionality of the SaaS offering. it is essential to understand the nature of the workload. For example. it must be ensured that there are sufficient compute resources available to handle current requirements and future growth. To determine the best suitable storage service. their constraints must be clearly understood. It also explains that it is not required to build a Cloud service on top of a lower layer Cloud service.3. 2.3. the needs are identified in this step. The ITSO Cloud Foundation document describes the layering of Cloud services.2.6 Capacity Planning Once the Cloud service candidates are identified.2. in addition to ensuring that sufficient compute capacity is available. 2. Since most organizations standardize their development technologies. 2.

2.3. Figure 2–6 Cloud Candidate Services Stack Model An example of the Cloud candidate services stack is shown in Figure 2–7.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. The red arrows illustrate the request flow across these services. 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.Cloud Service Identification 2. 2-10 Building Cloud Services . Figure 2–6 shows a conceptual view of the Cloud candidate services stack model.

It also shows which services are built on other services and which ones are extension services. It shows how the services (or service candidates) are stacked up and the dependencies between them.3. existing services.2. when deployed with dedicated hardware the combined single PaaS service may provide greater scalability and performance.9 Defining the service boundaries The service candidates identified can now be reviewed further to define or refine the service boundaries. security. autonomous unit that does not have unnecessary dependencies on other entities. and modified services. 2. Finally. ■ Is it necessary to combine two or more service candidates into one for performance. Oracle WebLogic service may be deployed on an Exalogic engineered system or a generic compute node. ■ 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. Cloud Service Identification Figure 2–7 Cloud Candidate Services Stack Example This model serves multiple purposes. If WebLogic is deployed on a generic compute node. 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 . then the service will be split into a WebLogic platform service (PaaS) and a compute infrastructure service (IaaS). The following list captures some of the considerations for defining service boundaries. conversely. it can be used to identify new services. It is necessary to fully define a service’s boundaries to ensure that it is a fully encapsulated.

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

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 2–8 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 2–8 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 2–9 Cloud Architecture Refinement

Figure 2–9 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

federated. Ultimately the only differences should lie in the nuances such as the order in which things happen. In general this should not make great deal of difference to the method for building services. while a customer survey application does not need to incur the overhead and complexity of Two-Phase-Commit (2PC). however. Self-Service. BASE ■ Identity and Access Management: centralized. security. rather than the consumer. ■ Abstraction. in varying degrees. or brokered Guidance must be provided at a high level. monitoring and measurement should never be afterthoughts. Performance (RASP) ■ Transactions: ACID. 2-16 Building Cloud Services . since software services may be brokered or merely providing support to other software systems).3 Architectural Capabilities The following is a list of examples of architectural capabilities that may be required. charging mechanisms. Unlike the case of Infrastructure and Platform services where the consumer is another IT layer. to be consumed (typically by SaaS applications) or provided (typically by IaaS and PaaS).5. a credit card processing application may require the highest level of transaction support. For example. more attention to location and regulatory differences. of course. whereas a commercial provider publishes a standard service level agreement (or menu of agreements) which the consumer can choose to accept or decline. a greater need for isolation. 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. a greater emphasis on scale and. and User Acceptance Testing (UAT). Automation. Transparency ■ Reliability. Availability. 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.Cloud Architecture Refinement 2. an in-house development team is given service level requirements directly from the business. the application (SaaS) consumer is typically the end user (this is not always the case however. 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.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). for example. The term "consumer" also encompasses a number of different roles. 2. but typically with little scope for negotiation. collecting and delivering functional and nonfunctional requirements. Scalability. synchronized.5. 2PC. In particular governance. distributed. 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. This document focuses primarily on the service provider. potentially with options for selecting options from within these categories to enable decisions to be made at project level. it does typically have some significance in the approach to gathering requirements. Visibility.

7.6 Other Program Level Considerations The following topics are out of scope for the purposes of this document. The business units have also dictated that the application must be up 99.Gates and check points in the process.2 Solution As part of a multi-year initiative. and Options/Derivatives).migration of existing applications to the Cloud services being built. the broad network Program Level Activities Overview 2-17 . including self-service. 2. ABC Bank is already offering customers equity and Forex trading. Is funding coming from the central budget or is it based on a cost allocation model? ■ Architecture development methodology . The traders of the bank use remote trading desks. Cloud migration policies and guidelines. The private Cloud embodies all essential characteristics of Cloud. elasticity. 2.how enterprise architecture is developed at the enterprise and how it influences Cloud service development. it is important to consider these subjects in the context of the service development method. how the Cloud services can be identified. ■ IT portfolio management . ■ IT demand management . However. definition of roles and responsibilities (typically by means of a RACI chart or something similar). This low latency requirement is consistent across all three business lines (Equity. ■ Cloud Governance .how IT demand is managed and channeled into the Cloud service development process. ABC Bank has presence in over 20 countries and different regions use the platform at different times. Forex. ABC Bank had started building a private Cloud two years ago. ■ Funding model . 2. broad network access. policy exceptions and escalations.7. ABC Bank is investigating whether Cloud is the right deployment option and if so. IT had built the necessary Cloud management infrastructure and a few Cloud services over the last two years. 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.management of the portfolio of Cloud services in the broader context of IT portfolio management. measurement. Quotes must be provided really fast with less than 50ms delay.999% on trading days and the system should be able to accommodate additional load seamlessly as the quote volume varies widely.7 An Example This section shows a simplified example of Cloud service identification. and resource pooling.how Cloud service development and operations will be funded. An Example 2. ■ Application migration . 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.1 Problem ABC Bank is expanding into new markets and is introducing an options trading product. More broadly how an Enterprise Architecture framework would be used in concert with the Cloud service development method. The elasticity and resource pooling are important because the different regions use the platform at different times.

ABC Bank's IT has determined that one of the key components of the architecture is the Quotes Engine that provides option quotes. 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. 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 architecture team has established middleware standards. the small banks. Since there is significant reuse of the OEP platform service and Oracle NoSQL database service. The service creation team also evaluates the workload requirements and ensures that the service can handle the load patterns. Based on the non-functional requirements of the project the architecture team identifies OEP as a service candidate. The functional requirements did not have a match with existing services. 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 Cloud service creation team also determines that the Oracle NoSQL database can be deployed on an existing Infrastructure cloud service without any modifications.An Example access is important for remote trading desks. these services are easily justified and accepted by the service creation team. Further boundary analysis suggests that OEP deployed on Oracle Exalogic can better satisfy the business requirements. the three business units and the external customers. the measurement and monitoring is important for checking the QoS. This component is the same as the one used in the equity and Forex trading applications. 2-18 Building Cloud Services . The availability and low latency requirements also drive the need for a high performance database as a service. This new service should support the internal customers. Oracle Event Processing (OEP) has been standardized as the preferred platform for Event Driven Architecture. The Cloud service creation team further analyzes the requirements and identifies an OEP service and an Oracle NoSQL database as a service. so a new Quotes Engine service needs to be built.

and the process of Inception 3-1 .1 Inception Phase Activities Figure 3–1 shows the high level activities of the Inception phase. 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. and cost of the project. Infrastructure or Platform services when view from a high level. However. 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. but SaaS specific concerns are also identified in the following sections. and migration to a Cloud service model is an investment that provides increasing returns as more services are deployed. 3 Inception 3 In traditional software engineering methods. 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. In most cases. As with the rest of the document. In the case of SaaS. non-functional. 3. just as in the case of SOA. leads to great confusion resulting from inconsistent definitions across service tiers). Cloud benefits arise largely from the economies of scale and velocity. In addition. Infrastructure and Platform service development differs from traditional engineering in a couple of ways. Cloud applications service development has many similarities to traditional software development. Cloud services are enterprise scoped and shared by multiple IT projects within the enterprise. Traditional software engineering methods refer to functional and non-functional requirements. Inception is largely concerned with establishing a cohesive team and validating the requirements. however. the term "non-functional requirements" is no longer sufficient to encompass our needs in the Cloud environment (furthermore. On the other hand. identifying risks. application requirements are analyzed to separately identify functional requirements and application architectural requirements. While the functional requirements for the application. the distinction. The inception activities are only slightly different for Software services v. 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. scope. functional v. this chapter focuses on elements of the process that are specific to building Cloud services.

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. the application architectural requirements become much more significant in a Cloud environment. Figure 3–1 Inception Phase Activities (SaaS) Figure 3–1 shows the two primary inputs to this phase for SaaS: the application requirements and the Cloud service capabilities available from the Cloud architecture. Some examples of architectural capabilities were given in Section 2. While most of these requirements should be established at the program level from an analysis of the application portfolio for architectural requirements. etc. The primary input to this activity is the requirement for either a Platform or Infrastructure service.Inception Phase Activities gathering and validating them. The outputs for this phase are (1) technical architecture describing the required capabilities of the service. its API’s. including (1) the Cloud service project fails feasibility checks. Figure 3–2 Inception Phase Activities (IaaS and PaaS) A number of differences arise in the Inception phase for Infrastructure and Platform services.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. These are shown in Figure 3–2. New requirements arising from application projects in this way must be considered at the program level with a number of possible outcomes. and (2) use cases describing how the service should be used. (2) an alternative architectural strategy is proposed by EA. 3-2 Building Cloud Services . these may also arise from additional discoveries during the inception phase of SaaS projects. 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. (3) a new Infrastructure and Platform service project is identified to fill the gap.5. is no different from traditional software development practices.

A key input to this phase is the Cloud reference architecture.1 Cloud Service Definition The next step in the process is to define the Cloud service identified in Section 2. Elaboration 4-1 . 4 Elaboration 4 Elaboration phase of Cloud service development includes definition and design activities as shown in Figure 4–1. Figure 4–2 outlines the activities in the Cloud definition step of the process. The output from the Inception phase forms the input for the Elaboration phase.3. Figure 4–1 Elaboration Phase Activities 4. "Cloud Service Identification" and further validated in the Inception phase in Chapter 3.

Commercial Cloud service providers must define the internal Quality of Service (QoS) requirements to meet the SLAs published to the consumers. Contracts are the agreements between the consumer and provider. It is the business definition of the Cloud service that is likely to appear in the consumer-facing service catalog. Furthermore. contracts should be defined between the IT department and users (business or IT) of Cloud services.1 Defining Cloud Service Contracts Contracts define what the service offers and the SLA for the service from the consumer's view point. 4.1.1.1. an abstraction of the infrastructure resources become more relevant to address concerns of compliance and configuration. For Infrastructure and Platform Cloud services. and accessed. Even for private Clouds. Service providers typically provide a master contract that covers the terms between the provider and all the consumers of the service. As IT deployments are becoming more complex. 4.2 Defining Service APIs APIs are an important component of Cloud services. API specification is a key part of both Cloud services across all service tiers.2. such abstractions enable consumers to both self serve and to operationally control these services without any significant administrator involvement. providers must make their best effort to create and support standards based APIs for the management of infrastructure and platform. APIs specify how the service will be provisioned. Although there are no dominant standards at this point.Cloud Service Definition Figure 4–2 Cloud Service Definition 4. managed. APIs are made available for the consumers to interact with the Cloud provider.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 . 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.

Cloud Service Definition ■ Standards support ■ Good documentation ■ Abstract ■ Encapsulate multiple Cloud resource management tasks into one 4. common resource attributes ■ Resource models.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. WS-* 4. e. ■ Which communication protocols to support. REST. running.1. The platform implementation is responsible for translating the API request and orchestrating the underlying resources.3 PaaS API PaaS APIs are required to manage the building. error messages.2. and the responses expected.. administration.g. Elaboration 4-3 . SOAP. Figure 4–3 shows PaaS consumers managing their PaaS instances using the self service PaaS APIs.2. which describe the data structures used in requests and responses ■ The requests that may be sent to cloud resources. monitoring and patching of applications in the cloud.1.

for example. stop. the standardized API increases consumers' ability to port their applications between PaaS offerings. such generic implementations are likely to be of higher quality than the 4-4 Building Cloud Services . ■ 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. recover. and updating applications. snapshot. etc. and patch an application instance While patching an application instance is mentioned here. This may not be the case. starting. ■ Popular development environments could use the APIs to create plug-ins. 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.Cloud Service Definition Figure 4–3 PaaS API The following is a non-exhaustive list of common PaaS use cases which PaaS providers may choose to support. Over time. where the platform is just a queuing service or data warehouse service. A standardized PaaS management API has the following benefits from the consumer point of view. suspend. stopping.By standardizing the management API for the use cases around deploying. These are application oriented use cases that assume an entire application is deployed to the platform. ■ Portability .

API considerations focus on two main areas of concern: interfacing with management systems and integration between applications. effective integration with externally provided SaaS applications. but must also ensure secure. the management API helps "grow the pie" of the PaaS marketplace by addressing one of the key pain points for PaaS consumers. deployment. Cloud Service Definition implementations written for solitary. This is not only required for interaction between applications within an enterprise. Under a Cloud model however. proprietary application management interfaces. all demanding greater isolation.). 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. Ultimately. 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. change resource priorities. A suitable architectural strategy forces application interactions through orchestration and mediation capabilities provided by the Platform layer. Further examples of provider APIs might enable the provider to move resources around their infrastructure. more valuable areas. Figure 4–4 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).4 SaaS API When developing SaaS applications.1. ■ By increasing the portability of applications between PaaS offerings. Elaboration 4-5 . much more formal interactions between architectural layers (and service tiers) must be defined. Figure 4–4 depicts these application integration considerations for SaaS. there may exist both provider APIs and consumer APIs. Many of the management systems considerations for SaaS have been mentioned in the foregoing PaaS discussion (packaging. 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. start/stop. 4. increase or decrease capacity/capability.2. This is because Cloud application services are more likely to be highly distributed and even hosted by separate providers.

memory/heap size ■ Define HA and elasticity requirements ■ Define any self service interfaces ■ User Interface specifications (primarily for SaaS. Cloud Service Name Name of the Cloud service Type of Service e.g. 4.g.g.1.1 Template for Cloud service definition A sample template for capturing the Cloud service definition is provided below. mirroring etc.CPU size/RAM size. but some UI’s are also necessary for PaaS and IaaS) In addition to the technical specifications. bandwidth.storage capacity. PaaS.# of platform instances or cluster size.g. CPU utilization. ■ Identify IaaS.g.break down services if necessary ■ Define the SLA for the service ■ Define the security aspects ■ Size the service – E. Factors such as service scope.identify the Cloud service boundaries by analyzing various influencing conditions against the Cloud service Candidate. – Platform . # of CPUs – E.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. and QoS requirements may affect service boundaries. ■ Boundary analysis . and SaaS services . The following are the key service definition activities. IaaS/PaaS/SaaS Sub-Type of Service e. security policies. 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.1. functional specifications will also be necessary for SaaS.Cloud Service Definition 4. Compute .3. Storage .) Sizing Service sizing using the service-specific parameters 4-6 Building Cloud Services . space used etc.

overprovisoining ratio) that form SLA's and are wrapped up into business language (e. Gold.3.2. Silver. This section presents some sample metrics for IaaS and PaaS. retention period.CPU utilization % Elaboration 4-7 . a large VM hosing multiple Weblogic JVM's. backup frequency. Bronze) Deployment Zones This is a logical concept but can represent business units. data centers. 4.3.g.g. application level. 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 IaaS Metrics IaaS services are specified broadly based on the fundamental resources such as compute capacity and storage capacity ■ CPU . Cloud Service Definition Access Method How the service will be accessed? Routing information and load balancing Isolation Define isolation strategy . container level. a Weblogic JVM. virtualized infrastructure hosting VM's.) or service quality metrics (e. 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.data level.1. infrastructure pods.2 Defining Service metrics One of the essential characteristics of Cloud services is the ability to be measurable. a Database hosting multiple schemas) Service Class/Tiers These are typically the operational characteristics (e. but composite will be typical for most services. Metrics may be simple or composite. Service definitions should identify which metrics will be used to measure the cost as well as the usage of the service. etc.1. a VM with OS pre-installed. security zones.g. (configurable to the enterprise within the management tooling) Unit of provision What is the consumer getting when this service is turned on? (e. process level etc.g. etc.g.

3.configured CPU Count # ■ Memory Usage GB ■ Memory . average time it took to close security findings or recovery from an outage. 4-8 Building Cloud Services . managed. # of invocations ■ Usage Cost .Transaction Cost.ear. # of services – Number of Deployed Apps. # of transactions 4.Designing Cloud services ■ CPU . number of dropped operations (i. SLA).2.e.1. 4.2 Designing Cloud services Cloud service design should include detailed static and dynamic behavior models that show how the services are provisioned.based on business functions of the application Additional operational metrics common across the service models include service availability (vs. Data transfer characteristics – DML Statements.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. Average/Max DB.3.3 SaaS Metrics ■ Number of users ■ Service Consumption . DB Connections.). number of open security findings.business metrics based on the functions performed by the application ■ Usage Cost . GB – DDL requirements ■ Deployed Entities – # of . etc. and self-serviced. packets. Figure 4–5 shows the key activities in Cloud service design. overall SLA compliance. pool Size. etc.Service Invocations.2 PaaS Metrics ■ DB Usage – DML Operations.2. transactions. Exposed Services ■ Service Consumption .

detailed design may identify the need for additional cloud services that were not previously anticipated. Build vs. How does the design support multiple consumers? For example. velocity. schema level. ■ Multi-tenancy is another key consideration. For example. test cases and test scripts are also created during the Elaboration phase. APIs and service integration components are designed next. how is multi-tenancy handled? Is data isolation handled at the database level. Some Cloud services need workflows that are specific to those services.g. and elasticity requirements of the Cloud? Elaboration 4-9 .Is security infrastructure shared across multiple consumers and multiple service types (e. for example. in the case of a DBaaS. table level. In the case of Infrastructure or Platform services.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.2. In a Test Driven Development (TDD) environment. 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. 4. but may simply identify the elements needed to describe the consumer’s configuration. These service specific workflows are to be designed as well. This could be as little as configuration data in a database. service templates are created from reference configurations. Designing Cloud services Figure 4–5 Cloud Service Design For all Cloud services. or row level? ■ Security considerations . ■ Service model choices may change during the design process. In such a case it may be necessary to reconsider and application development in favor of a SaaS from an external provider. what will be procured and what will be custom developed? Guiding principles around Buy vs. SaaS templates for service instantiation may not involve deployable entities. assembly templates are instantiated to create deployable entities. Lease need to be developed.

and how the critical components of architecture are isolated. a private Cloud might be located in a building owned by a hosting company providing services that are managed by someone else.2 Service Design Template This template captures the key elements of the Cloud service design.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 be scaled over long term? What are the capacity requirements? What is the strategy for long term scaling? ■ High Availability . the number of employees managed in a HR system. CPU. container level. UML activity diagrams.Does the service design satisfy the self service requirements? How does it interact with the management infrastructure? ■ Metering and monitoring .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 . Service usage metrics might include.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. how the requests from different tenants are routed.Scale and velocity are two of the key design considerations for Cloud. the number of users using the service.).2. For example. the number of business transactions performed. This should cover design issues such as how tenant data will be organized. 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 .g. process level etc Multi-tenancy Supporting multiple tenants/consumers at various design levels of architecture. application level. storage. etc. how security infrastructure is shared. Cloud Service Name <name of the Cloud service> Design Overview <high level overview of the design> Static behavior <static diagrams of the service . an important consideration would be integration (both business process and data).e. for example. 4. 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. 4-10 Building Cloud Services .Designing Cloud services ■ Scalability .g state change> Dynamic Behavior <dynamic behavior diagrams . etc.e.data level. ■ In the case of SaaS.

should be configurable Configuration via documents external to the code. HA design High availability and redundancy design.2. Programatic Control Design for programatic control rather than traditional human operations. They are deployed onto a pool of hardware resources with minimal user input. 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. monitoring. Scaling design How the services will be scaled.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. DHCP. and concurrency. Declarative Cloud services. particularly SaaS. The cloud provider instantiates the resources and their configurations as specified in the SAT. From the user's perspective. consistency. Users can create cloud resources by specifying a Service Template in a deployment request. 4. SAT lists the components of the deployable entity and how they are packaged. Transaction Control SaaS in particular must specify its needs for transaction management. a SAT represents the definition of a deployable entity. etc. Elaboration 4-11 .

Designing Cloud services 4-12 Building Cloud Services .

These activities are Cloud service implementation. Construction 5-1 . and Cloud service testing. 5. Packaging and assembly.1 Cloud Service Implementation Figure 5–2 shows the key activities in Cloud service implementation. Figure 5–1 Construction Phase Activities Each of the activities in service construction is elaborated in the following sections. 5 Construction 5 Figure 5–1 shows the high level activities in the Construction phase of Cloud service development method.

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

■ The Cloud service catalog is updated with the information about the new Cloud service. oversight and diagnostics Construction 5-3 . Packaging and Assembly Figure 5–3 Packaging and Assembly ■ Assembly templates are created from a reference configuration.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. Virtual IP addresses (VIPs). The assembly template is a collection of interrelated software components that are automatically configured to work together upon deployment. etc. deployment. 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.2. 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. 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. in which the service instance of a subscriber is created by deploying a set of deployable entities that embodies the topology needed. 5. Firewalls. 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. Assemblies (logically called as deployable entities) are deployed onto a pool of hardware resources with minimal user input. In order to achieve this automation a virtualization solution is typically used. Deployable entities must provide a set of capabilities in order to be useful in a production environment. 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. Load Balancers (LBRs). ■ The Cloud service is deployed in the test environment for testing.

and fault tolerance to ensure that the service level agreements can be met. This is not to be confused with Cloud Testing. ■ Test the service usage with test workloads that are similar to the anticipated consumer workloads. Figure 5–4 Cloud Service Testing Following list captures some of the key tasks involved in Cloud service testing.3 Cloud Service Testing Cloud service testing process is illustrated in Figure 5–4. 5. These include: ■ Ability to easily replicate deployable entities in production. a simple means of composing deployable entities of the components is required. ■ Test the provisioning of Cloud services beginning from discovering the service in the service catalog. The focus of Cloud service testing is to test the concerns specific to Cloud enablement. 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. ■ Test service scalability. even allowing for variations of the them without adding complexity ■ Reduced risk of configuration errors as deployable entities are moved between development. 5-4 Building Cloud Services . ordering. Provisioning process orchestrates several resources behind the scenes and the test cases should cover validation of each of the resources provisioned. allowing for simple implementation of best practices. test and production environments ■ Replicated environments facilitate high-level standardization and consistency across application infrastructures. which refers to the use of Cloud services for software testing. 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. elasticity. The goal of this step is to test the platform and infrastructure Cloud services. ■ Accelerated deployment of new infrastructures and applications In order to realize these benefits. and deployment of the service.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.

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

Cloud Service Testing 5-6 Building Cloud Services .

UAT typically suggests a closed cycle with control over access. These high level activities are shown in Figure 6–1. 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). Transition 6-1 . 6 Transition 6 The transition activities are a) User Acceptance Testing and b) Cloud Service Deployment. although not a "key" transformation. Figure 6–1 Transition Phase Activities 6.1 User Acceptance Testing The concept of UAT is another transformation triggered by Cloud. but public Cloud services frequently rely on an open-beta testing phase. and usually implies structured testing designed to poke at all features in a service and test data is "throw-away". and before revenue release. UAT is still suitable for a private Cloud service. Figure 6–2 shows the User Acceptance Test (UAT) activities. This testing phase usually comes after functional testing / regression testing.

or passive and informal? Cloud application builders may test the service to ensure that the applications they build will run on the Cloud service. is applicable more to the enterprise than a Commercial Cloud Service Provider (CCSP). The activities involved in this deployment are shown in Figure 6–3. The following issues must be considered with respect to this kind of trial or open-beta testing. or thrown away? Or. what are they? ■ What is the feedback mechanism? Is it active and formal. ■ 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. ■ Test service consumption by provisioning the service and testing its functionality. A CCSP may allow a trial period during which the consumer may try the services and provide feedback. are there any service level objectives.2 Cloud Service Deployment Cloud service is deployed to production next. The user might want to test data recovery after termination. ■ Test monitoring and management of the Cloud service ■ Test service termination and cleanup from the user's perspective. Enterprise UAT steps are similar to Testing steps in the construction phase but are performed by the users of the service.Cloud Service Deployment Figure 6–2 User Acceptance Testing UAT. and fault tolerance. ■ Test the provisioning of services beginning from discovering the service in the service catalog and ordering the service. in the traditional sense. elasticity. more generally. 6. ■ Test service multi-tenancy and security. ■ Test service scalability. 6-2 Building Cloud Services . and if so.

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

Cloud Service Deployment 6-4 Building Cloud Services .

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. variations in both requirements and performance are likely to be encountered. 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. Figure 7–1 shows the key activities in this phase. Operate focus area has a phase called "Operations. Ongoing throughout the project. and Management (OA&M)". Proactive evaluation of variations to the baseline will help to identify potential performance issues before the user community notices the impact. as well as the IT Transition Plan prepared during Transition is implemented. For that reason. change and communication events targeted to specific audiences with the goal of mitigating identified risks and challenges are conducted. Operate is a separate focus area in our method.OA&M Phase Activities Production Performance Management is an extension of Performance Management techniques and approaches identified and implemented prior to production implementation. the providers must develop policies around when the services can be upgraded and how the changes will be communicated to the consumers. Since the services are shared across multiple consumers. Administration. 7 Operate 7 Operation is an important aspect of Cloud Computing. Although the basic strategy may be in place. In addition. during Production. Figure 7–1 Operate . Operate 7-1 . Performance metrics should be regularly collected and reviewed for all components.

Any upgrades or patches are applied to the service template (deployable unit) and the service is redeployed. Cloud service retirement should be well planned and the subscribers must be provided with sufficient notice to migrate to the newer versions if applicable.Operations Best Practices Services must be continually monitored to ensure that the SLAs are met.Applying patches is not done the traditional way with Cloud.1 Operations Best Practices Following list captures some of the Cloud operations best practices. The consumers monitor the service they deploy using the self-service management capabilities. In a multi-tenant subscriber environment. Any violations to the SLA must be automatically detected and escalated. Data and other assets must be backed up periodically and recovered when necessary. Capacity management . 7.common issues must be automatically detected and systematically fixed using knowledge management techniques. Metrics are constantly collected and passed on to the respective systems for analytics or billing purposes. hence can diagnose any issues related to the payload. 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. market shift. The underlying Cloud infrastructure must provide ways of collecting and conveying the service specific metrics. Backup and recovery capabilities are essential for any Cloud. Consumers have access to the self-service logs. changes in business priorities. and migrations. 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. 7-2 Building Cloud Services .Consumers must be provided with a self-service administration interface to manage their services. Additional capacity may be required to support the spikes in load. "Operating a Cloud". Self Service Administration . Older versions of Cloud services are typically retired to make way to new versions of services. Self healing .Provisioning must be automated through self-service capabilities Patch Management . The provider is responsible for monitoring the platform components on which the service is running. Cloud services may need to be retired at the end of their useful life. Diagnostics and troubleshooting also happens at multiple levels. Cloud services may be retired for a variety of reasons such as technology obsolescence. Cloud Operations is covered in detail in the ITSO document. If the issue is in the underlying infrastructure. Automated Provisioning . it is diagnosed by the Cloud provider operations team or support analyst groups.Capacity must be proactively managed by taking into account the current and future demand for services.

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. Cloud services are differentiated from traditional IT applications by the scale and velocity. The Cloud service development process for Application. structured approach for effective and consistent results. Summary 8-1 . Most enterprises have either adopted or have plans to adopt Cloud as a strategic choice in support of their business and technology goals. This process can be used with a variety of development methodologies including a flavours of UP and Agile methods. and precise execution to ensure that the services meet and support the business goals. Infrastructure. In all cases. and the level of automation required. Building successful Cloud services requires well defined method. 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. 8 Summary 8 Cloud is quickly becoming a key strategy for business and IT alignment and is starting to dominate architecture roadmap discussions. primary concerns should be ensuring Cloud Computing strategies are appropriate to providing expected benefits and that service development follows a architecture-led. extensive planning. 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.

8-2 Building Cloud Services .

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

A-2 Building Cloud Services .

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

B-2 Building Cloud Services .

networks. OPEX A common business term meaning operational expenditure. OUM is an Iterative and Incremental Development approach similar to Unified Process. Infrastructure-as-a-Service (IaaS) A Cloud service model in which consumers deploy and run arbitrary software. and provisions processing. Glossary The following Cloud specific terms and abbreviations are included here for easy reference. off-the-shelf". Oracle Unified Method (OUM) The engineering method used by Oracle and its partners for all Oracle product implementations. Unified Process (UP) A popular Iterative and Incremental Development engineering process. COTS Abbreviation for "commercial. Operational expenditure refers to the running costs of a business. referring to t a commercial product as opposed to a custom built one. The IaaS provider manages or controls the underlying physical Cloud infrastructure (i. A capital expenditure occurs when a business spends money on tangible assets. CAPEX A common business term meaning capital expenditure.e. and other fundamental computing resources. storage. Glossary-1 . 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. 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). everything below the operating system layer). Please see the ORA Master Glossary for other terms used in the various ORA documents. Software-as-a-Service (SaaS) A Cloud service model in which consumers use applications in a computing environment exhibiting Cloud characteristics.

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. which includes everything below the run-time execution environment. Glossary-2 . The PaaS provider manages or controls the underlying Cloud platform.