By now you have heard the hype about providing services in the cloud. You cannot ignore it — the cloud is everywhere and organizations are gathering in conference rooms to determine how they can take advantage of the shift from traditional to utility service delivery. One of the key questions relating to the cloud is not necessarily, What is the cloud?, but rather, What can I do in the cloud? Even watching your favorite television show can lead you to this question as you watch advertisements of people using the cloud to collaborate, share videos, and access services to accomplish their goals.
Whether or not the cloud is something new or just something old re-branded is an academic question. What is important right now is that IT organizations figure out how to adapt and mature their design capabilities to meet the demands of the business. When designing for the cloud, or for any other service strategy for that matter, there are elements to consider that can lead to better success. The ability of the cloud to deliver the services necessary to meet business expectations rests on IT. While all IT departments use an approach of some sort to define and design technologies to deliver services, few organizations address some of the more challenging elements required to ensure operable services meet customers’ requirements. Elements such as: 1) establishing service level expectations; 2) transition planning; 3) supporting services in the cloud; and 4) monitoring and management in the cloud.
Establishing service level expectations
Any discussion relating to services must start with utility (fit for purpose) and warranty (fit for use). The basis for a service strategy is defining what the business wants to do in terms of expectations and requirements. By the time you arrive at the design stage, you should have already determined how the business uses services, the demand for those services and whether there are options in place to deliver them — or if a new design needs to be developed.
It is premature to consider cloud, or any other delivery option, before the service requirements are completely understood. A more mature method of defining requirements focuses on what the services will enable the customer to do vs. how the services will be delivered.
Early in the design stage is the time to determine and agree on the levels of service that will be expected by the business. A good design brainstorming session will address how the services are used: that is, the utility of the services. Questions to ask include what they want to do and where, when, and how they plan to access it. For example, do they want to collaborate online? Quote, bill or order goods? This discussion will flesh out the customer experience in terms of how they use the service and their corresponding expectations. Once documented, these expectations can be used to facilitate a design that meets the requirements.
Understanding the service utility is the foundation for understanding the business needs.
The service requirements should also relate to the warranty of the services. Differentiating between purpose and use is a key concept in designing service level agreements (value can only be achieved when both utility and warranty requirements are determined). The warranty requirements focus on when the service is available, whether it has enough capacity (now and in the future), continuity requirements and whether the service is secure. Establishing understanding and gaining agreement on these terms is the basis for developing achievable service levels that deliver value.
Of course, defining these requirements is an iterative process as you move through the design phase and determine whether the requirements can be met. It is a good practice to evaluate the requirements throughout the service lifecycle to ensure they are meeting expectations. Take advantage of processes such as Service Catalog and Service Level Management in the Service Design phase of the ITIL v3 Service Lifecycle to help you establish the process you will follow to document services.
The service catalog and the service design package are good places to document the utility and warranty requirements. Once fully documented you now have the foundation for design considerations including whether or not the cloud is an option.