Conclusion
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.1 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.2 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:
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:
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:
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:
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.
_______________
1See Chapter 6 for a detailed description of the Deming cycle and Agile development.
2See Paul Deming, Out of Crisis. Cambridge, Massachusetts: MIT Press. 2000. Pages 88–90 express his views of the cycle.