ServiceTechMag.com > Archive > Issue XLVII: February 2011 > Creating a Successful Cloud Roadmap
Stephen G. Bennett

Stephen G. Bennett

Biography

Stephen G. Bennett is a Senior Enterprise Architect at Oracle, and previously with BEA where he was the Americas SOA Practice Lead within BEA's consulting division.

Stephen is focused on providing thought leadership, best practices, and architecture guidance around SOA, and more recently cloud computing. He has co-chaired a number of working groups within the Open Group organization around SOA Governance and TOGAF/SOA.

Contributions

rss  subscribe to this author


Archie Reed

Archie Reed

Biography

Archie Reed is HP Chief Technologist for Cloud Security. He is a 20-year experienced manager and technologist, with a wide range of leadership, architecture, product, R&D, and implementation experience gained in high-profile environments.

Archie's previous books include The Definitive Guide to Identity Management, Migrating to Windows 2000 and Exchange 2000, and Implementing Directory Services, alongside many whitepapers and magazine articles.

Contributions

rss  subscribe to this author

Bookmarks



Creating a Successful Cloud Roadmap

Published: February 15, 2011 • SOA Magazine Issue XLVII PDF
 

Introduction

No matter what type of cloud services or deployment models you are considering as part of your overall IT strategy, you must have a cloud services adoption roadmap to guide your journey.

A cloud services adoption roadmap provides guidance that enables multiple projects to progress in parallel yet remain coordinated and ultimately result in a common end goal. The cloud services adoption roadmap consists of program–level efforts and a portfolio of cloud services. The program–level effort creates strategic assets such as the cloud architecture, cloud infrastructure, cloud governance, risk, and compliance (GRC) processes, and security policies that are leveraged across all the individual projects.

The program–level efforts provide and enforce the necessary consistency required to succeed at cloud service adoption. A delicate balance needs to be struck between too little control and too much control. With too little control, cloud services adoption will be haphazard at best. Too much control may stifle project teams, resulting in pushback or, in the worst case, outright defiance.

Initial projects drive the cloud infrastructure build–out and identify the initial cloud services. Follow–on projects leverage the cloud infrastructure and use the cloud services. Obviously, it is the follow–on projects that demonstrate the full value of adopting cloud services.

Without an adoption roadmap, there is a higher chance that you will encounter challenges that may undermine your organization's effort to realize the benefits of cloud services. This might lead to circumstances in which you are not making the most of the cost savings and agility improvements that you could have acquired.

Be aware that your initial cloud services adoption roadmap will be based on several assumptions—due to the cloud services market being in its infancy and your understanding of the affect cloud services will have on the culture of your IT organization.

Do not be afraid to revise your cloud services adoption roadmap as your organization and the cloud marketplace matures. Make sure that any updates to the roadmap are executed in an expeditious manner to ensure that they have the best chance of addressing any unforeseen challenges and risks without delaying your overall program. The rest of this chapter focuses on a number of organization characteristics that will affect the way you address and plan your cloud services adoption roadmap.


Crossing Your Chasms

Geoffrey Moore's book Crossing the Chasm used the 1957 technology adoption model and highlighted the different organization types (innovators, early adopters, early majority, late majority, and laggards) and that technology vendors had a significant barrier to overcome between the early adopters and the early majority.

Moore's initial model recognized that organizations fall across the spectrum, but he focused on one chasm. Today, there is much lower resistance to technology adoption because of the Internet, so the gap and potential time lag between the early adopters and the early majority is now much less. In addition, today's organizations can fall across more than one category, depending on their size, structure, and appetite for risk.

We have used the original technology adoption model and identified a number of chasms that organizations may encounter, depending on their organizational type and culture to adopting cloud services. Our goal here is to help identify each chasm and the benefits and risks associated with crossing each chasm. You can then use these chasms to identify which organization types describe your organization and to start molding your own cloud services adoption route.

