As Amazon Web Services (AWS), the market leader in public cloud services, paves the way with industry good practice for cloud service management, their AWS Managed Services offering can be used to truly better understand the required changes for IT service management (ITSM) in the context of cloud – whether you’re using AWS services or not.
You’re probably hearing more and more talk about how the cloud affects ITSM but not necessarily what you need to do, meaning, there’s lots of information on the fact that there are new challenges and that things will need to change, but not enough on what this would actually entail.
There’s no cloud-focused version of ITIL yet. But there’s something that can be consumed to better understand the impact of cloud on ITSM – the new AWS Managed Services (“Infrastructure Operations Management for AWS”) offering.
And let’s not assume that this is a one-way need for learning – because, while ITSM pros might need to understand how cloud impacts their role, cloud pros will also need to understand more about service management.It's not a 1-way street: #ITSM pros might need to understand how #cloud impacts their role & cloud pros need to understand service management to do their role! Click To Tweet
So here’s what I think we need to do.
The first step in learning more about ITSM in the context of hyperscale cloud (via AWS Managed Services) is to, as with all AWS services, read the FAQs. And remember that you can learn from the AWS online documentation – to improve your IT service delivery and support – even if you aren’t, and don’t plan to use, AWS Managed Services.
But please read the AWS documentation in the context of your own organization. For example, for organizations:
You’ve probably heard the ITIL “people, process, and technology” mantra for better ITSM throughout your career – and it’s not likely to go away any time soon, even with the use of cloud service providers. It also provides a great way of considering how the AWS Managed Services documentation can be consumed, and then used, to improve your ITSM (and the resulting business outcomes).
For the people aspect, it’s highly recommended that someone assumes the internal role of the AWS-Managed-Services-defined Cloud Service Delivery Manager and to not just have the AWS-provided one (which of course cannot be the case if AWS isn’t your organization’s cloud service provider of choice).
This internal position shouldn’t be an old-fashioned, risk-averse, and robust (unchanging) style of role. So, try not to think of an old-school IT Ops Manager – this Cloud Service Delivery Manager role does need to have some of the old robustness but it also needs to embrace the anti-fragile world of DevOps and microservices.
The role, or the person(s) in it, also needs to de-risk cloud service consumption for the business while not getting in the way of cloud consumers by way of slow and onerous approvals and controls. And if AWS Managed Services is used, then this internal role should be positioned to work well with the AWS-allocated Cloud Service Delivery Manager resource.
For the process aspect, the AWS Managed Service is an ITSM-friendly combination of ITIL and cloud. Hence, it can be used even if AWS services aren’t.
As with most things cloud, a shared responsibility model is in place and it’s clear what the service provider (AWS in this case) needs to do and also what the customer needs to do. In the words of AWS:
“AWS Managed Services manages endpoint security, directory services, and critical network appliances, but does not manage the installation, configuration, or monitoring of applications.”
In particular, when it comes to ITSM, it’s imperative for the business to realize that they are responsible for the availability of their services running on the cloud, not AWS. For organizations used to traditional outsourcing, and holding providers to account for everything, this is a big change.
Another change for organizations using ITIL with hyper-scale cloud service providers relates to service level agreements (SLAs). Because it’s dangerous for a business to think that they can create a custom SLA with a hyper-scale provider such as AWS that will force the provider to go beyond their uniformly-agreed responsibilities.
This is a common misconception as seen with the February 2017 AWS S3 outage, where customers had to prove that their business was impacted and the only compensation was a small amount of AWS S3 credits – with nothing for EC2 or any loss of business.
For the technology aspect, the AWS system is driven by APIs and most, if not all, of the leading IT management and ITSM tool vendors have capabilities to integrate with AWS. An obvious example is using a service catalog to limit/offer services to cloud consumers, such as HR onboarding of new staff.
Some more-antiquated tools might not be cloud-friendly though, in that they don’t understand AWS constructs such as regions and availability zones, or they might not be integrated with APIs. Thus, tools needs to be assessed against AWS, or any other cloud service provider services, on a product-by-product basis and non-cloudy tools should be considered for deprecation and replacing.
This blog just scratches the surface of how hyper-scale cloud affects ITSM, and how AWS Managed Services can be used to understand and make the required changes (whether or not AWS services are used). Hopefully the pointers to the AWS resources will help you and your organization.