Cloud Service Management Guide

Cloud Service Management (CSM) is the cloud version of Information Technology Service Management (ITSM). Traditionally, IT departments have had to manage both hardware and software in order to deliver IT services in an efficient and cost-effective manner. The drive towards budget optimization inevitably led to cloud services. This presents many IT managers with a conceptual problem – if they aren’t managing the infrastructure of the IT system, are they actually providing IT services?

ITSM never was about managing hardware and logically, if the IT department isn’t actually building the servers it runs, it can’t claim to be providing infrastructure but merely housing it. Providing IT services involves more than being the guardians of equipment. So, the fact that cloud infrastructure is located in another place doesn’t really change the aims and duties of IT service management. CSM is the same as ITSM but with the outsourcing of hardware provision made clear by the discipline’s title.

CSM doesn’t really change the concept of software delivery. Software-as-a-Service (SaaS) has been around for almost a decade and its deployment didn’t impact the requirements of ITSM or the ITSM framework, ITIL. Whether the IT department buys a software license and loads that package onto a cloud-located virtual server or pays a monthly subscription to get access to software hosted on a cloud server by the software provider, it is still managing responsibility for IT services.

Business strategies and IT services

Business practices have been moving towards cloud services for a long time. This is not a sudden move that ITSM has been unstable to keep up with. The move towards remote resources started off with the centralization of IT services. Remote IT administration has enabled businesses to remove the need for IT experts to be present on every site.

To a remote site, the central IT department acts very much like a cloud-based SaaS system or Managed Service Provider (MSP).

The use of remote services makes sense, particularly in the provision of continuity systems. Using off-site servers protects backup files from being knocked out by any accidental, malicious, or environmental damage that might occur at the main data storage site. Businesses have been deploying this off-site backup strategy for decades and best practices standards, such as ITIL account for these practices.

Business strategies that include the use of cloud services still require management by IT managers within the business. Some of the business functions previously performed in-house have been shifted out to third party providers, while planning and commissioning of IT services, cost tracking, the assurance of data protection, and the monitoring of performance standards still remain the responsibility of the IT department.

ITSM split

IT services management defines areas of competence within the responsibilities of IT provision. An IT department has a number of roles and ITSM defines the internal boundaries of each service. In many cases, those services fit together to present a single interface to the user community and in other areas, a specialized function contributes to other services performed by the IT department.

It is not unusual for an IT department function to exist to only provide services to other IT services and not have direct contact with the end-users of the business. ITSM best practices take account of this layered service model. However, dividing services into layers creates extra requirements for service level assurance. The IT department, as a provider of IT services, is used to dealing with end-user departments and working towards Service Level Agreements (SLA) and data protection standards. In the layered services model, the IT department is sandwiched between the SLA agreements with its user departments and the contracts signed with service providers.

The biggest issue this layering of services creates is a chain of responsibility. An IT department might choose to entirely outsource its functions to an MSP. The MSP, in turn, might decide to subcontract functions out to other service providers. The provision of the outsourced service might be facilitated by SaaS platforms. The SaaS provider might decide to outsource infrastructure provision to a cloud service. The underlying servers of that infrastructure system could easily be virtual and actually managed by a cloud storage service. This, initially straightforward scenario of utilizing an MSP ends up creating six layers of provision where once there was only one.

Legal liability

When the IT department signs an SLA with user departments, it needs to give assurances on delivery standards and system security on behalf of many other companies. In theory, the IT department just needs to be assured of the reliability of the MSP in the above-layered provision outline. However, a security failure in the bottom-level server provider that exposes the personal data of the top-level business’s customers, it is the top-level business that will be sued.

Cloud services provision creates legal complexities and it is the staircase of responsibility that traditional ITSM standards fail to address. Each business operating as a layer in the provision of cloud services need to be assured that the provider they chose is capable of delivering enough capacity with proficiency and security. The central document that binds a pledge of competent cloud service delivery is the service level agreement.

ITSM for cloud services customers

The top layer in cloud services management is the responsibility of the IT department of the consuming business. Deploying cloud services instead of originating services in-house makes the IT department a cloud services broker.

The responsibilities at this level are to tightly define service expectations, to ensure that those goals are properly expressed in the service level agreement, and to monitor the delivery of services to ensure that the SLA goals are met by the service provider.

There are ITSM tools available for businesses that also enable quality assurance programs for SLA monitoring. There are also Cloud Service Management (CSM) platforms available for service providers that include live monitoring interfaces for use by the customer.

