Cloud computing is a revolution, a revolution built on high-speed, high-capacity global networks for communication and virtualization technology for flexibility. Network speed and capacity makes possible the separation of computing resources and resource consumers. Virtualization provides the flexibility to offer consumers the exact computing capacity they need within protected boundaries on shared hardware.

The result has been the appearance of huge datacenters holding massed computing resources that were once inconceivable. These resources are usually what “the cloud” means. In many cases, new cloud services do not duplicate existing services provided by computers distributed among consumers and enterprise IT departments. Online purchases from Amazon, instant information from Google, virtual communities on Facebook, and streaming movies on Netflix are all services that can exist only when supported by a cloud. The highly portable devices that have become so popular for personal computing—smartphones, tablets, and laptops—are all tied to the cloud, and they also have become dependent upon cloud computing as the availability of cloud-based services has increased.

Cloud business patterns are also disruptive because the cloud is more than a technology. It also is a way of managing and financing IT.

Prior to the cloud, most computers were owned and operated by enterprises whose business was not computers. These companies manufactured cars and airplanes; they sold insurance and offered banking services. They delivered freight and sold equipment in small and large towns and a myriad of other lines of business. Only a comparatively few computer-owning businesses manufactured computers, developed software, or provided computer services as a business. For most, their IT department and computing hardware were costs they could not avoid because their business depended on IT.

Enterprises always have had the option of delegating their IT to outsourcers, but that is not a viable solution for many enterprises because their dependence on IT is so profound they are uncomfortable with entrusting their IT to a third party. Cloud implementations are a form of outsourcing that is sort of middle ground. An organization can step out of the role of owner and custodian of IT equipment yet retain control and responsibility for IT services they implement on clouds.

The possibility of outsourcing to cloud providers drives basic changes in IT departments. Depending on the type of cloud service—IaaS, PaaS, or SaaS—different types of expertise and tasks are delegated to the provider. This delegation results in significant changes in the organization of the IT department. Costing for cloud services is largely based on metered usage; on-premises IT is typically based on staff time and investment in hardware. Since staff and investment do not correlate well with IT usage, cloud computing offers better alignment between costs and revenue.

Cloud implementations are fundamentally outsourced relationships. Consequently, contracts and service level agreements affect cloud implementations much more than they affect on-premises implementations. Expertise in writing, interpreting, and managing contracts takes on greater significance for IT as cloud usage increases. In cloud implementations, contracts can affect system reliability, capacity, performance, security, costs, and many other aspects of enterprise IT.

Cloud computing also opens up the possibility of improved IT services, new services, business innovations, even new lines of business, but to take full advantage of the technical and business advantages of cloud implementations, cloud projects often require a different approach to planning and design.

Unlike most innovations in IT, the cloud is as much a business innovation as a technical innovation. This implies that business and technology must work, and technology must work in tandem to realize the promise of the cloud.

Cloud implementations require cooperation between the business and technical sides of the enterprise. Service management best practices, such as ITIL, are directed toward effective cooperation between both technology experts and business managers and the design and construction of systems that are both technically efficient and supportive of enterprise business goals.

ITIL service management is based on the Deming cycle for continual improvement: plan, do, check, and act.¹ ITIL adapts the Deming cycle to IT with its own set of equivalent steps: strategy, design, transition, operation.

Many enterprise IT projects have suffered from a misinterpretation of the Deming cycle. They isolate activities in each stage in the cycle into independent steps that start with a set of inputs, transform the inputs into a set of outputs, assign each stage to successive teams, and evaluate each team on the speed and precision with which they execute their transformation within the narrow constraints of their assigned activity. This describes the waterfall development methodology. Deming himself argued against this approach. He interpreted each stage in his cycle as part of a process that ultimately leads to a satisfied customer. Stages must interact to achieve the goal of customer satisfaction, and no stage is complete until the customer is satisfied.² Figure 6-1 in Chapter 6 expresses this concept.

A well-planned and executed cloud implementation follows the ITIL phases with continuous feedback and interaction between each stage, not in rigidly isolated and independent steps. The deliverables from each step are still required, but the other stages in the cycle interact as the project progresses. The process is a continuous loop that improves stakeholder satisfaction in an evolving environment.