Use Figure 1 to identify the types of characteristics that you associate with your organization, which in turn will assist with the type of chasms you have encountered or will encounter when producing or consuming cloud services. Without addressing these chasms, cloud services will either lose momentum or run wild in your organization. As previously stated, your organization may exhibit multiple characteristics.



Figure 1 – Cloud chasms

As with any model that attempts to characterize all organizations into a small set of categories, there will be exceptions to the rule. In essence, however, this model describes in a generic fashion the current and future penetration of cloud services in terms of organization types.


Risk Realization Chasm

Enthusiasts/innovators tend to jump headlong into cloud services without fully understanding the nontechnical aspects and significance to both IT and the business. Cloud services are not a purely technology play, and enthusiasts commonly miss opportunities to fully realize all the benefits made available by the use of cloud services.

Enthusiasts must understand that technology is an enabler and not the final solution and that their organization requires a cloud strategy that caters for disciplines such as enterprise architecture, governance, risk management, and compliance.


Wider Acceptance Chasm

Visionaries/early adopters want a strategic advantage and have the vision to understand the strategic business opportunity and impact that cloud services offer and utilize it to gain a competitive edge.

Visionaries have enterprisewide plans and build a roadmap accordingly. Although pilot deployments highlight the benefits that cloud services offer, visionaries encounter resistance when attempting to deploy on a wider basis within their organization. This resistance tends to center on the data privacy and security concerns that the rest of the organization has with public cloud services. In addition to this resistance, another area of concern for visionaries is that the level of benefits highlighted during the pilot does not manifest itself across all the divisions that deployed cloud services. This can come down to various reasons, including the following:

  • Additional challenges that the extra human involvement and interaction bring when crossing divisional boundaries.
  • The cloud management infrastructure cannot accommodate the large amount of cloud services and the federated distributed nature required.

For visionaries to cross this chasm, they must appreciate the need for a cloud GRC model that addresses the decision and accountability required. This requires the visionaries to have the will power and authority to address the political and culture change aspects of cloud services. In addition, visionaries need to provide a cloud architecture and engineering framework that can be applied when consuming and producing cloud services. Lastly, visionaries need to focus on the operational and post–deployment aspects of cloud services, including collecting, aggregating, collating, and presenting key performance indicators to improve engineering, operational, and the business aspects of cloud services.


Best Practices Chasm

Pragmatists appreciate the IT and business benefits of cloud services but are less risk averse to what they see as a high–risk proposition. These pragmatists wants to make sure that cloud service products have gone through multiple released versions and utilize standardized APIs and have matured to the point in which they are supported by the majority of mainstream products. In effect, pragmatists want a reliable standard. In addition, the pragmatists want access to the best practices and antipatterns that the enthusiasts and visionaries have encountered.

Pragmatists are risk averse and thus tend to consume cloud services from known focused cloud service providers with a reputation for providing quality, stable, and mature cloud services. To cross this chasm, pragmatists need to understand consuming and producing cloud services best practices and patterns and to have access to detailed case studies and references from organizations within their own industry.


Business Case Chasm

Conservatives delay any technical major decisions and tend to be followers. Therefore, for the conservatives to cross this chasm, they will wait until cloud computing hits the bottom of the hype curve and moves up toward the slope of enlightenment. The two key areas to assist with crossing this chasm is education and cloud business case development.

Education is paramount to the conservatives, especially around cloud costs and benefits and the differences between utilizing cloud services and traditional data center costs and benefits. Conservatives require a business case specific to their organization rather than taking a boilerplate example and plugging in numbers.

Conservatives tend to be hesitant because cloud services are classified as a disruptive technology, which conservatives are against because it requires political and culture changing events to occur within their enterprises. Conservatives would rather concentrate on the current–year objectives rather than on multiyear disruptive technology project that would affect the "business as usual" culture.

Conservatives will wait until cloud services becomes an established standard not only in their industry but also across multiple industries. At the end of the day, conservatives require a multitude of cross–industry cloud computing references with a detailed return on investment (ROI) business case before investing substantially.


