How to Plan the Transition to Cloud Computing

Organizations are always faced with a steady pace of change. There seems to be a new approach, methodology or design concept popping up every day. Some are completely new and some are re-branded with a fancier name. Today, one of these new design concepts, utility services, (better known as cloud computing) represents a shift from the more traditional technology-based solution, to more of a service-based solution.

The basic concept is to provide services on-demand as more of an all inclusive utility cost vs. the traditional shared cost model that most organizations opted for in the past. It’s a good solution for many businesses, but before management makes the decision to jump into a new technology, it’s wise to first step back and plan. Using a service focus with defining frameworks such as ITSM and ITIL, leaders can make a more informed business decision.

Cloud appears to answer the questions IT organizations have long been asked --how much does a service cost and how fast can it be subscribed and provisioned? As consumers, we are accustomed to utility-based services where we pay a fixed, or usage cost, for a subscription. Examples of this include natural gas, electricity and cable television services. We can get basic, premium and platinum subscriptions as well, for an additional cost.

There are usually a couple of ways to pay for these services -- at a variable rate based on the amount consumed, such as natural gas and electricity, or at a fixed cost, based on selections, such as cable television. As IT organizations continually look for ways to provide services to their customers, the concept of a utility cost is intriguing. However, there are challenges that IT organizations face when evaluating whether or not they can provide services using cloud computing. They include:

• Using a framework
• Defining service requirements 
• Documenting the service requirements and service attributes
• Writing effective service-level agreements

Getting Started

Using a framework - First and foremost, decide on a framework that focuses on the various components of the plan. One such framework is IT service management.

Figure 1 shows an ITSM framework where processes, people and tools/technology are supporting components of services (whether business and/ or technical). Within the process component, the IT infrastructure library (ITIL) service lifecycle can be leveraged to help define the best practice process activities for the journey (see Figure 2).

The time and energy saved by leveraging an existing framework will pay off in the future as it can guide the effort by aligning to best practice activities that can ensure a smooth transition. Each phase of the lifecycle can be used to define the activities that lay out a path to service maturation. Once an organization has made the decision to adopt cloud computing, the next step is to focus on the processes contained in service strategy and service design.

Defining service requirements - In this phase, it is important to understand utility and warranty as it relates to an organization’s service strategy. ITIL v3 defines utility as “fit for purpose” or, in other words, does the service meet the customer’s expected outcome? Whereas, warranty is defined as “fit for use”; answering the question of whether the service is usable.

An example of utility related to home Internet services is ordering goods, paying bills, collaborating with friends and family, sending e-mails, and so on. Warranty of home Internet services is whether appropriate availability, capacity, continuity and security exists. When utility and warranty are guaranteed, then value is created. It’s not possible to plan for one or the other -- there must be both. It is absolutely necessary to address the question of utility and warranty when considering a transition to a cloud computing environment.

Within the service strategy phase of the lifecycle, the service portfolio process defines various activities that can lead to a path that ensures utility and warranty are provided. The service portfolio is where service requirements are defined and analyzed. Using these process activities, the purpose (utility) of the service is defined. These are the specifications of the service that normally relate to business processes and outcomes. The specifications are always in business terms, not technology. The manner in which a service is delivered is not a discussion topic at this point in the service definition process, however, expected performance requirements should be discussed. After the service requirements are defined, they are analyzed to determine if the capabilities already exist to deliver the service, whether the capabilities need to be developed, and whether the service should be approved, thus moving to the next stage in the process.

Documenting service requirements and attributes - Once a service is approved, it now moves along the lifecycle to the service design phase. This is where the service is chartered, designed, developed, built, tested, released, and operational and is entered into the service catalog. The goal during this phase is to design for warranty to guarantee utility.

Various processes interact during the design phase, such as availability, capacity, continuity and information security management. This is where the decision regarding cloud computing can be made. As each and every requirement of the service is evaluated, decisions are made regarding the processes, people and technology that will be required to support it.

The caveat related to cloud, however, is having a complete understanding of all the service components to determine if the cloud is a viable option. For example, a business requests online meeting services to help reduce travel costs and collaborate on demand. There are various offerings for software-as-a-service (SaaS) that can provide meeting services with a fixed cost per month, where the services are all inclusive. When evaluating the option to use SaaS vs. an internal technology-based solution, organizations need to know the costs associated with delivering the service so they can make an educated decision as to which option is more suitable.

During the evaluation, defining the service requirements and attributes is necessary. All requirements need to be evaluated such as the technology/resources required, available support, service level requirements, security, upgrade options, subscription process, incident handling and change management ... to name a few. If the utility and warranty to support the meeting services via the SaaS (or cloud) option are comparable or better, then the decision to move to that option becomes clear.

Writing service level agreements - During the design phase, an additional process, service level management, can be leveraged to define the service level agreement (SLA), operational level agreements (OLA) and underpinning contracts (UC) that will be agreed upon to deliver the services.

The difference between these three documents is an SLA is an agreement between the business and IT, an OLA is an agreement between IT domains, and a UC is an agreement with an external provider (such as the SaaS, or cloud, provider). These documents are the entities that will be used to govern whether the requirements of the services being provided are met.

Writing effective SLAs is always a challenge, but the main goal is to document the level of service that is being provided and define the roles of both parties in relation to the service requirements. Negotiating SLAs with the business should transcend the entire design phase of the lifecycle as shown in Figure 3.

Initial discussions with the business will define the requirements, which will then be aligned with a design that can meet those requirements, followed by a validation step where the SLA is finalized, agreed upon and signed by both parties. From this point, the service then moves to the transition stage, where the planning will begin to transition the service to production.

Too often, IT organizations focus more on the technology than service. A service-focused decision defines all the requirements in the ITSM framework, aligning services, processes, people and tools/technology to deliver and support the business requirements. By leveraging various processes within the ITIL v3 service lifecycle, a decision on whether the cloud is an option is driven by business requirements and follows a defined process. Using defined frameworks such as ITSM and ITIL, a wiser decision for cloud can be made.

As Director of Forsythe's IT service management practice, Mike Tainter focuses on IT service management, ITIL, operations management, process design, IT operations support system development, and IT logistical requirements for a wide variety of organizations.