opg a pragmatic approach to cloud adoption, release 3 send us your comments a pragmatic approach to...

Oracle® Practitioner GuideA Pragmatic Approach to Cloud Adoption

Release 3.0

E28961-01

March 2012

A Pragmatic Approach to Cloud Adoption, Release 3.0

E28961-01

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Primary Author: Scott Matoon

Contributing Author: Jim Baty, Bob Hensle, Cliff Booth, Steve Bennett, Anbu Krishnaswami, Mark Wilson

Warranty Disclaimer

THIS DOCUMENT AND ALL INFORMATION PROVIDED HEREIN (THE "INFORMATION") IS PROVIDED ON AN "AS IS" BASIS AND FOR GENERAL INFORMATION PURPOSES ONLY. ORACLE EXPRESSLY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. ORACLE MAKES NO WARRANTY THAT THE INFORMATION IS ERROR-FREE, ACCURATE OR RELIABLE. ORACLE RESERVES THE RIGHT TO MAKE CHANGES OR UPDATES AT ANY TIME WITHOUT NOTICE.

As individual requirements are dependent upon a number of factors and may vary significantly, you should perform your own tests and evaluations when making technology infrastructure decisions. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle Corporation or its affiliates. If you find any errors, please report them to us in writing.

Third Party Content, Products, and Services Disclaimer

This document may provide information on content, products, and services from third parties. Oracle is not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle 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.

Limitation of Liability

IN NO EVENT SHALL ORACLE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY YOU OR ANY THIRD PARTY, WHETHER IN AN ACTION IN CONTRACT OR TORT, ARISING FROM YOUR ACCESS TO, OR USE OF, THIS DOCUMENT OR THE INFORMATION.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

iii

Contents

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

Preface ................................................................................................................................................................. ix

Purpose ......................................................................................................................................................... ixAudience....................................................................................................................................................... ixHow to Use This Document....................................................................................................................... ixDocument Structure .................................................................................................................................... ixRelated Documents ..................................................................................................................................... xAcknowledgements .................................................................................................................................... xiConventions ................................................................................................................................................. xi

1 A Pragmatic Process for Cloud Adoption

1.1 Pragmatic Process Defined ........................................................................................................ 1-2

2 Forces for Cloud Adoption

2.1 Provider versus Broker .............................................................................................................. 2-12.2 Strategic versus Tactical ............................................................................................................. 2-32.3 Motivational Context.................................................................................................................. 2-42.3.1 Business Drivers................................................................................................................... 2-42.3.2 Project Control...................................................................................................................... 2-52.3.3 Technology Adoption ......................................................................................................... 2-52.3.4 Operating Model Context................................................................................................... 2-62.3.4.1 Business Process Standardization .............................................................................. 2-62.3.4.2 Business Process Integration....................................................................................... 2-72.3.5 Business Model for IT.......................................................................................................... 2-82.4 Example Scenario........................................................................................................................ 2-82.5 Barriers to Cloud Adoption.................................................................................................... 2-10

3 Key Architectural Decisions

3.1 Service Model .............................................................................................................................. 3-13.2 Usage Patterns ............................................................................................................................. 3-23.3 Deployment Model ..................................................................................................................... 3-43.4 Multi-tenancy Model .................................................................................................................. 3-53.5 Cross Cloud Defenses................................................................................................................. 3-7

iv

4 Roadmap Essentials

4.1 Maturity Assessment.................................................................................................................. 4-14.2 Strategic versus Tactical Path.................................................................................................... 4-34.3 Key Transformations .................................................................................................................. 4-44.3.1 Roles Shifts and Automation ............................................................................................. 4-44.3.1.1 DevOps........................................................................................................................... 4-44.3.1.2 Deployable Entities ...................................................................................................... 4-54.3.1.3 Model Management and Late Binding...................................................................... 4-64.3.2 Governance........................................................................................................................... 4-7

5 Conclusion

A Cloud Maturity Model

A.1 Capabilities ................................................................................................................................. A-1A.2 Domains ...................................................................................................................................... A-1A.3 Maturity....................................................................................................................................... A-2A.4 Adoption ..................................................................................................................................... A-2

B Cloud Candidate Selection Tool

B.1 Evaluation Criteria..................................................................................................................... B-1B.2 Weighting.................................................................................................................................... B-1B.3 Component Scoring ................................................................................................................... B-1B.4 Affinity......................................................................................................................................... B-1B.5 Analysis ....................................................................................................................................... B-1

vi

List of Figures

1–1 Distribution of Activities Across the Phases of Pragmatic Process ..................................... 1-32–1 Three Scenarios for Control of Public Cloud Adoption Over Time .................................... 2-22–2 Six Forces Influencing Cloud Adoption .................................................................................. 2-32–3 Business Drivers.......................................................................................................................... 2-42–4 Project Control............................................................................................................................. 2-52–5 Technology Adoption................................................................................................................. 2-62–6 Business Process Standardization............................................................................................. 2-72–7 Business Process Integration ..................................................................................................... 2-72–8 Business Model for IT................................................................................................................. 2-82–9 Health-E's Motivational Context - Efficiency, Business Control, Mainstream Adoption 2-92–10 Health-E' Operating Model Context - Low Standardization, High Integration, Support 2-93–1 Predominant Cloud Computing Service Models ................................................................... 3-23–2 Common Cloud Computing Usage Patterns .......................................................................... 3-33–3 Cloud Suitability Chart .............................................................................................................. 3-53–4 Multi-tenancy architectures for database ................................................................................ 3-63–5 Discontinuous Defenses Across Clouds .................................................................................. 3-74–1 Maturity Model Domains .......................................................................................................... 4-24–2 Roadmap Focus Areas Identified by Cloud Maturity Model............................................... 4-34–3 Strategic versus Tactical Cloud Roadmap............................................................................... 4-44–4 Delineation of Traditional and DevOps Responsibilities ..................................................... 4-54–5 Deployable Entities within a Logical View of Cloud Architecture ..................................... 4-6

vii

Send Us Your Comments

A Pragmatic Approach to Cloud Adoption, Release 3.0

E28961-01

Oracle welcomes your comments and suggestions on the quality and usefulness of this publication. Your input is an important part of the information used for revision.

■ Did you find any errors?

■ Is the information clearly presented?

■ Do you need more information? If so, where?

■ Are the examples correct? Do you need more examples?

■ What features did you like most about this document?

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

ix

Preface

The label Cloud Computing carries a multitude of connotations, involving concepts ranging from pay for service and ubiquitous access to the simplification and commoditization of information technology. Yet, amid the ambiguity and inexact interpretations, Cloud Computing is widely regarded as a disruptive and potentially transformational direction for information technology. 'The Cloud' is frequently associated with a prospective way of processing and managing information. “In the future, we will [verb] [object] in the Cloud,” is a familiar prediction. Of course, this future has already arrived. It is just unevenly distributed.

PurposeFor enterprises that seek to transform their own IT capabilities and avoid adverse disruption in the process, a structured and pragmatic approach is required. This Practitioner Guide proposes a framework that can be used within any organization for developing such an approach to Cloud adoption.

AudienceThis guide is intended for those who wish to gain understanding of the fundamental considerations involved in developing a Cloud Computing strategy and how to apply them within their own organization. This guide does not present a stepwise recipe for implementing Cloud Computing. Its goal is to provide sufficient insight into the critical factors influencing Cloud architecture and guidance on how to approach key decisions in the development of a roadmap to Cloud Computing.

How to Use This DocumentThis document is intended to be read from start to finish. However, Chapter 1 can be read standalone if the goal is only to get a high level understanding of the process.

Document StructureA structured process to facilitate successful application of the principles described in this guide is indispensable. Such a process is presented and is then related to activities and considerations described in subsequent chapters. Specifically,

■ Chapter 1 describes the process for adopting Cloud Computing.

■ Chapter 2 puts the potential for Cloud Computing into a more useful context by describing the specific forces driving the enterprise to Cloud Computing. The

x

major factors to consider and a method for balancing these forces are the focus of this chapter.

■ Chapter 3 examines the important architectural considerations for Cloud Computing.