Avoiding the Inevitable Chasm

Again, education is paramount to the late–to–market organization in detailing the differences between cloud services and past and existing technology strategies such as hosting, application service providers (ASPs), and virtualization.

Some late–to–market organizations will wait until cloud computing hits its adoption peak and then try to play catch–up with their competitors. This can be an expensive and disruptive proposition because cloud services require a culture change, which in turn requires time to feed in some learning experiences.

Because time is of the essence for the late–to–market organizations, this imposes more pressure on the late–to–market organizations as they try to speed the culture–changing process through. Therefore, the late–to–market organizations actually have a higher chance of failure.

The late–to–market organizations either don't understand the full scope of cloud services or believe that there is a more risk–averse manner in which to achieve the same benefits that cloud services offers. Late–to–market organizations believe that cloud computing is just marketing or hype and that the benefits and approach to cloud services is no different from ASPs or virtualization.


Planning Your Journey

To build your roadmap, you must fully understand your current environment so that you can make an informed decision and justify why moving certain aspects of your environment to the cloud makes sense.

As highlighted in Part III, "Life in the Cloud—Planning and Managing the Cloud," many areas apart from the technology aspects of cloud services must be considered as part of your overall cloud services adoption roadmap. Figure 2 highlights that your cloud services adoption journey and speed will be dictated by your risk comfort level, governance model, level of executive backing, size of organization, and the current maturity of your processes and procedures within your data center.



Figure 2 – Business commitment, time, and journey will vary from organization to organization

Conferences, magazines, analysts, vendors, and (we hope) this book have raised your awareness and excitement about the opportunities that cloud services offers to your organization. As with any disruptive technology, however, a level of hype is followed by disillusionment as your concerns elevate when you start to understand the consequences and challenges that cloud services brings to your organization. You could say "silver clouds, dark linings."

Many of the opportunities, risks, and challenges that your organization may encounter have been covered in earlier chapters. Fear can scupper your plans for strategically adopting cloud services. Therefore, as part of your overall adoption roadmap, do not underestimate the importance that change management will have in the successful deployment of cloud services within your organization.

Defining a cloud services adoption roadmap is no different from any other planning activity. As with all other planning activities, you need to fully understand the reasons why your organization wants to start utilizing cloud services. Depending on the process formality in your organization, this can lead to the development of a full–blown cloud services business case that documents the reasons and the cost, time, and quality benefits of cloud services.

There should be a combination of personnel from both the business and IT side of the house who should identify the strategic uses of cloud services for your organization. The path you take to adopt cloud services must be planned strategically and acted on tactically.

Your organization must understand the long–term goals and then make strategic decisions accordingly while at the same time delivering both incremental values to both the business and IT. In all likelihood, you will not fully realize the benefits of cloud services until you have executed a number of roadmap iterations. For example, noticeable cost savings due to economies of scale are unlikely to be met after one application has been moved to the cloud. Although you might not get all the cost benefits initially, these initial deployments give your organization the time to realign your operational and employee challenges.

You can then accelerate the deployment when internal resistance lessens. Until resistance lessens, a key success criteria for the execution of your cloud services adoption roadmap will be the level of executive support that you can garner and the willingness of your management teams to be innovators.

Make sure that your vision and expectations for utilizing cloud services are realistic for the maturity of your organization and the cloud services marketplace.

Because you will not realize all your goals on the initial project, it is probably best to view adopting cloud services on a multiyear horizon when focusing on a private cloud. Conversely, don't fall into the old trap of analysis paralysis and attempt to answer every question and discover every risk before proceeding. This can easily lead you in fear of pulling the trigger. Instead, time–box your effort around assessing your current environment.

