In IT Service Management, the ITIL V3 philosophy stresses that “IT is the business.” This is truly realized for providers offering cloud computing services. There are a number of considerations that affect Service Management processes when moving to a cloud services model.
These traditional ITIL Service Support processes are tightly linked. In the cloud computing model, high expectations of availability are part of the model’s selling point, so rapid restoration of service becomes critical through the use of these processes and the Service Desk that performs them.
In addition, Change Management work flow activities can sometimes be done best by the Service Delivery Architects. They are the ones who determine the rules used by the automation tools rather than by the Service Management team, who traditionally performed those tasks now being done by the automation tools.
Configuration and Asset Management
With the Cloud service model’s standardized infrastructure and specialized tool sets, configuration is typically much simpler than that of an enterprise environment, with its extensive variety of hardware and software that must be orchestrated together. Many service-specific tools provide configuration capability for that service, thus reducing the amount of manual coordination requiredwhen compared to the Enterprise IT model.
Asset management is related to configuration management and, in a cloud service, has both a virtual component (e.g. tracking virtual resources) and a dynamic component (i.e., assets can change every hour) to its management process. Configuration Management needs to address a consumer view, (i.e., what assets belong to the service being consumed), a service view, (since assets equal revenue), and an enterprise view, (showing the business status of all cloud services being offered.)
Service Level Management
With a cloud environment, a single SLM process can exist, but separate SLAs and Service Level Packages should be defined, monitored, and managed for each service. The monitoring components for SLA related performance data will require tools that do not just rely on knowledge of the infrastructure, given the unpredictability of which cloud infrastructure components will actually be used. Instead, monitoring service performance and availability for ensuring SLA compliance must be done from the perspective of the user not from the perspective of the infrastructure.
Availability, Capacity, Continuity, and Security
The cloud environment’s “Provider-Consumer” model breaks the link between IT continuity and the customer’s business continuity. The Cloud service provider must offer to its customers a warranty of service continuity and make it part of the SLA that comprises the Service Level Packages offered by the service provider.
With a cloud service provider, the hardware and software environments are much more uniform and more easily managed. With the provider’s more homogeneous infrastructure offering a much more stable environment, the risks from a change to production are significantly reduced. With reduced risk, Cloud service providers can deliver modifications to services much faster and hence their agility becomes a part of the business model and a distinguishing capability in the market. It also implies that the Release and Deployment Management (RDM) process is often replaced by a different paradigm.
In the cloud model, scalability of capacity and performance is a core offering provided by cloud service providers and their SLAs should reflect this. To accomplish this real-time scalability requires two things on the part of the service provider.
For cloud services, availability is vital; much of the availability must be architected into the service. Where once the technical developers of a service could ignore the availability issues of their applications, leaving that to the job of the IT organization, cloud service availability is a key factor to its commercial success and hence must be built-in by the service developers and service architects working with the IT organization. With a combination of tools and resiliency built into the design and implementation of the service itself, the responsibility for availability must be shifted into the development lifecycle long before a service goes into production.