The CSM framework

A CSM framework is very similar to the Professional Services Automation (PSA) systems used by MSPs. There aren’t very many pre-written CSM platforms available on the market. This is because there is no single business model for cloud services.

Consider an MSP, a SaaS provider, and a cloud storage service. Each type of cloud service has different levels of interaction with the client business and will need to serve a different community within the organizations for whom service is provided. Incident management is a bigger responsibility in the MSP category of cloud services. In many cases, the provision of a Help Desk service is the main job of the MSP. Cloud infrastructure providers aren’t expected to provide direct support to end-users. Instead, these services are integrated into the responsibilities of the client’s IT department. Therefore, the infrastructure provider is more likely to offer channels for infrequent contact by IT professionals.

Cloud service categories

In the case of MSPs, a combination of a Remote Monitoring and Management (RMM) service and a PSA package provides all of the software needed to run the business and so provides a CSM platform. The SaaS provider has a very similar operational model to a centralized IT department that serves several sites. A SaaS operation could function well with off-the-shelf Service Desk tools.

Only the pure cloud-based infrastructure provider operates a business model that doesn’t exist in on-premises equivalents. This category of business would benefit from a CSM system that doesn’t directly fit into the ITSM set of practices that are already available. This category of cloud service is not easy to quantify because the industry caters to a wide variety of clients and so need different client-facing functions on a service-by-service basis.

Take, for example, the cloud storage sector. Some cloud storage providers, such as Google Drive offer a structured space that is available to members of the public or to businesses. This is a consumer-oriented public and deals with individuals. Those services that cater to businesses offer a cluster of individual accounts with a management console added onto them, so they still need to open up communication channels to each end-user. At the other end of the spectrum are disk space packages, such as block storage, that only cater to applications running on the same cloud service.

Software services have become more complicated in recent years, thanks to the offloading of processing power needed for mobile apps. Microservices offer functions for apps that can also be integrated into Web pages. The difference between microservices and the typical function library is that they are hosted. Microservice providers don’t sell their code, they run it and allow subscribing software builders to trigger an execution through an API. Microservices are built on other microservices that are run on other servers, making the legal concepts of a chain of responsibility difficult to implement.

Cloud services management for these obscured layers of microservices needs to be built into the library of functions – API commands should have access to analytical functions that run alongside the main software in order to check on statuses and investigate failures. The support required by users of these APIs goes through two phases. The developers integrating and testing the microservices deployed in their new apps have different support requirements to end-users who trigger those services once the apps that include them are available for use by the public.

This shows that some cloud services have different audiences at different phases of their usage lifecycle. The providers of microservices can’t draw a dateline between the two types of service demands because some services will be in use by end-users all of the time while new apps are being developed using the same APIs. Therefore the cloud-based microservices industry requires two different CSM strategies to be running simultaneously.

The monitoring, management, and human interaction requirements of each type of cloud storage is different, therefore, it is difficult for any software house to construct a suitable CSM platform that caters to a wide enough market that makes the system economically viable.

The cloud services sector is very diverse and so the demands for a CSM platform are similarly varied. The broad spectrum of requirements for the industry means that there is no one-size-fits-all CSM solution. Each provider needs to adapt to existing best practices standards to suit its unique operating model.

Implementing CSM

The lack of a standard working business model for cloud services means there is no iconic brand in existence that provides the go-to CSM strategy for all cloud service providers. Cloud service managers are more likely to fall back on their experience that has evolved from classic product development and support in the IT industry or established working practices for IT professionals that are derived from Service Desk conventions.

A CSM strategy is more likely to follow classic ITSM standards, such as ITIL, up to the point where those systems fail to provide suitable models. ITSM practices never fit exactly to all of the needs of every type of IT provision scenario and so IT managers have long been adept at picking and choosing which processes to implement and which to skip over for lack of relevance.

Cloud services that have human elements, such as MSPs, or pen testers are better catered to in the field of best practices because they more accurately model the typical IT department with their multi-level contacts with other company departments and individuals. The providers of obscure, back-end microservices will find that much of the ITIL book is irrelevant to their working practices. In those instances, built-in monitoring facilities and comprehensive usage manuals fulfill assurance, SLA negotiation, and support requirements.

