For those of us in the IT service management (ITSM) space, DevOps appeared on our scene around five years ago. And at that time, to most in ITSM, DevOps was seen as an outsider pushing in to places it didn’t know enough about. Specifically, it seemed to be an entirely development-driven concept that suggested IT operations wasn’t actually needed – that getting development right meant NoOps was perfectly possible, where NoOps is “the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house.”
In the absolute sense, this is perhaps even correct. If you could build an IT system that was perfect, in that it never failed, and is so flexible that it’s adaptable to every change in customer needs, environment, legislation, etc. – then surely all you need to do is build and test it, then let it go delivering the service without any need for tinkering, fixing, or updating.
If you’ve attended an ITIL Foundation course, you’ll remember learning about emergency changes, and the role of the ECAB – the emergency change advisory board. In many cases, the ECAB is presented as something of a “rubber stamp,” helping a change manager “cover their back” by getting an emergency action signed off by senior staff. What the relevant ITIL book (Service Transition) actually says is “Where CAB authorization is required, this will be provided by the emergency CAB (ECAB)” (do you think this would look good as a tattoo?).
In IT, one of our biggest (maybe even our favorite?) grumble, every year, is how the business expects us to deliver more for less. So why is that? Perhaps there’s one overriding reason why the business expects it: IT has, by and large, delivered exactly that for the last 50 years or so. From inside IT, we’re very aware how hard it is to deliver these constant improvements in times of budget cuts and austerity. But step outside IT, take a wider perspective and you’d agree that your customers just see technology driving savings and the IT department offering more and better services than ever before.
Have you ever thought about the truly basic concepts underpinning continual service improvement (CSI)? Let’s take a look at the words themselves.
The main point of CSI is to deliver improvement, so I think it makes sense to start with that word.
Often individuals’ preconceptions of improvement limit the scale and scope of what can be delivered.
This is especially true of suppliers who think they know what a customer, user, or other stakeholder would consider “better”.
Let’s illustrate this with a familiar product – cream cakes. What range might the term “improvement” cover?
As more companies move to adopt DevOps practices to improve IT performance (my company included), I was thinking to myself – is it clear how to blend this with our existing IT service management (ITSM) activities? These existing ITSM disciplines and processes, often based around ITIL, have served us well for many years. So although most of us accept that it’s time to adapt, how do we best marry the ITSM, or ITIL, activities and DevOps? In particular, how do we best incorporate the IT service desk in the DevOps world?
In this blog, I want to look at each of the DevOps “three ways” and outline how the service desk can be fundamental to all of them as well as other Agile concepts.