■ Chapter 4 presents important considerations and advice for laying out a focused and achievable path for Cloud adoption.

■ Chapter 5 provides a summary and conclusions for this document.

■ Appendix A describes the Cloud Maturity Model that is used to evaluate the current state and identify capabilities that are lacking or lagging

■ Appendix B describes the Cloud Candidate Selection Tool that is used to evaluate the architectural suitability of IT assets for deployment to a public or private Cloud.

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

ITSO is made up of three primary elements:

■ Oracle Reference Architecture (ORA) defines a detailed and consistent architecture for developing and integrating solutions based on Oracle technologies. The reference architecture offers architecture principles and guidance based on recommendations from technical experts across Oracle. It covers a broad spectrum of concerns pertaining to technology architecture, including middleware, database, hardware, processes, and services.

■ Enterprise Technology Strategies (ETS) offer valuable guidance on the adoption of horizontal technologies for the enterprise. They explain how to successfully execute on a strategy by addressing concerns pertaining to architecture, technology, engineering, strategy, and governance. An organization can use this material to measure their maturity, develop their strategy, and achieve greater levels of adoption and success. In addition, each ETS extends the Oracle Reference

xi

Architecture by adding the unique capabilities and components provided by that particular technology. It offers a horizontal technology-based perspective of ORA.

■ Enterprise Solution Designs (ESD) are industry specific solution perspectives based on ORA. They define the high level business processes and functions, and the software capabilities in an underlying technology infrastructure that are required to build enterprise-wide industry solutions. ESDs also map the relevant application and technology products against solutions to illustrate how capabilities in Oracle’s complete integrated stack can best meet the business, technical, and quality of service requirements within a particular industry.

This document is one of the series of documents that comprise the Cloud Enterprise Technology Strategy. The Cloud ETS includes reference architecture documents (ORA Cloud Foundation and ORA Cloud Infrastructure) as well as “how to” documents such as this guide to adopting Cloud Computing.

Please consult the ITSO web site for a complete listing of ORA documents as well as other materials in the ITSO series.

This Practitioner Guide also makes reference to the following documents relating to analytical tools created by Oracle to aid in the Cloud adoption process:

■ Cloud Maturity Model Capabilities - This spreadsheet contains the specific capabilities that are measured as part of a current state analysis. For each capability a description is provided for each level of maturity and adoption. Approximately 60 capabilities are described in the spreadsheet.

■ Cloud Maturity Model Capabilities Analysis - This spreadsheet is used in conjunction with the maturity model to analyze scores for each capability on both maturity and adoption. The spreadsheet contains various graphical depictions of the scores.

■ Cloud Maturity Model White Paper - This document gives the rationale for the Cloud Maturity Model and describes the maturity and adoption levels used in the tool. It then provides guidance on how to develop an analysis using the Cloud Maturity Model.

■ Cloud Candidate Selection Tool - This spreadsheet is used to score applications, services, modules, etc. for Cloud suitability i.e. are they architecturally compatible with Cloud (public or private) deployment.

■ Cloud Candidate Selection Tool White Paper - This document gives the rationale for the Cloud Candidate Selection Tool and describes the criteria and process involved in applying the tool.

AcknowledgementsThis document is based on a variety of materials that have been created by many different individuals and groups. Thanks to all who contributed. The purpose of this document is to catalogue the materials and describe the process for using the materials together to create a A Pragmatic Approach to Cloud Adoption.

ConventionsThe following typeface conventions are used in this document:

http://www.oracle.com/goto/itstrategies

xii

Convention Meaning

boldface text Boldface type in text indicates a term defined in the text, the Master Glossary, or in both locations.

italic text Italics type in text indicates the name of a document or external reference.

underline text Underline text indicates a hypertext link.

1

A Pragmatic Process for Cloud Adoption 1-1

1A Pragmatic Process for Cloud Adoption

As organizations adopt Cloud Computing, they will need to define a roadmap that aligns with their own business drivers and clearly identifies their current and future capabilities for delivering IT services. For most enterprises, an effective approach combines the right mix of IT standardization, consolidation, and optimization and introduces new capabilities such as self service, resource pooling, and rapid elasticity.

Development of such a roadmap requires analysis across multiple dimensions involving business and technology considerations. In this Practitioner Guide, a framework for this analysis and roadmap development is presented, along with references to additional documents and tools developed by Oracle to help organizations gain the most from transitioning to Cloud Computing. The approach follows a basic methodology, Pragmatic Process for Cloud Adoption, which is similar to the Unified Process in structure and purpose, and is characterized as:

■ Iterative and lightweight - key activities are repeated in multiple phases of the process and produce an incremental result for evaluation and further improvement at the end of each iteration. The process is not prescriptive and does not define specific artifacts or outcomes for each of the iterations.

■ Usage Pattern and Workload Driven - implementation requirements are derived from the intended usage patterns for Cloud Computing. Applications and workloads are examined in the context of these usage patterns and the resulting “intersections” of usage patterns and workloads form the basis for iteration within the phases.

■ Lifecycle Complete and Adaptable - the process is end-to-end with respect to the lifecycle of a Cloud Computing initiative within an enterprise and assumes that the initiative will address Cloud adoption for at least part of an existing (legacy) IT environment. The process is adaptable and is intended to be tailored by its practitioners. It should complement, not replace, other methods that may be in use.

The drivers of Cloud Computing adoption are highly diverse between organizations and even within the same organization. Likewise, there is broad diversity between organizations in terms of operating models, risk sensitivities, and relationships between business and IT, among other factors. For these reasons initial activities focus on identifying the unique combination of forces influencing the organizations' approach to Cloud Computing. Balancing these forces is one of the primary objectives of this pragmatic approach. This is a critical step in developing an informed business strategy and rationalized architecture for Cloud Computing.

Finally, the process describes the essential considerations for synthesizing the identified forces and the architectural decisions into a comprehensive roadmap to Cloud Computing carefully tailored to the needs of the enterprise.

Pragmatic Process Defined

1-2 A Pragmatic Approach to Cloud Adoption

1.1 Pragmatic Process DefinedAn iterative process involving five phases is recommended to govern the Pragmatic Approach described in this guide. The phases and major associated activities are:

1. Envision - Identify the primary forces driving the Cloud strategy. Define the major usage patterns to be supported and the major groupings of workloads to be deployed with these usage patterns.

2. Assess - Measure current Cloud related capabilities in terms of maturity and adoption. Decompose and evaluate target workloads for Cloud deployment. Evaluate potential service models for the target usage patterns and workloads. Estimate and compare costs and benefits of potential deployment models. Validate target usage patterns and workloads with current and prospective consumers. Define preliminary budget and skills requirements.

3. Design - Expand and refine target usage patterns. Choose service model(s). Prioritize workloads and desired capabilities. Define architectural building blocks and detailed deployment model. Define projects and project dependencies. Identify major areas of operational and organizational transformations. Validate designs with vendors and service providers. Create roadmap.

4. Build - Implement the design. Track progress against roadmap - capabilities development, and projects' budgets and schedules.

5. Operate - Transition the implementation and put into production operation. Track progress against Goals - consumer impact and operating budgets.

While this process is end-to-end in terms of Cloud adoption activities, this guide is primarily concerned with the first three phases. As the framework for a pragmatic approach, this process is flexible and should not supersede other effective methodology that may already be in use. Rather, it should be adapted to these methods. The activities described can be readily adapted to other processes and frameworks such as Unified Process1. The expected distribution of major activities described in this guide across the phases of the Pragmatic Process is shown in Figure 1–1. Note that most of the activities involved in the Build and Operate phases are beyond the scope of this guide, so are not shown in this illustration.

1 Unified Process on Wikipedia: http://en.wikipedia.org/wiki/Unified_Process

http://en.wikipedia.org/wiki/Unified_Process


A Pragmatic Process for Cloud Adoption 1-3

Figure 1–1 Distribution of Activities Across the Phases of Pragmatic Process

