Greetings!

In this week's article, I will be talking about how ITSM can co-exist with DevOps so that the ITSM teams are not seen as blockers and the DevOps team(s) are not seen as “chaos monkeys”.

This can be achieved through two fronts;

1. Culture
2. Understanding and agreeing on the touch points

Culture

It is easy to say that a good working culture, within an organisation, leads to better interworking between departments and the teams within them. But what does that mean in practical terms when you are aspiring to get ITSM and DevOps working together?

In my experience, this means addressing the following areas, in a program of change that is sponsored from the top but driven from the bottom up.

• Open and respectful dialogue - so that issues can be raised and ideas discussed
• Willingness to change - adopting a one-team approach
• Continual improvement mindset - striving to do better

Touchpoints

The below diagram is my view on where the key touch points are between ITSM and DevOps as models. I have deliberately used ITIL terminology for the ITSM side, mainly because it is widely used around the globe.

Ticket Creation / Update / Resolve

• The resolution of an Incident or Problem may require the DevOps team so, unless it is critical, it would need to be cross logged onto the appropriate Product Backlog
• A Service Request could be a conduit for “asks” being raised onto a Product Backlog
• Depending on how rigorously the deployment of Release Packages to the production environments is controlled, the DevOps team will be raising Operational Request for Changes (RFCs) to get approval to deploy. This can be seen as a bottleneck that restricts business agility, so consideration must be given to;
  • Agreement on what can be automatically approved based on specific criteria being met i.e. tests passing
  • Pre-agreed windows for deployment

Authorisation

The Operational Change Management process will provide authorisation to deploy based on what criteria is either defined in the Change Management policy document or as agreed operationally for each Product.

The key to this is finding the appropriate balance between the business's needs; - frequency and rapidity of change - ensuring that users / customers, depending on your business environment, do not suffer from change fatigue - maintaining the required levels of service availability - minimising risks

Pre/Post Baseline Report

The SACM (Service Asset and Configuration Management) team is responsible for ensuring that there is accuracy in the configuration of the service(s).

The DevOps team relies on this information to;

• know what good looks like, so they can restore the service back to its baseline configurations in the event of an Incident
• identify what might be impacted as a result of planned changes

The typical advice, which I broadly agree with, is to use a CMDB (Configuration Management Database) to hold this data.

My view on this is that a CMDB should be seen as a collection of federated data / information repositories that are specific to the type of data / information that is being managed e.g. a Software Configuration Manager tool (CICD pipeline or Github etc) or Wiki / Knowledge Articles (ITSM tool, Gitbook, Confluence).

Knowledge Share

This touchpoint is important to ensure that changes to the service(s) are understood by the Service Desk, and other support tiers, so that they know what to do when an Incident occurs or a user phones up to query something.

It is also important from a user perspective so that they;

• know what has changed and what, if anything, that change means to them
• can access self-service knowledge to resolve issues themselves

The DevOps team also needs a flow of knowledge not them so that they can understand;

• whether the knowledge that they are providing is actually of use
• how users are reacting to the visible changes that are being made

Summary

In this article, I have described the key touchpoints between ITSM and DevOps and why they are important. Hopefully, this article has been of some use and has given you a good idea of the types of areas that need to be addressed.

I wish you well on your ITSM journey…