I often get questions whether an organisation should choose ITIL or DevOps. Or people tell me that ‘before DevOps everything was clear’.
And I can imagine the confusion. And often people are right. But it is not so much about choosing a one-size-fits-all solution and expecting things to sort themselves out. It is a matter of choosing the patterns that suit your people’s, processes and product’s needs.
The beautiful thing is that in essence ITSM, Agile and DevOps absolutely strive for the same thing: optimise the delivery of value for your customers and your organisation. Creating and maintaining the best possible products and services.
Where Agile is strong is making sure we build the right things, DevOps focuses on making things the right way. ITSM, when applied properly could be the glue and making sure the right things are being built the right way and that it will stay that way.
Be explicit
Since DevOps is not a strict prescriptive framework or method and therefore it is very important to make things explicit so expectations are crystal clear:
A DevOps team is responsible for: both change as run for a given product or service.
That means that subjects like change, configuration, problem and incident management are very much in scope for a DevOps team and the team also is responsible to fulfil agreements with third parties. This is quite more responsibility than merely making sure the backlog is prioritised and the team can independently deploy to production.
Incidents are part of the run and could easily be prioritised based upon their specific SLA. This means that teams need to know about the SLA’s and where to find them in order to know when and how to communicate and solve the issue.
Problems are a crucial part of the continuous improvement of the product/services. Problems with external dependencies should be addressed during post mortems and/or through root cause analyses. This is a direct part of the inspect and adapt cycle and should be an important part of any DevOps teams process.
If subjects like configuration management in the form of a CMDB have a crucial part in the life cycle management in your company it is from a DevOps perspective wise to automate the creation and updating of the CI’s through your pipelines. You will have both the speed you want and the administration that your company desires.
The road to
The work of a DevOps team can be regarded as a flow in which ideas are being transformed to products. A good approach to see if this flow is optimized is to map all steps that are needed to plan, design, develop and test, deploy and operate the product/service. This mapping should be done in a session with both people with ITSM and DevOps knowledge.
Instead of discussing DevOps vs ITIL we should for each subject be able to answer three questions: what is the essence of this subject, is it covered somewhere in the current process and could we take the risk of not doing it?
We need to first see that there could be a big difference between the essence of ITSM change management and the red taped over bureaucratic implementation of your organisation.
Same goes for capacity planning, configuration management, disaster recovery, performance management, availability management and how/where did we secure these?
I strongly believe that most of these subjects are strongly embedded in DevOps, often completely automated, and we have the right tools to manage all of these. I am also absolutely sure that we cannot regard everything related to ITSM as old-fashioned and thus stupid. We just have to make sure we have the full scope in sight and make sure we use all that is good from any way of working.