I’ve been doing a lot of thinking about ITIL and whether or not it is fit for purpose for DevOps. The logic I keep hearing goes like this - you shouldn't confuse the ITIL approach with the implementation; the ITIL approach is building blocks; these building blocks are easily applied to DevOps. I’m not convinced. First, ITIL is fundamentally time bound. For example, ITIL v1 was primarily around applying mainframe disciplines into the emerging world of Client/Server, ITIL v2 was more about ensuring quality of output across complex operations environments and ITIL v3 was more about consolidating established operations principles and shifting the focus to “how does IT contribute to business value?” Isn’t it a stretch to make best practices for previous waves of technology apply to DevOps whereby infrastructure and operations professionals are not silo’d but play an active part in delivering customer products and services along with application developers? Second, ITIL zealots are convinced that these ITIL “best practices” are some kind of complex baking recipe and if all steps are not followed to the letter, the end result will be a failure. This means that for many, the approach and the implementation of ITIL is tied. This leads me to my question: Is ITIL fit for purpose for DevOps? To return to the analogy of building blocks, let’s use the ultimate of building blocks – Legos. When I think about ITIL and service management, what most enterprises have implemented, looks like this:
Everywhere I turn, I hear about how some product or service is geared towards DevOps. It feels like the “cloud washing” we all just went through. “Cloud washing” continues to cause problems as even today it remains difficult to understand how products and services really affect our ability to create and manage clouds and applications in the cloud. This “DevOps washing” is causing the same problems and it becomes harder and harder to understand what DevOps really is and how it applies. I spent a morning breakfast presentation just talking about the definition of DevOps with a group of technology management folks for over an hour!
I’ve spent the past year being the Ops part of the Forrester DevOps story. We have been hard at work and released a playbook called Modern Service Delivery (to match the Modern Application Delivery playbook coming from my Dev partner Kurt Bittner) and we are approaching the end of creating the foundation of the DevOps story from planning to optimization. We define DevOps as:
“DevOps is a set of practices and cultural changes — supported by the right tools — that creates an automated software delivery pipeline, enabling organizations to win, serve, and retain customers.”
If you are serious about DevOps, you can cut through the noise of the “DevOps washing” and start with several practical tips to get you moving in the right direction:
At my wedding reception (I will NOT be saying how many years ago), another couple and my husband and I took the dance floor when the cotton eyed joe began to play. I’ve actually seen it danced a few different ways but the way we danced it then involved a lot of going forwards and backwards, kicking and hopping to and fro in a circle as couples rather than traditional line dancing. How did we manage this dance in a very small circle with all the dress clothes including my poofy wedding dress (THAT probably dated me) to boot and still manage to laugh our way through it? Our partners made all the difference.
You are probably thinking – she just released the ITSM Implementation Service Providers Wave for North America a few weeks ago with a blog, why didn’t she bring up the partnership story then? Because picking the right partner for ITSM SaaS is just as important as picking an implementation service provider for success. Everyone knows that when you pick a SaaS provider, they are responsible for the delivery operations of that service. But I find clients who know very little about what the delivery capabilities are for the ITSM SaaS vendors and in the past we did not have a method of highlighting the differences between delivery capabilites. In the newly released Forrester Wave: ITSM SaaS Delivery Capabilities report, I take the 10 vendors we have classified as having an “established” client base in the Market Overview: IT Service Management SaaS Tools Update, 2014 report and applied 30 evaluation criteria to detail these differences.
A common inquiry I get from clients has some of the following flavors:
“We’ve chosen a new ITSM tool and need help moving to it. Who can help us?”
“We want to choose a new ITSM product and an implementation provider at the same time. How do I know which implementation providers work with a particular ITSM product?”
“We don’t have the resources to automate our processes. Who can help us with that by applying best practices?”
“We want to work with someone who has developed industry specific best practices. Who really delivers that?”
“We need to revolutionize the way we are delivering services so we can focus on what really matters to the company. Is there an implementation service provider who can help get us there from where we are today?”
A few months ago in my blog about Drake and Service Management, I hinted twice that I would talk later about how to measure success and how to change from a culture of speed. In the report “This Isn’t Your Grandfather’s Service Desk”, we have taken the research from our team that supports Customer Experience Professionals and applied it to the IT Service Desk. Forrester recommends that all IT service desks determine the Customer Experience Index (CXi) by taking a survey of business customers to test how effective (met the needs), easy, and enjoyable their interactions have been with the IT Service Desk over the past three months. By measuring the customer experience and coupling it with the metrics of speed traditionally collected, a true picture emerges of the success of an IT Service Desk. However, we found that only 1/3 of business customers are surveyed about their experience with the Service Desk whether it’s random surveys or surveys after each ticket. We can do better!!
If you haven’t started measuring the customer experience at your IT Service Desk, make a New Year’s resolution to start now (and I don’t mean one of those New Year’s resolutions that peter out about 2 weeks into the New Year!!!). Starting with a baseline will help you understand how you are progressing at customer experience and give you an understanding of what needs to be fixed in order to make the customer experience at the IT Service Desk even better.
Forrester is big on music. Conference rooms are named after bands or musicians and headquarters just held a music festival. As for me, I am a big Drake fan. Therefore, to honor Drake (shout out to Noah “40” Shebib too!) and with a nod to the love of music at Forrester Research, I have combed through his lyrics and here’s the top 5 things I think Drake can remind us about service management:
“I be yelling out: money over everything, money on my mind” Especially after a long week of dealing with outages, changes gone awry, or a huge volume of service requests, it is good to remind ourselves why service management is so important. At its heart, service management solves critical business problems or enables business success. Good service management can make employees more productive which in turn makes the company more profitable. How are you measuring success? More on that later.
“There ain't really much out here that's popping off without us” Whether it is business processes or applications that support functions such as HR, Finance, R&D, Marketing, or Sales, service management is at the heart of it all. Service Management should be enabling, monitoring, and measuring all of these business processes and therefore making you relevant to the business success or failure.
“It’s hard to do these things alone” Services are reliant on the networks, servers, databases and all other parts of IT to run smoothly. Boundaries can easily pop up between functions of IT. Work hard to break down those boundaries to make everyone’s job easier.