Many readers will recognize flexible progress toward customer satisfaction as a characteristic of Agile development. Chapter 6 discussed Agile development methodology and ITIL. The approach suggested there follows Deming’s lead in treating the stages in the cycle as occurring more or less simultaneously, interacting with all the others. The combination of the Deming’s interpretation of Deming cycle and Agile development provides a powerful tool for addressing the dual technology–business nature of cloud implementation.

The rest of this chapter will cover the steps in the ITIL cycle applied to the cloud.

Strategy

Strategy should be the beginning point of any substantial cloud implementation, including the adoption of a SaaS application specifically requested by a business division. Each stage in the ITIL process is important, but strategy occupies a special place. A cloud project must fit into the business and technical strategy of the enterprise. The project strategy must establish a clear expected outcome that will support business goals, align with existing technical infrastructure, and take advantage of the unique strengths of cloud implementation.

A strategy that meets these criteria must have attention on the executive level, perhaps the CEO and the board, because the consequences are often enterprise-wide. A cloud project can have profound effects on governance, finance, and sometimes the entire direction of the enterprise. Conventional technology can often deeply affect the enterprise, but cloud computing is likely to have wider effects because it is both a technical innovation and a business innovation. Even when a cloud application is identical in every functional detail to an existing on-premises application, moving to the cloud can have financial and organizational implications because the ownership and costing model will change.

If the financial/business managers do not understand these implications, their planning can be compromised and lead to issues that better planning would have averted. Understanding these implications may present a technical dimension that will require help from the IT department. For example, if the cost per month of running an application depends on CPU loading rather than lease payments on equipment, a financial planner cannot rely on his knowledge of lease agreements to project future costs. Instead, costs depend upon future process loads more than favorable or unfavorable equipment leases. Projecting those loads requires technical advice. In addition, he may have to consult other business experts because the cloud loads may depend on business projections, which were not relevant when cost did not depend on load. From the beginning, all the enterprise players must understand the strategy as the project progresses. This requires executive-level support and approval.

These are some key items in the strategy stage:

• Determine a strategy for serving the customers, clients, patrons, or other stakeholders in the enterprise. IT is just one part of this strategy. Typically, this strategy will be a product of enterprise planning.
• The strategy should delineate the parts of the service strategy that this project is intended to implement, including the strategic requirements and constraints on the project.
• If an IT service portfolio does not exist, establish one. An IT service portfolio is an executive-level document that describes each service supplied by IT. Minimally, the portfolio describes the functionality and value of each service, who manages it, who uses it, the service costs, and when it went into production. If the service has an expected termination date, that should appear also. The portfolio is the basic tool for viewing the scope and depth of IT activity and determining how a cloud service fits into the fabric of the IT environment.
• The strategy will not necessarily mention a cloud implementation. Later phases may indicate that a cloud implementation will best meet strategic demands. When a cloud implementation does appear in the strategy, the strategic reasons for the choice are important. If, for example, implementing in the cloud to reduce costs during business lulls is part of the strategy, the strategic deliverables should state it.
• A new cloud project must align with the strategy and coordinate with the services in the IT service portfolio, identifying new services to be developed, old services to be replaced or eliminated, and existing services to be used.
• The strategy should discuss high-level demand for the services supplied by the cloud project. Required capacities are derived from these demands.
• Concern over governance and management consequences, such as personnel changes, new auditing procedures, and security issues, should appear.
• Financial implications (including funding plans for developing the project) and where returns are expected are important to the strategy. Some discussion of cloud providers may appear in strategy but should focus on the strategically significant characteristics of potential providers.

Strategies change as business environments change. They may also change in response to technological changes that alter the finances of a project or open business possibilities that were not available in the past.

ITIL Design, Transition, and Operations

ITIL distinguishes a design stage, a transition stage, and an operations stage. In the design stage, the high-level goals and requirements in the project charter developed by the strategy team are transformed into concrete plans that direct the implementation of the project. The transition phase consists of implementing and placing the project into production. Much of the transition phase is devoted to testing the new project, training personnel, and adopting the project into production.

Design, transition, and operations are especially interdependent. Separating design from development and testing can have painful consequences. A project built to support a discarded strategy or a project that fails to meet production requirements are both bad, but a design that cannot be built or a development that does not meet requirements because the design was misunderstood is egregious. A design that does not keep up with changing operational requirements is even worse. Discovering that a project is of minimal use to customers after the development is complete is a tragedy. A fact of both business and technology is that environments always evolve and requirements change. A perfectly executed project that meets only old and irrelevant requirements has little value. Hence, design, transition, and operation must always be a mutually interactive effort. Nevertheless, the teams representing each of these stages have special concerns.