The key innovators of cloud services are more adept at creating new working practices than their counterparts in established business sectors. Internal best practices are less important to those innovators. However, as a service or product goes to market, those innovators bump up against the service level expectations of potential customers. These innovative providers are going to find that they will need to retrofit CSM into their working practices in order to win sales.

Cloud services and clients

There are four major points of client and service interaction in the cloud service management model:

• Provisioning
• Change management
• Problem management
• Incident management

The proper management of the interaction points will keep the customer satisfied. However, the main responsibility for most of these processes lies with the IT department – now the cloud services broker – rather than with the cloud service provider.

Provisioning

Cloud service providers don’t reach out to potential customers through sales reps. With a global market, all contracts are set through online forms. This business model presents off-the-shelf take-it-or-leave-it service level agreements.

Although many cloud service providers offer customized plans, the provider manages to take control of the SLA definition process. Only very large corporations with heavy purchasing power will be able to set their own terms. Ultimately, the service broker has the option of choosing between providers in order to find one that is able to provide a suitable SLA.

Cloud service providers cut costs and present an affordable alternative to in-house services by serving many clients. Thus, through process standardization, they are unable to offer a personalized service. The key to success for a cloud price provider is to properly identify the service features that a typical business needs and define SLA goals that are likely to attract customers.

Getting the balance right between standardization and attractive SLA goals is the key to success for cloud service providers.

Change management

Change management is the process by which the service provider adds on a new service. This process is not usually directly translated from the traditional IT department function through to a cloud equivalent. Change management remains the responsibility of the IT department, now transformed into the cloud services broker.

The cloud services broker, through meetings with end-user departments, draws up a set of service requirements. This is exactly the same as the existing process deployed in ITSM.

The implementation of change management is found in the provisioning process. The broker searches through available cloud service providers to see which can fulfill new requirements. If the change request is an expansion of existing services, such as adding on new users, the current service contract can usually be adjusted accordingly. If not, the broker will need to replace its current provider. For a completely new service, the broker will look to see whether existing contracting providers have that required service in their menu of services. If not, the broker will have to take out a separate contract with a new provider.

Over time, the change management and provisioning processes result in the broker managing many contracts with many different cloud service providers. In large companies with a wide It support requirement, the complexity of contracts management will soon become too complicated to handle manually. The cloud services broker will need a software tool to assist with contract management – this might also be a cloud-based SaaS utility.

Incident management

Incident management can be handled within the IT department of a company or it can be outsourced. The cloud services broker is responsible for choosing appropriate cloud service providers that seem to be able to fulfill the requirements identified in the change management process. The broker is also responsible for monitoring cloud service providers and ensuring that they meet SLA goals.

A business that selects different SaaS providers for each business software requirement won’t get a unified incident management point of contact for all IT services. Similarly, for infrastructure services, the brokerage will need to access several different provider help desks in order to manage service problems.

A solution to the piecemeal incident management problem is to outsource most of the functions of the cloud service brokerage is to outsource those functions to a managed service provider. This team will monitor infrastructure and deal with service providers. The MSP will also provide a Help Desk to handle end-user problems.

Problem management

Problem management processes are triggered either by reoccurring incidents or by capacity planning. Again, this process is the responsibility of the cloud service broker rather than the service provider. However, the problem resolution process requires coordination of effort and cooperation between provider and broker.

Where problems arise from capacity issues, an MSP will address these issues, negotiating service expansion with the broker. MSPs often levy their charges according to managed resources. Therefore, an expansion of resources requires a recalculation of charges. Similarly, the MSP can use the opportunities presented by problem management to offer add-on services to manage the introduction of new infrastructure capacity.

Repeated incidences could be an indication of the unsuitability of a selected cloud service. A cloud service provider can also be the cause of a problem if it consistently fails to meet the service level targets set out in the SLA. Therefore, there are two workflows that the broker can implement in the problem management process. These are to either contact the service desk or sales representative of the service provider to seek a solution or to replace the provider with a rival who is better able to fulfill the requirements of the customer.

CSM platforms

Owing to the varied nature of cloud service provision, it is difficult to define a software package that will support all types of businesses in this sector. Creating a platform of templates and workflows offers an opportunity to cater to a wide range of cloud service providers.

The flexibility of platforms doesn’t provide enforcement of a framework because no single strategy will cater to all types of cloud services businesses. There are very few cloud service management platforms currently available and many organizations will have to rely on ITSM tools or PSA systems instead.  

Cloud service management FAQs