An important part of cloud services roadmap planning is understanding what your current environment offers in terms of functionality, costs, time, and quality. This is a real challenge to many organizations. For example, many organizations are not fully aware of how many servers (physical or virtual) are currently in production or what their individual running costs are (e.g., electricity, employee costs, license costs). Without an understanding of the current situation, it is much harder to make informed decisions about whether your current pricing model such as asset ownership is better or worse than a charge–per–transaction pricing model. Metrics such as availability, utilization %, and application network and data requirements are needed so that you can analyze and compare the expected results from utilizing cloud services against the current environment.

In addition to understanding your current environment, you must identify and assess the risks, barriers, and opportunities you expect when adopting cloud services. Doing so enables you to identify the specific cloud requirements that your organization needs.

These requirements drive the creation of the overall program and project plans focusing on resource needs, costs, risks, time, and deliverables.

When defining your future vision for the adoption and use of cloud services in your organization, consider your high–level goals and principles that will be utilized to guide the entire cloud services adoption roadmap. These principles lay the foundation for the cloud architecture, and most important, are the basis on which cloud governance decisions can be made in a defendable and repeatable fashion.

The gap between your current state and desired future state identifies key program–level activities that should be given priority when defining your cloud services adoption roadmap. As stated earlier in the book, cloud services are not a panacea, and therefore not all applications can or should be moved to the cloud. Review your project portfolio to decide which projects will be implemented in the cloud. This tends to be an easier approach than taking an existing application and updating its design to be implemented in the cloud. Consider your data privacy policies, project complexity, cost, risk, and business criticality. Involve as many parts of the organization as required to identify the appropriate projects and to alleviate its concerns. This includes involving departments such as security, audit, and legal.

We cannot recommend which cloud services your organization should adopt because there is no one way to leverage cloud services for your business. However, organizations have typically focused on public cloud services that provide noncore functions that cater for, for instance, email, collaboration tools, on–demand testing environments, websites that have seasonal peaks in website traffic, and customer relationship management (CRM).

These low–hanging fruit cloud services have been chosen primarily for their benefits around cost savings, lack of any real integration work required, lower network latency and security requirements, and minimal political pushback. As both the public and private cloud services marketplace matures, so will the confidence levels rise of cloud service consumers, and with it we will start to see organizations use cloud services in other major areas. The speed of cloud service adoption and the types of cloud services consumed are dictated by your organization's characteristics, as discussed earlier in this chapter.

After you have identified and prioritized the appropriate projects, you can then derive your cloud service requirements from the needs of these projects, which can lead to the development of a cloud service consumption model that details which cloud services will be consumed (and how, by whom, and when). This leads nicely to your cloud vendor sourcing strategy; that is, whether you intend to fulfill the cloud service consumption model with internal services hosted within a private cloud, use a public cloud service, or use a mixture of the two that meets your requirements.


Conclusion

As stated earlier, we are in the early phases of cloud service adoption, and the marketplace has many hurdles to overcome. Nevertheless, organizations today are realizing the benefits that cloud services offer. As your maturity and comfort level increases over the years, adapting your cloud service adoption roadmap will be critical. This chapter has covered organization types and related characteristics when adopting cloud services and the potential pitfalls and risks you may encounter. This will give you a heads–up as to some of the near–term challenges you will need to address in your roadmap.

Key points to consider are:

  • A cloud services adoption roadmap consists of program–level efforts and a portfolio of cloud services.
  • Program–level efforts provide and enforce the necessary consistency required to succeed at cloud service adoption.
  • Without an adoption roadmap, there is a higher chance that you will encounter challenges that may undermine your organization's effort to realize the benefits of cloud services.
  • Make sure that your vision and expectations for utilizing cloud services are realistic for the maturity of your organization and the cloud services marketplace.

"This excerpt is from the eBook, 'Silver Clouds, Dark Linings: A Concise Guide to Cloud Computing' authored by Archie Reed and Stephen Bennett, published by Pearson/Prentice Hall Professional, Sept. 2010, ISBN 0–131–38869–X, Copyright © 2011 Pearson Education, Inc. For a complete Table of Contents, please visit: www.informit.com/title/013138869X