In practice, phase 1 (Envision) may not always be the most expedient starting point. However, Cloud initiatives beginning with later phases will incur a certain 'debt' to earlier phases that will likely need to be dealt with at some point, at potentially greater risk and cost. For instance, beginning with Design activities to automate provisioning of virtual machines may produce relatively quick visible benefits by leveraging existing server virtualization capabilities, but this form of automation may not be aligned to the ultimate goals of automation capability to provision complete topologies of complex and distributed applications. This, in turn, may cause a redesign effort that eliminates server virtualization from parts of the architecture - an effort that might have been avoided if the Envision and Assess phases were completed first.

2

Forces for Cloud Adoption 2-1

2Forces for Cloud Adoption

Organizations approach Cloud Computing in a variety of contexts. These contexts, together with the problems to solve with Cloud computing, make up the forces driving Cloud adoption. Before defining architecture or prescribing solutions for a Cloud Computing initiative, it is important to identify the forces behind it - what are the organization's expectations from Cloud, what drives the investment, and what role will the organization play in the consumption and delivery of Cloud services. Identifying the forces for Cloud adoption, then, entails representing the range of viewpoints having a stake in the outcome of Cloud adoption, as well as the goals of these stakeholders. This is the first step toward an approach that is realizable and aligned to the needs of an organization.

2.1 Provider versus BrokerOne of the obvious forces affecting Cloud adoption is the increasing availability of public Cloud services that meet the IT needs of enterprises. This drives consumption of certain IT services away from internally provided services toward externally provided services. It also drives a rethinking of the role of enterprise IT where it traditionally functioned as the builder and provider of all IT services consumed by customers, partners, employees, and management. The approach to Cloud adoption must explicitly address which services are provided internally and which are consumed from public Cloud providers, as well as what role IT plays with respect to each in the delivery of IT services. With the explosion of public Cloud services, IT may increasingly function not only as provider, but also as broker for public Cloud services, to administer:

■ Aggregation: Unify the management interface to multiple public Cloud providers.

■ Arbitrage: Evaluate, audit, and acquire public Cloud services based on capabilities, price, standards, and service level compliance.

■ Intermediation: Provide higher-level service by integrating specific capabilities with lower-level services consumed from a public Cloud provider.