Design

The design team translates strategic goals and requirements into a design that will achieve the goals and meet the requirements. In theory, a design describes what to do but not how to do it. In practice, what and how often blend because what often implies a how. For example, a design may specify a communication protocol that is connection oriented and guarantees packets will be delivered in the order sent. The designer probably chose those characteristics because they are met by available protocols, and the design was probably built around the assumption that an available protocol would be used. In fact, a design that requires a new protocol would probably be unwise without an overwhelming reason for inventing a new protocol because a new protocol has wide implications for development, testing, and support. Something as potentially expensive as a new protocol should be justified by both design requirements and consultation with the developers who will be assigned to implement it. Their implementation plan may affect the performance, reliability, and long-term maintainability of the service as well as the cost. These considerations may even require revisiting the strategic plan. Although returning to strategy may seem calamitous, it is better done early in design, not after a deleterious service is delivered to consumers. This is another example of the interdependence of the phases.

The following are some specifics of cloud design:

• Designs must support the functionality described in the strategic plan. This may involve indicating which processes will be implemented on a cloud, which will be traditional on-premises processes, plans for bursting to or between clouds, and requirements for communication between all components.
• Business considerations beyond functionality, such as metering usage and assigning costs to business divisions, should be addressed in the design.
• Design for manageability and limited complexity.
• Designs should indicate which applications should be supplied as SaaS. Choosing between IaaS and PaaS can be left to the transition team, but a SaaS decision should be made in design. Strategy may dictate SaaS also.
• The design should describe the functionality, inputs, and outputs for each process. The human interactions and the business requirements for each process are part of this description. Consideration should be given to the distribution requirements of processes including network limitations, data consistency, disaster recovery, and failover.
• The scalability requirements and expectations should appear in the design. Direct special attention toward horizontal scalability, cloud elasticity, and the possibility of expansion and contraction between clouds.
• Geographic distribution influences reliability and performance of processes and data availability. The design should include these aspects.
• The design should include integration requirements and an integration architecture. It should also specify how existing integration architectures are to be included in the design.
• The design should spell out availability, capacity, performance, and security requirements. Note that the availability specification includes enterprise requirements that indicate the risks and dangers involved in process failure or degradation. Disaster recovery and failover requirements also appear here. Security requirements may have broad implications for the design and must address process access as well as at-rest and in-transit data security. Service level requirements and service contract requirements that derive from the strategy or design should appear.

Transition

From the developer’s point of view, transition is where the work is done. During the transition phase, developers translate the design into working code. The quality assurance team tests the code. A training team prepares training materials such as manuals, online and offline classes, and online help. The training team also trains the trainers on the new service in preparation for instructing the users who will work with the new software and services. A rollout plan provides for the orderly transfer of the new service into production. Eventually, the operations team receives responsibility for the new service.

Neither Deming, Agile development, or current DevOps practice advocate a practice that executes the transition phase as a discrete series of steps. They all suggest that the transition phase, as well as all other ITIL phases, should be a collection of simultaneous and interactive processes. See Chapter 6 for a more detailed discussion of Agile, DevOps, and ITIL. The testing team must be familiar with the enterprise strategy, the design, and the implementation to assure that tests exercise the important and vulnerable aspects of the service rather than dwelling on easily tested minor issues. A test that trips up development with a different interpretation of the design is a pointless waste of time. Both development and testing must agree on the design from the beginning. Development must work with the testing team to build in instrumentation that will verify that the code is behaving properly. Trainers often have profound insight into user requirements and interaction with existing services. This insight should inform design, development, and testing. The operations team and the consumers of the service are the ultimate judges of the system and should be involved from the beginning. The simplest and most effective way of achieving these goals is Agile-style incremental development that is released to all the players for examination, testing, and feedback.

Here are some considerations for the transition phase:

• All the players must keep the strategy and design documents in mind. An issue discovered during coding, testing, training, or rollout planning may require redesign or even reconsideration of strategy. Addressing the issue immediately will be more efficient than dealing with it after the project is in production.
• When scalability is an issue, assure that the scalability built into the product aligns with the scalability goals in the strategy and design. When cloud elasticity or bursting from cloud to cloud is anticipated, be aware of the requirements of the cloud platforms you intend to deploy on.
• Choose the right form of virtualization for the job. Containers use the underlying physical hardware more efficiently and are easily portable but are less inherently secure than virtual machines and may not have all the needed functionality. Make the choice carefully, although current trends are to use more containers.
• When development must decide between an IaaS and PaaS platform, consider the strategic direction of the enterprise as well as development needs. Outsourcing the ownership and maintenance of utilities to the PaaS provider should align with enterprise strategy. Also, consider governance issues such as ownership of data, auditability, and security.
• Base decisions on storage on anticipated volume of data and need for rapid access. Also, consider cost and governance issues such as ownership of data, auditability, and security.
• Messaging and event strategies are vital to the long-term success of integrated systems. Make decisions based on the entire system. Consistency is often more advantageous than a collection of messaging systems tailored to individual processes. Consistent use of a commercial or in-house messaging bus or hub may be a good long-term decision.
• The development group must work with service management to craft service level agreements and service contracts that will meet strategic and design requirements. Development must include instrumentation that will detect service violations.
• Testing should begin as early as possible. Even paper designs can be tested against requirements. When functionality is delivered to customers in small increments, the customer’s comments become part of the testing process.
• Training groups should prepare users for the cloud experience, including new support expectations, such as continuous delivery that enhances services continually instead of incrementally by releases.

Operations

The operations team should participate in or be aware of every stage of a cloud project. The operations team will be held accountable for a successful cloud project longer than any other group in the ITIL cycle. The work of the preceding teams will be lost if operations cannot successfully deliver the planned services. Therefore, the previous stages should make every effort possible to assure that operations will be happy with the results. The only group more important than operations is the consumers. The previous phases are obliged to pay attention to the concerns of operations at all times. Even the strategy team must pay some attention to operational requirements such as provision for adequate facilities and network connections for operating the anticipated services.

At the same time, the operations team is obligated to provide useful feedback to the strategic, design, and transition teams. Without feedback from operations, the Deming cycle is incomplete. Not only must the operations team manage the delivery of services, they must also monitor the success of the service so that the service can continually improve.

The operations team should do the following:

• Maintain a service desk. The purpose of the service desk is not just to expedite the resolution of operational issues. It must also record and classify issues for improvement of the system, including “out-of-band” requests that might indicate gaps in the service portfolio.
• Collect resource consumption and performance data.
• Detect and report to service managers on service level violations.
• Work with cloud provider to take full advantage of cloud features such as failover and elasticity.
• Provide continual feedback to the transition, design, and strategic teams on all aspects of the performance, reliability, and acceptability of the deployed services.

Summing Up

Service management is always a cycle, not a single project. The business of services is never complete because business environments always change. Sometimes the change comes from the outside in the form of new customer demands, the availability of new resources, or new regulations. Competitors rise and disappear. Leaders revise strategy based on new external environments, the experience of operations, and the vision of business to come. Design and transition follow strategic direction and inject real experience into strategy. Operations absorbs the results of design and transition and delivers services to consumers whose reaction drives strategy.

From the standpoint of service management, cloud implementations are a form of outsourcing made possible by high-bandwidth networks and virtual systems. They can shift the expense of IT from capital investment to operational expense. The cost of cloud-implemented services can track more closely to business demands than on-premises services. Clouds can provide extensive capacity at low cost, which offers technological opportunities that would otherwise be unavailable. Scaling on demand is a basic property of cloud architectures. Scaling on demand is critical to the online business world that must respond to consumer demand that varies unpredictably. Clouds also enable services that are available anywhere, such as music services and document sharing.

Like all technology, cloud implementations can be done well or not so well. The rules for building cloud implementations are not greatly different from conventional projects, but the expectations from a cloud implementation are justifiably high, and the consequences of a design that does not consider the unique characteristics of clouds can be onerous. Successful enterprise cloud projects require a systematic approach to implementation following established principles of service management.

_______________

¹See Chapter 6 for a detailed description of the Deming cycle and Agile development.

²See Paul Deming, Out of Crisis. Cambridge, Massachusetts: MIT Press. 2000. Pages 88–90 express his views of the cycle.