(See NIST's Cloud Computing Reference Architecture1 for more on the role of Cloud broker.)

Within an enterprise IT context, these broker roles usually involve some form of integration or interoperability between internal functions and public Cloud providers. These hybrid scenarios stand to grow in relevance for most organizations. Correspondingly, the proportion of services provided internally versus consumed from public Cloud providers, is likely to change. Depending on the direction, velocity,

1 Cloud Computing Reference Architecture by the National Institute of Standards and Technology (NIST): http://www.nist.gov/manuscript-publication-search.cfm?pub_id=909505

http://www.nist.gov/manuscript-publication-search.cfm?pub_id=909505

Provider versus Broker


and impact of this change, an enterprise may be compelled to establish Cloud broker capabilities.

Figure 2–1 presents a simplified view of three potential scenarios for public Cloud adoption within an enterprise.

Figure 2–1 Three Scenarios for Control of Public Cloud Adoption Over Time

Each scenario begins with the majority of services provided internally, and public Cloud services being adopted over a series of business cycles (e.g., annually). Scenario 2-A is what might be expected for a highly integrated organization with a strong central IT function that has authority to control technology choices and, consequently, limits public Cloud adoption and maintains control over it with a broker capability. Scenario 2-B is what many IT organizations may strive to achieve as their line of business customers begin to adopt public Cloud services directly, while under pressure to provide some control over IT costs and risk across the enterprise. In this scenario, IT develops a compelling value add broker capability that gains control over public cloud services. Scenario 2-C, wherein IT relinquishes control of public cloud adoption, is what might be expected of a highly diversified organizations where business processes are not standardized across operating units and technology choices are not governed by central IT.

For those services brokered by IT, the value added by the broker must be clearly demonstrable. The broker will be subject to demands for competitive pricing, faster delivery of new services, and continuous service improvement. The broker's existence depends on its positive contribution to the value chain, the total value of which must exceed the value of consuming those services directly from public Cloud providers. This contribution may be comprised of values associated with control over security, pricing leverage, and integration with other services. The capabilities needed to make

Strategic versus Tactical


this contribution to the value chain, and to measure it, must be developed in order to succeed with an internal Cloud broker approach.

2.2 Strategic versus TacticalWhat sorts of advantages are expected from Cloud Computing by the organization? A major factor influencing the approach to Cloud adoption is whether those expectations are more strategic or tactical in nature.

Expected tactical advantages of Cloud Computing may include:

■ Reduce IT cycle time through streamlined deployment processes.

■ Improve service reliability during peak demand periods through rapid scaling capabilities.

■ Gain efficiency through consolidation onto shared resources.

■ Simplify cost allocation through common metering and chargeback capabilities.

Expected strategic advantages of Cloud Computing may include:

■ Reduce time to market for new business initiatives.

■ Change the cost structure of IT to reflect actual costs of delivered service.

■ Reduce risk of experimentation with trial products and services.

■ Enhance synergy with other strategic business initiatives, e.g., new M&A strategy.

Expectations drive the planning and architectural decisions, so it is important to start by characterizing the expectations in terms of strategic or tactical advantage.

In addition to the first order questions of provider versus consumer and strategic versus tactical advantage, many other forces combine to form an organization's approach to Cloud Computing. These factors include the motivations driving the initiative, decision authority for the initiative, the intended business model, and tolerance for risk, among others. These factors can be gauged from diverse viewpoints including planning time horizon (short term versus long range), business impact (minor versus transformational), and market approach (protect position versus disrupt and challenge). Six distinguishing forces discussed here that influence a pragmatic approach to Cloud adoption are shown in Figure 2–2.

Figure 2–2 Six Forces Influencing Cloud Adoption

Motivational Context


A sphere is used in this discussion to symbolize the unique combination of forces influencing an organization's approach to Cloud adoption. These forces are organized into two contexts: a Motivational Context comprised of three forces - Business Drivers, Project Control, and Technology Adoption; and an Operating Model Context comprised of three forces - Business Process Standardization, Business Process Integration, and Business Model for IT.

2.3 Motivational ContextThe three forces described below combine to form a motivational context for approaching Cloud adoption. A thorough understanding of the direction and magnitude of these forces should be established in the Envision phase of the Pragmatic Process to Cloud adoption. Requirements for target usage patterns and workloads should be interpreted and refined in this context as part of the Assess phase. Compromises on certain forces in the motivational context should be dealt with in the Assess and Design phases.

2.3.1 Business DriversThe business drivers leading to IT investments are as varied as the organizations making the investments. Very often these drivers spring from a motivation to either save costs or to increase business agility. Understanding what an organization expects from the Cloud initiative broadly in terms of efficiency and business agility is an important consideration in making design tradeoffs and in constructing a roadmap for Cloud adoption.

Figure 2–3 Business Drivers

Cloud Computing projects motivated by potential cost savings and increased efficiency are generally tactical in nature and may have a return on investment target expressed as expense reductions. In this case, a common approach is to increase asset utilization through consolidation of workloads onto less costly infrastructure. In contrast, business agility improvements, such as acceleration of product development and faster response to market conditions, are the kinds of strategic motivations typical of investments in Cloud Computing. Whether efficiency or business agility primarily motivates the Cloud project will affect the approach. For example, Cloud projects focused on efficiency may initially plan to consolidate applications onto shared infrastructure, whereas an agility-focused plan is more likely to introduce higher levels of automation early in the project.



2.3.2 Project ControlControl and responsibility for IT projects most often lies with the IT department today. However, this orientation is shifting toward more control in the hands of lines of business and enterprises' operating units. Gartner recently projected that 35% of enterprise IT expenditures for most organizations will be managed outside the IT department's budget by 2015. This shift reflects a 'consumerization' of IT, and Cloud Computing's self service, ubiquitous access, and pay-for-use features exemplify that shift. Frequently, IT's overt position of control has not been adjusted to reflect the business reality of simple and direct access to public Cloud services by business units and workers. This commonly leads to 'shadow' IT, which carries potential security risks and unnecessary expenditures.

Figure 2–4 Project Control

Where the actual authority and control for a Cloud project lies within an organization affects many aspects of the approach to the project. Questions such as how resources are shared, how data protection policies are enforced, and how expenses are controlled are answered differently depending on whether a central IT department controls projects or control is distributed among the business consumers of IT. The balance of Cloud project control is a critical force that figures prominently in an effective approach to Cloud adoption.

A related question arises in the case of business controlled Cloud projects: what level of the business is responsible for the project? The IT departments' traditional responsibilities of ensuring security, managing service levels, controlling costs, and vetting technology providers, etc. still need to be carried out. Are these duties conducted centrally or distributed to the parts of the business that control Cloud projects?

2.3.3 Technology AdoptionTechnology adoption practices typically reflect an organization's tolerance for risk as well as its expectations of technological leverage to be gained in the market. Innovators and early adopters will routinely accept a higher degree of risk in terms of the viability or reliability of a given technology in order to gain first mover advantage. Mainstream adopters wait until a technology goes mainstream before introducing it into their own environment so as to avoid any but the most minor of risks. While early adoption has the potential to produce real market advantage, success with this strategy is not assured. In fact, many innovative technologies fail to reach mainstream adoption, which may expose early adopters to problems of reliability as well as a negative return on investment.



Figure 2–5 Technology Adoption

Whether an organization leans toward early adoption or mainstream adoption can be gauged simply by reviewing the existing technology portfolio. A portfolio dominated by mainstream products and technologies indicates a mainstream adoption bias. A portfolio that includes many products from new companies or unproven technologies indicates a bias toward early adoption. Mainstream adoption practices affect the approach to Cloud projects by following another organization's or industry's lead and involves minimal levels of innovation. A strong preference for early adoption leads to an approach that accepts certain significant risks and accounts for the prospect of failure.

2.3.4 Operating Model ContextEnterprises are differentiated by, and often defined by, their business processes; an enterprise's operating model is a reflection of its business processes. The operating model context is comprised of three forces: The level of standardization and integration found in an enterprise's core business processes, and the function of enterprise IT as either just a supporting role or as a leading role with direct revenue responsibility. The direction and magnitude of these forces should be readily identified in the Envision phase of the Pragmatic Process, then used to guide the activities in the Assess and Design phases. Adjustments to the operating model may be necessary in order to implement the Cloud solution.

2.3.4.1 Business Process StandardizationStandardization of process can produce significant efficiencies and improve predictability for an operation, but may limit business units in their ability to operate autonomously. High levels of standardization tightly constrain processes and leave little room for diversity between departments, business units, and geographic regions. Low levels of standardization allow for diversity and are usually accompanied by redundancies that carry overhead expense.



Figure 2–6 Business Process Standardization

Enterprises that support diverse processes with minimal standards across the businesses may find it difficult to introduce Cloud Computing as a shared service across the enterprise. In this case, a Cloud environment tailored to the needs of a specific operating unit may be more tenable. Enterprises that employ common processes across operating units may be able to parlay the high level of standardization into widely adopted Cloud services that support these processes.

2.3.4.2 Business Process IntegrationProcess integration can accelerate operations and help organizations capitalize on synergies among its operating units. An enterprise that relies on highly integrated processes can coordinate complex operations reliably and efficiently, yet affords relatively autonomous operations across business units. Low levels of process integration hinder coordination across business units, but independently operated business units and centralized operations are not necessarily held back by lack of process integration.

Figure 2–7 Business Process Integration

The level of process integration is fundamental to how an enterprise operates. The approach to Cloud adoption should reflect this. For example, highly integrated processes may benefit from running on highly integrated platforms. A Platform-as-a-Service (PaaS) model, which can facilitate data sharing across processes, may be advisable in this case. Low levels of integration may indicate reduced emphasis on infrastructure sharing and programmatic control in the Cloud in favor of robust self service capabilities.

Example Scenario


2.3.5 Business Model for ITMost IT departments are organized as a cost center to support business operations. Functioning as a cost center necessitates cost allocation schemes and processes for liaising with the business consumers of IT. In cases where IT capabilities are core to the organization's products and services, however, much of the IT department's traditional function merges with the business. As IT becomes more integral to a functioning enterprise, the business model for IT may shift away from operating as a separate support function and toward an integrated model where IT and business are organizationally indistinguishable. The implications of the business model for IT affect multiple aspects of the approach to Cloud Computing. In organizations where IT exists as a support function, pricing of Cloud services are more likely to be set on a cost recovery basis and service levels are managed according to business need. When IT is integrated with business units and its services are delivered directly to customers, pricing of services may be set on a gross margin basis or according to market rates, and service levels are more likely to be managed according to contractual obligations.

Figure 2–8 Business Model for IT

Furthermore, attainment of Cloud Computing capabilities often compels organizations to envision new business models for IT in which internal Cloud services make possible new revenue opportunities by providing the platform for external services. For example, if an enterprise possesses a market leading process, it may be in a position to implement this process as a public Cloud service if it had the leverage of a Cloud enabled platform. Identification of prospective services that could be delivered on a new Cloud platform is likely to shift the business model balance for IT toward IT as a Business.

2.4 Example ScenarioAll of the factors described above comprising the forces influencing an organization's approach to Cloud adoption should be evaluated both in terms of current state as well as desired state. Developing an approach that reflects not only the current realities, but also the changes needed to transform the organization is essential to the success of any project. The following example scenario considers the direction and magnitude of forces in both current and future motivational and operating model contexts.

Health-E Corporation (fictitious) is a leading healthcare provider. The company has experienced rapid growth primarily through acquisition of hospitals. Health-E seeks to protect their market leading position by exploiting economies of scale while also modernizing their IT systems. A major initiative focusing on elimination of redundancies among the various acquired hospitals has been launched. In support of

Example Scenario


this initiative, Health-E's central IT department is planning a Cloud Computing project with a goal of reducing redundancies in IT infrastructure in order to save 15% in operating costs year over year through the next three years. This project puts more weight on cost savings than business agility and follows Health-E's existing model wherein IT supports projects that are funded and measured by the CFO. As a highly regulated enterprise that manages systems involving life support, Health-E is risk averse and typically adopts only those technologies that are well proven within the healthcare sector. Figure 2–9 shows Health-E's perspective in terms of business drivers, project control, and technology adoption for this Cloud project.

Figure 2–9 Health-E's Motivational Context - Efficiency, Business Control, Mainstream Adoption

Further, IT exists to support Health-E's business and does not directly drive business decisions or produce revenue. Health-E's plan to rapidly integrate acquired hospitals has been difficult to fulfill because of the diversity of systems in which individual hospitals have invested. As part of the Cloud project, Health-E central IT will absorb the majority of IT functions currently performed within the hospitals with a goal to integrate patient records and claims processing across these silos of IT systems. Figure 2–10 shows Health-E's perspective in terms of IT's business model, Level of Standardization, and Level of Integration for this Cloud project.

Figure 2–10 Health-E' Operating Model Context - Low Standardization, High Integration, IT as Support

Barriers to Cloud Adoption


Approaching a Cloud adoption with an understanding of the unique combination of forces confronting an organization will help to make reasoned tradeoffs, rationalized design choices, and set priorities in the development of a roadmap.

2.5 Barriers to Cloud AdoptionIn addition to the forces outlined above, there are a number of perceived barriers that inevitably affect an organization's approach to Cloud adoption. Some of the challenges that organizations face when moving to a Cloud Computing model are practical reflections of the limits of the technology and constraints beyond the organization's control. However, many barriers to Cloud adoption are imposed by the organization itself. These barriers should to be examined in the context of Cloud Computing benefits, and a determination made for each as to whether it should continue to be a barrier to Cloud adoption. Commonly cited barriers include:

■ Data privacy protection issues

■ Line of Business aversion to resource sharing across business unit boundaries

■ Loss of control over architecture and technology choices by line of business

■ Complexity of auditing in a shared environment

■ Risk of disruption to critical services

■ Introduction of latency into business applications

■ Increased operating expense

Any or all of these barriers might be addressed with an appropriate architecture that mitigates the concerns. The following section illuminates the key architectural choices involved in the implementation of Cloud capabilities. Choosing the right architecture is essential to addressing the organization's unique needs and overcoming its perceived barriers to Cloud Computing.

3

Key Architectural Decisions 3-1

3Key Architectural Decisions

Cloud Computing represents significant potential returns on IT investment to an enterprise. Applying an architectural approach that accounts for the forces influencing and organization's perspective is instrumental in attaining the expected advantages of Cloud Computing. This section discusses six architectural decisions that will ultimately need to be made in the course of most Cloud Computing projects. Addressing these decisions early as part of the roadmap development can help to streamline implementation.

3.1 Service ModelThe NIST grouping of Cloud Computing service models into three layers is a reasonable representation of the predominant implementations of Cloud Computing today. The concept of layered service types is not rigid, but the distinction between the three service models is unambiguous. Simple definitions of the three models are:

■ Software as a Service (SaaS): Consumers use applications running on a Cloud infrastructure. The SaaS provider manages or controls the underlying software and infrastructure. Relative to the other lower layer service models, functionality of SaaS offerings is less flexible by design, but what it lacks in flexibility it aims to make up in direct value to its users.

■ Platform as a Service (PaaS): Consumers use programming languages and tools supported by the PaaS provider and then control the deployed application. PaaS is designed to provide the necessary capabilities to allow developers to focus on the higher value activities of building and delivering applications while leaving the configuration and management associated with the underlying platform to the provider.

■ Infrastructure as a Service (IaaS): Consumers deploy and run arbitrary software, and requisition from the IaaS provider the needed compute, storage, and networks to do so. IaaS is designed to allow consumers choice of technology for the entire stack above the hardware, while eliminating the complexity of management of the physical infrastructure.

Figure 3–1 depicts the three service models in relation to each other. The layering in this depiction indicates that higher-level service models can be implemented upon lower level service models, e.g., PaaS on top of IaaS. Layering of service models is not essential, however, e.g., SaaS can be implemented without an underlying PaaS or IaaS model.

Usage Patterns


Figure 3–1 Predominant Cloud Computing Service Models

However, even in the case of SaaS, multiple service models may be involved. The delivery of a single software service may be built upon a PaaS environment that is shared by other SaaS offerings, which in turn may be built upon an IaaS environment that is shared by other PaaS and SaaS offerings.

For most enterprises, the choice of service model will derive primarily from business goals; particularly in the case of IT services to be provided commercially. If a business wishes to deliver a consumer application to mobile devices then their choice of service models would certainly include SaaS. SaaS may also be the right choice for a business that wants to consume a specific business application, such as CRM, from a service provider rather than deliver the service itself.

In addition to the business goals, other factors influencing choice of service model include:

■ Investment in virtualization - virtualized IT infrastructure established through the use of hypervisor technologies provides a starting point for incremental adoption of Cloud Computing. This approach conforms to an investment protection strategy and should enable quick implementation of hardware resource pooling, which is a fundamental IaaS capability. This approach also potentially represents less disruption to existing processes - it perpetuates the status quo for the development, release, and management of applications. Because this approach alone does little to eliminate complexity and delivers no new shared services other than pools of hardware, it often falls short of the transformational benefits represented by higher-level service models.

■ Commitment to technology standards - as described in the preceding chapter, Forces for Cloud Adoption, the level of process standardization has important implications for approaching Cloud Computing. The same is true for technology standardization. Organizations committed to a standard based on highly integrated technologies that comprise a 'complete stack' may not need the flexibility to support a diverse array of alternative technologies. In this case, the higher value capabilities of PaaS may be more readily attained. Conversely, flexibility to support diverse technologies may be necessary in environments where standards are difficult to establish and enforce. IaaS may be a more realistic goal for service model in this case.

3.2 Usage PatternsCloud Computing can be applied to a wide range of usage patterns. Figure 3–2 shows four of the typically sought patterns to be implemented in Cloud environments.

Usage Patterns


Figure 3–2 Common Cloud Computing Usage Patterns

■ Augmentation (also known as 'Cloud Bursting') - This usage pattern implies a hybrid Cloud implementation whose components span Cloud environments. The primary objective is to augment committed capacity required to serve normal or baseline service demand with additional temporary capacity to serve peak demand when it occurs; thereby reducing total committed capacity to serve all demands. This is a very attractive usage pattern for reasons of cost saving, but it is usually complex to implement and may introduce an unacceptable amount of latency into the application. Further, this usage pattern is often cost prohibitive due to data transfer costs involved in maintaining application state across Cloud environments.

■ Shared Services - This usage pattern encompasses a broad range of services and refers to discrete components common to multiple larger complete systems. DNS is an example of a shared service. Shared services commonly implemented as Cloud services include information storage services and certain security services. Service-Oriented Architectures can often be leveraged for delivering shared services in a Cloud environment.

■ Development & Test - This usage pattern is driving much of the early demand for public Cloud services. It helps to minimize the initial startup costs of research and development by eliminating the need for dedicated infrastructure for new projects. If affords the researcher and developer the opportunity to experiment without assuming unnecessary risk associated with dedicated infrastructure. As the name would imply, software developed and tested in a Cloud environment will then be deployed for production use in a different environment, often a private Cloud environment.

■ Resource Sharing - This usage pattern is most typically associated with consolidation of application workloads and data onto shared hardware. Shared resources in a Cloud environment is an evolution of IT consolidation with the added capabilities of self service and elastic scaling of resource allocation.

There are myriad other usage patterns for Cloud computing, most of which are derivatives or combinations of the above four patterns. Disaster Recovery is another notable usage pattern that, depending on intended uses, might resemble Augmentation, Shared Service, and Development & Test usage patterns. Solutions to the most common patterns are readily available from a range of service providers and vendors.

Deployment Model


The major target usage patterns should be identified in the Envision phase of the Pragmatic Process for Cloud Adoption. Target workloads (discussed in the next section, Deployment Model) are mapped to these usage patterns in the Assess phase. The usage patterns are then refined and expanded into multiple use cases or user stories in the Design phase.

3.3 Deployment ModelA successful approach to Cloud adoption needs to make a distinction between software components that are well suited for Cloud and those that are less so. Further, components will ultimately be deployed in one of multiple possible deployment models. NIST defines four Cloud deployment models, each of which is found in operation broadly in different industry sectors.

■ Private Cloud - Operated solely for a single organization.

■ Public Cloud - Infrastructure, platforms, or applications operated as Cloud service is offered to the general public or industry on a subscription or pay-for-use basis.

■ Community Cloud - Shared by several organizations in a related 'community', e.g., academic research or industry.

■ Hybrid Cloud - The Cloud is a composition of two or more Clouds (private, community, or public) bound together by data and application interoperability.

For established enterprise IT environments, it would be unrealistic to expect wholesale migration to any Cloud deployment model. Certain workloads in the environment will lend themselves to migration better than others. Determination of what workloads should be considered for a Cloud Computing environment, and then which deployment model is best suited for each workload, are critical considerations in the development of a roadmap to Cloud. Oracle has developed an evaluation framework, called the Cloud Candidate Selection Tool (CCST), to help IT organizations with this task. The framework computes Cloud suitability of candidate components by evaluating each against architecturally significant criteria in the context of target usage patterns. Availability requirements, latency requirements, and statefulness of components are among the criteria considered in the evaluation. Figure 3–3 shows a chart from this framework, which is used to indicate which potential deployment model is most suitable for a given software component. Analysis with the CCST plots each of the components from an application, or application portfolio, into one of the four quadrants shown.

Multi-tenancy Model


Figure 3–3 Cloud Suitability Chart

Furnished with such an analysis, IT architects will likely identify clusters of components with corresponding patterns of criteria influencing the position and clustering relative to public or private Cloud deployment models. The framework also provides a basic indication of dependencies between components. IT architects can use this to identify potential areas of focus to mitigate those dependencies that may be hindering the (conceptual) deployment of an application to a target deployment model. See Appendix B for a description of the CCST and where to download the white paper, Cloud Candidate Selection Tool: Guiding Cloud Adoption on oracle.com.

This component-level analysis of the candidate workloads (as identified in the Envision phase) is an Assess phase activity that will help to paint a picture of which components should be targeted for Cloud deployment and in what order. The analysis will also identify which criteria most affect the architecture and which dependencies between components might prevent the desired usage pattern and deployment model for a given workload. Activities in the Design phase then specify strategies to account for the criteria in the architecture and to address the offending dependencies between components.

3.4 Multi-tenancy ModelOne premise of Cloud Computing is that services are accessed by multiple users with an expectation of isolation within the service from other users. Operators of Cloud services need a multi-tenancy model that reasonably meets these expectations while delivering the right level of performance and flexibility.

Described below are three archetypal designs for implementing database service in a Cloud. These designs belong to a spectrum of designs that vary according to means of isolation and degree of flexibility. Architecturally they differ primarily in depth of integration and can be adapted to other workloads beyond databases.

■ Shared Server - Typical of IaaS designs, this model relies on a hypervisor (or operating system container) to host multiple virtual machines on a single physical server. Tenant isolation is achieved through logical isolation of virtual machines at the hypervisor level. This model allows choice of operating system and everything that runs within it. From a Cloud tenant point of view, this model affords the greatest degree of flexibility.

Multi-tenancy Model


■ Shared OS - Found in PaaS designs, this model relies on consistency of operating environment among nodes in the architecture, i.e., standardized hardware and operating system. This model supports a high availability design implemented at the operating system level and, therefore, allows for databases (and other stateful workloads) to run across multiple servers affording greater reliability and scalability. Tenant isolation is achieved by allocating separate instances of the database (or other tier of the application) to each tenant. Cloud tenants of this model give up choice of operating system and server architecture but gain advantages of a more highly integrated platform, such as improved performance and reliability, and they dispense with the details of operating system configuration.

■ Shared Database - Typical of SaaS designs, this model combines all tenants into a single instance of the database. This model hides all the implementation detail of the database and underlying platform. Tenant isolation is achieved by a variety of means, typically implemented within the database and the application. While this model may allow for some degree of customization to enable variants of the application, this is the least flexible model and is often employed for a single monolithic application.

Figure 3–4 shows the three architectures just described.

Figure 3–4 Multi-tenancy architectures for database

Each of these architectures has attributes that make them more suitable for certain workload types and less suitable for others. Table 3–1lists some of the usage patterns and workload types commonly deployed to Cloud environments and the architectures most suited to those types. For example, an enterprise with a database schema common to multiple business processes, consolidation to a shared database may be the simplest approach. Whereas, database heterogeneity may be best served by a shared server architecture that provides the necessary flexibility, even with the implied administrative overhead and scaling limitations. Shared O/S readily supports database clustering so is preferred for mission critical workloads that require high availability.

Cross Cloud Defenses


The appropriate multi-tenancy architecture for each tier of the target workloads is determined in the Design phase of the Pragmatic Process to Cloud Adoption.

3.5 Cross Cloud DefensesAs the approach to Cloud adoption evolves within an organization, diverse Cloud services often come into scope, sometimes involving multiple Clouds and external public Cloud services. A security strategy based on the best practice of defense-in-depth1 relies on a foundation of common policies and procedures for securing the environment and data. Employing public Cloud services renders this foundation of security discontinuous, as depicted in Figure 3–5, which shows the layering of defenses typical of a defense-in-depth.

Figure 3–5 Discontinuous Defenses Across Clouds

Table 3–1 Multi-tenancy architectures mapped to service models, usage patterns, and workload types

Architecture Service Models & Usage Patterns Workloads

Shared Server ■ IaaS

■ Resource Sharing

■ Development & Test

■ Mixed / legacy

■ Rehosted applications

■ Development tool chain

■ Unit & regression tests

Shared Operating System

■ PaaS

■ Shared Services

■ Augmentation

■ Disaster Recovery

■ Mission critical

■ High performance

■ Distributed processing

Shared Database ■ SaaS

■ Shared Services

■ Augmentation

■ Disaster Recovery

■ Standardized & mature applications

■ Consolidated data

■ Tolerant of variable latency

1 Wikipedia definition of Defense-in-Depth: http://en.wikipedia.org/wiki/Defense_in_depth_(computing)

http://en.wikipedia.org/wiki/Defense_in_depth_(computing)

http://en.wikipedia.org/wiki/Defense_in_depth_(computing)

Cross Cloud Defenses


Cloud environments involve many enforcement points for security. Using common security practices across multiple data stores, applications, hosts, networks, and the physical environment is an essential strategy for large-scale Cloud security. Inevitably, Cloud service providers will use different security practices than private enterprise Cloud operators. Identifying these differences and addressing them through some form of integration or reconciliation is essential to the integrity of a defense in depth strategy. Among the technologies to consider for integration between private and public Clouds are Virtual Private Data Centers and Federated Identity systems:

■ Virtual Private Data Centers use virtual private network connections between the private environment and the Cloud provider to allow these environments to operate as one seamless virtual environment; thereby enabling consistent enforcement of certain security policies across Clouds.

■ Federated Identity systems allow an existing private environment’s identities and access controls to be used in a public Cloud service; thereby avoiding duplication of identity data in both environments and maintaining the integrity of role based access control and assured revocation of privileges when necessary.

The public Cloud provider must support these technologies for cross-Cloud integration in order to be effective. These technologies do not, however, address the full range of security enforcement points. Therefore, visibility into the service provider security capabilities and policies is critical if public Cloud services are incorporated into an organization's Cloud strategy.

4

Roadmap Essentials 4-1

4Roadmap Essentials

A roadmap identifies and plans the activities required to transition from the current state to a desired future state. An effective roadmap should impart coordination to multiple projects culminating in a common end goal that provides value greater than the sum of the individual projects. An enterprise's roadmap for Cloud adoption organizes the activities that will deliver the Cloud capabilities necessary to produce the desired benefits over time.

The organization and management of the entire lifecycle for any transformative IT initiative will benefit from the use of a methodology designed for bringing about the transformation. The roadmap is one tool in that process. This guide's definition of the Pragmatic Process to Cloud Adoption is intended to fill this need for end-to-end methodology and includes activities for creating a roadmap. However, this particular process is not compulsory, it is not comprehensive, and it is expected to complement any of the methods commonly employed by IT planners today.

The following sections describe major activities in the process that contribute to roadmap development. Key insights necessary to develop a rationalized and complete roadmap for Cloud adoption are discussed, as well as some of the key transformations to anticipate along the way.

4.1 Maturity AssessmentOne of the most important inputs to a roadmap tailored to the specific needs of an organization is the level of maturity in its capabilities. Using an established model of maturity, such as the Oracle Cloud Maturity Model, is an efficient means of assessing an organization's capabilities. Maturity Assessment is a critical Assess phase activity that is essential to the creation of a rationalized roadmap. The results of maturity assessment are used to define the structure and organization (timeline, projects, project goals, dependencies) of the roadmap.

The Oracle Cloud Maturity Model catalogs the capabilities involved in Cloud Computing along with the related measures of maturity and adoption needed to comprehensively assess the current state of these capabilities in the existing environment. These measures can then also be used to gauge the progress of projects within the Cloud roadmap.

The Cloud Maturity Model classifies related capabilities into eight domains that are shown in Figure 4–1. For a description of the Oracle Cloud Maturity Model see Appendix A.

Maturity Assessment


Figure 4–1 Maturity Model Domains

Although the Oracle Cloud Maturity Model is intended as a comprehensive assessment of capabilities required for Cloud computing, it may be convenient to focus on just those domains in the model that are most relevant to the unique combination of forces driving the organization's approach to Cloud adoption. A tactically focused approach, interested primarily in IT cost savings and minimal disruption to existing applications and processes, may find the greatest value in centering their maturity assessment on just two domains: Operations, Administration & Management and Infrastructure. In contrast, a strategically focused initiative looking for competitive advantage through faster time to market will likely get the most from centering their use of the model on the Architecture and Business & Strategy domains.

In any case, the Cloud Maturity Model is highly flexible, so its use can be tailored to the task of developing an appropriate roadmap. Effective use of the model will illuminate gaps and areas needing focus in order to navigate the transition from current state to desired future state. Figure 4–2 shows an example chart that plots Cloud Maturity Model capability scores. Highlighted in the chart are outlier points representing capabilities that may need close attention in the roadmap, either due to their low level of assessed maturity, or to a combination of relatively low adoption and higher maturity.

Strategic versus Tactical Path


Figure 4–2 Roadmap Focus Areas Identified by Cloud Maturity Model

Using this type of analysis, planners can prioritize remediation activities to address the gaps and explore ways to exploit the more evolved capabilities identified by an assessment.

4.2 Strategic versus Tactical PathMost Cloud Computing initiatives will follow a roadmap involving both strategic and tactical goals. An organization may want to pursue a strategic path to transform one application into a market breakthrough service by converting it to a self-service model, with fully automated deployment, and rapid elasticity, i.e., high level of Cloud maturity with adoption limited to one application. In parallel it may also take a more tactical path for roll out of server virtualization in order to increase asset utilization across the IT environment for an entire operating unit, i.e., wide adoption with limited level of Cloud maturity.

In this sense, the strategic versus tactical orientation should be factored into setting target maturity and adoption levels for each capability, i.e., identify those capabilities whose adoption needs to be expanded first, versus those capabilities that first need greater maturity before wider adoption is pursued. Figure 4–3 shows the arcs of strategic and tactical paths through increasing levels of maturity and adoption for Cloud capabilities. Determining which path to pursue for the capabilities associated with a set of IT assets (e.g., infrastructure, platforms, applications) provides a solid foundation for roadmap development.

Key Transformations


Figure 4–3 Strategic versus Tactical Cloud Roadmap

Choosing the right paths through levels of maturity and adoption begins with an analysis of the results from a maturity assessment, so it is primarily an Assess phase activity. It is probable that the choices of strategic and tactical paths will be revisited in the Design phase.

4.3 Key TransformationsThe growth in maturity and expanded adoption of Cloud enabling capabilities represent the key transformations that should be accounted for in a roadmap. The following sections discuss some of these key transformations, and how an organization might approach them.

4.3.1 Roles Shifts and AutomationTraditional IT operations are typically responsible for operating the IT infrastructure, platforms, and applications that run the business. This includes the monitoring and management of service levels to the end users of business services. In this traditional model, operations may call upon application developers to assist with resolution of production problems, but the developers' primary role is to add features to the applications.

New capabilities introduced with Cloud Computing, such as automated provisioning / deprovisioning, elasticity, and self service lead to an increased pace of change. This creates a challenge for IT organizations that are structured to directly manage all changes to any part of the running environment and may even discourage or impede change in the interest of maintaining stability in the environment. Dealing with this challenge involves shifts in roles and increased automation of operational tasks to effectively manage the pace of change.

4.3.1.1 DevOpsFor services running in a cloud, the traditional line between IT operations and application developer roles is often replaced by a practical division of responsibilities that is more situational and less rigid. A “DevOps” approach integrates development and operations into a single role or shared responsibility between two or more roles. This merging of responsibilities from development and operations is bolstered by the use of common tool sets across the disciplines. One tool to manage both application configuration and infrastructure configuration promotes integration of “Dev” and “Ops”. A shared version control system that contains system provisioning scripts as well as application code is typical of a well functioning DevOps approach. Common

Key Transformations


methods and tools for testing and quality assurance are also shared in a DevOps approach. A simple delineation of responsibilities typical of traditional roles and DevOps roles is show in Figure 4–4.

Figure 4–4 Delineation of Traditional and DevOps Responsibilities

The transformation to a DevOps approach involves skills development and possible restructuring of organizational boundaries, as well as retooling to a common set of tools. Adaptation of the governance model for IT will also be necessary. The transition to DevOps is a multi-phase effort. It begins in the Assess phase by identifying affected roles and processes and continues in the Design phase with refactoring of existing roles and processes or creating new ones. Improvements to the associated processes are ongoing in the Build and Operate phases. The roadmap should account for activities to handle the mechanics as well as the cultural impacts of this transformation.

4.3.1.2 Deployable EntitiesAutomation is not new to IT operations, but Cloud services demand higher levels of automation than traditional IT customarily provides. Operating applications in the Cloud involves management of services as semi-autonomous entities, comprised of multiple elements (binaries, scripts, configuration, dependencies), whose deployment is treated as a single idempotent transaction. That is, complete services are managed as deployable entities that are provisioned uniformly as a single payload to a baseline platform common to other deployable entities. The platform is not modified by a deployment, and changes to the entity are applied not incrementally to the running system, but as part of the entity that is redeployed. This notion of deployable entities, where configuration and code for multiple subcomponents are encapsulated in a template or assembly, is a critical underpinning of Cloud scale automation. Figure 4–5 illustrates the concept of deployable entities in the context of an overall logical view of Cloud architecture.

Key Transformations


Figure 4–5 Deployable Entities within a Logical View of Cloud Architecture

Deployable entities vastly simplify operations and serve as logical abstractions of the underlying detail involved in delivering Cloud services.

4.3.1.3 Model Management and Late BindingAbstraction involves a normalized method of either aggregating underlying subsystems into larger systems or disaggregating systems into smaller subsystems. Server pooling abstracts individual servers into an addressable collection of server capacity. Server virtualization abstracts the physical hardware by dividing the processing and I/O capacity of a server into smaller virtual machines. Higher levels of abstraction require complete representations, or models, of the underlying subsystems along with the policies, configurations, and relationships that describe the system. In complex environments such as Clouds, model management becomes an essential capability and is the basis for maintaining deployable entities, among other core building blocks of the Cloud architecture. For Cloud service developers Model management is the main point of interaction with the Cloud environment.

Systems that support high velocity of change across a large number of subsystems rely on model management to define up front those elements of a service that are fixed or expected to change infrequently (“early binding”) while allowing the dynamic elements of the service to be defined later when the service is launched. This “late binding” of components enables rapid release of new features and quick correction of defects. This, in turn, reduces the risk of releasing new code and removes barriers to continuous service improvement.

The creation of models representing Cloud services and major subsystems is a Design phase activity, as is the specification for model management infrastructure, which includes some form of model repository. Creation of models can be greatly simplified through the use of introspection that captures a metadata description of a running reference system to be brought under model management. The roadmap should address which models are needed, how they will be created, and whether introspection would be possible and useful in the model management function.

As discussed earlier, the upfront “early binding” activities are concerned with building the Cloud infrastructure and occur infrequently. These build-time efforts implement

Key Transformations


the operational capabilities of a Cloud such as resource pooling, rapid elasticity, and self service. The “late binding” of service components is concerned with applications running in the environment and occur on shorter intervals, as frequently as, say, once an hour. These run-time activities include application deployment, dynamic provisioning and deprovisioning of capacity, and responding to problems in the running service.

Management of the overall system - infrastructure and applications - is typically separated into multiple control planes. One for management of the Cloud infrastructure, which serves the needs of the Cloud operator, and one or more for managing the applications running in the Cloud, which serve the needs of the application owner.

4.3.2 GovernanceOne of the most challenging and often overlooked aspects of Cloud adoption is the governance of activities according to a plan. A roadmap is only useful if its prescribed activities are carried out in a coordinated and consistent manner. A Cloud program office should be established to administer governance of Cloud adoption activities in accordance with the roadmap. The Cloud program office is a steering function and may also have responsibility for financial management, resource planning, change management, and training related to Cloud adoption activities. The program office defines the constituent projects that make up a Cloud initiative, and the goals of those projects, in the Assess phase of the Pragmatic Process. Project sequencing and dependencies are then defined in the Design phase. Ideally, the Cloud adoption program office would be established as part of the Envision phase.

Using the basic framework of the Pragmatic Process and major early phase activities described in this guide, a practitioner can begin to develop a roadmap that organizes the specific activities for an actual Cloud initiative into phases. Refer back to Figure 1–1 for a guideline for organizing activities into phases.

As the roadmap takes shape, a continuous effort to maintain stakeholder involvement and support will help to streamline the process and to avoid rework and unnecessary compromises in later phases of the process.

Key Transformations


5

Conclusion 5-1

5Conclusion

Cloud Computing can produce transformational benefits over the course of long-range strategic plans or incremental improvements through tactical implementation of discrete capabilities. Whether an organization seeks to reduce the cost of delivering IT services or to increase business agility, Cloud Computing can provide a foundation for achieving these goals.

Organizations should take a pragmatic approach to Cloud adoption designed to deliver their specific desired benefits. Cloud Computing is not a one-size-fits-all solution. The value of adopting Cloud Computing is strongly linked to the degree to which the approach accounts for the organization's motivational and operating model contexts for Cloud. Likewise, the ROI and transformational effects of Cloud Computing depend on rationalized architectural choices informed by the forces leading to Cloud adoption.

This practitioner guide has presented guidelines for identifying these forces and has given guidance on key architectural decisions involved in the design and implementation of Cloud capabilities. Essential steps for creation of a tailored roadmap to Cloud were presented. These include an assessment of Cloud capabilities and the identification of key transformations to the operations and management of the IT environment. These activities must be accounted for in the roadmap.

Roadmap development should leverage available methodology and tools, such as the Pragmatic Process to Cloud Adoption, the Oracle Cloud Maturity Model, and the Oracle Cloud Candidate Selection Tool. A roadmap developed with the benefit of this guidance provides a solid foundation for a successful Cloud initiative.

A

Cloud Maturity Model A-1

ACloud Maturity Model

The Oracle Cloud Maturity Model covers the major tenants of a complete Cloud Computing strategy including both technical and business focused capabilities. It is designed to be used as a diagnostic of the current environment and can also be used in roadmap development to set measurable goals for the assessed capabilities. The model also serves as a framework for insight and discussion among various stakeholders in the Cloud initiative, leading to a shared understanding of current capabilities and the gaps to be addressed in the course of Cloud adoption.

The main elements of the Cloud Maturity Model are briefly described below. For a detailed description of the model download the white paper Cloud Maturity Model: Guiding Success with Cloud Capabilities here: http://www.oracle.com/technetwork/topics/Cloud/articles/index.html

A.1 CapabilitiesThe Cloud Maturity Model includes approximately sixty capabilities that capture the best practices that Oracle has collected over years working with a wide variety of companies. These capabilities provide the detail necessary to truly measure and guide the progress of a Cloud initiative.

A.2 DomainsThe Cloud Maturity Model uses the concept of domains to classify and organize the related capabilities. As depicted in Figure 4–1, there are eight domains in the maturity model:

■ Business & Strategy - Contains capabilities that provide the high-level constructs that allow the Cloud initiative to proceed. This includes such things as business motivation, expected benefits, guiding principles, expected costs, funding model, etc. Capabilities such as service selection and service level agreements gain relevance in Cloud initiatives as well.

■ Architecture - Contains capabilities concerning the definitions of the overall architecture and guidelines for various practitioners to ensure adherence to the architecture. Capabilities fundamental to Cloud architectures, such as resource pooling, interoperability, and self service are considered in the model.

■ Infrastructure - Contains capabilities concerning the service infrastructure and tools that provide the technical foundation for the Cloud initiative. Shared services, provisioning, and model packaging are particularly important in Cloud infrastructure.

http://www.oracle.com/technetwork/topics/Cloud/articles/index.html

Maturity

A-2 A Pragmatic Approach to Cloud Adoption

■ Information - Contains capabilities concerning the information aspects of Cloud, such as metadata management, as well as customer entitlements, and data durability.

■ Projects, Portfolios & Services - Contains capabilities concerning the planning and building of Cloud services, and management of the portfolio of services.

■ Operations, Administration & Management - Contains capabilities concerning the post deployment aspects of Cloud service i.e. the Operations, Administration, and Management aspects of the Cloud environment. This includes capabilities for the delivery of self-service functions and change management.

■ Organization - Contains capabilities concerning the development of organizational competency around Cloud Computing including the organizational structure and skills development, as well as executive sponsorship and organizational authority.

■ Governance - Contains capabilities concerning the governance structures and processes that support and guide the Cloud efforts. These include policy management, risk management, and auditing capabilities. Maturity and adoption of adequate governance is a leading indicator of the overall success of a Cloud Computing strategy.

A.3 MaturityThe levels of maturity used in the Cloud Maturity Model (from highest to lowest) are:

■ Optimized - Metrics are being consistently gathered and are being used to incrementally improve the capability. Assets are proactively maintained to ensure relevancy and correctness. The potential for market mechanisms to be used to leverage inter-Cloud operations has been established.

■ Managed - The capability is being measured and quantitatively managed via some type of governance structure. Appropriate metrics are being gathered and reported.

■ Systematic - The approach has been reviewed and accepted by affected parties. There has been buy-in to the documented approach and the approach is always (or nearly always) followed.

■ Opportunistic - An approach has been decided upon and is being opportunistically applied. The approach has not been widely accepted and redundant or overlapping approaches exist. It may be informally defined, or if documented, may exist primarily as “shelf ware”.

■ Ad Hoc - Awareness of Cloud Computing is established and some groups are beginning to implement elements of Cloud Computing. There is no cohesive Cloud Computing plan being followed.

■ None - There is no Cloud approach being taken. No elements of Cloud are being implemented.

A.4 AdoptionThe levels of adoption used in the Cloud Maturity Model are:

■ Across Clouds - The capability is established consistently across an entire 'enterprise' and may span Cloud providers (i.e., all applications, all data centers, or all organizational units, or multiple Clouds are using the same approach).

Adoption

Cloud Maturity Model A-3

■ Across Units - The capability is established consistently within an operating unit (e.g., applications, hardware environments across multiple data centers or resources across an independent operating unit or subsidiary).

■ Across Pools - The capability is established consistently throughout a pool of resources primarily defined by a common administrative purview (e.g., JEE applications, shared servers or storage environments throughout a data center, or an organizational division).

■ Across Collections - The capability is established consistently for a collection of resources primarily defined by the resource affinity or coupling in relation to a higher level function (e.g., suite of related applications, an HA cluster of servers, or a composite engineered system).

■ Discrete Resources - The capability is established for a single resource (e.g., application, hardware system, discrete organizational workgroup [e.g., project]).

■ No Implementation - There is no current implementation anywhere in the organization of the capability being measured.

Adoption

A-4 A Pragmatic Approach to Cloud Adoption

B

Cloud Candidate Selection Tool B-1

BCloud Candidate Selection Tool

The Cloud Candidate Selection Tool (CCST) can be used both as a framework for insight and discussion toward developing a Cloud architecture, as well as a diagnostic for an existing environment and to what extent it is amenable to a Cloud architecture.

Download the whitepaper, Cloud Candidate Selection Tool: Guiding Cloud Adoption, at: http://www.oracle.com/technetwork/topics/Cloud/articles/index.html

The basic elements of the tool are described below.

B.1 Evaluation CriteriaThe CCST includes 23 initial criteria used in the evaluation of application components. Criteria can be removed and additional criteria can be added for any evaluation. Example criteria used in the tool are Availability Requirement, Latency Requirements, Government Regulation, and Statefulness.

B.2 WeightingThe CCST allows customization of the analysis by applying different weights to each of the evaluation criteria. By default, all criteria are weighted equally.

B.3 Component ScoringEach component within the application being evaluated must be rated on a scale relative to each criterion. These resulting scores are used to estimate component level suitability for public or private Cloud deployment.

B.4 AffinityIn order to identify component dependencies, an affinity rating (none, low, medium, high) is assigned to each pair of components within an application.

B.5 AnalysisOnce all of the above data is input, an analysis is automatically generated which includes charts illustrating the deployment models most suitable for each component along with the dependencies between components indicated.

http://www.oracle.com/technetwork/topics/Cloud/articles/index.html

Analysis

B-2 A Pragmatic Approach to Cloud Adoption