Ask the Experts: Making Sense of the DevOps / ITSM Intersection (Part 1)
Cake or pie, Coke or Pepsi, DevOps or ITSM? While it may seem like a classic match-up, DevOps and ITSM approaches don’t need to act as opposing forces.
Aeritae Solutions Architect and resident DevOps expert, Rob Hayes, has spent the last 10 years focusing on delivering successful ServiceNow implementations and projects. He has experience in most areas of the platform including system integrations, developing custom scoped applications, and is a ServiceNow Certified Application Developer and Implementation Specialist in ITSM and Service Mapping. Prior to specializing in ServiceNow, Rob has experience in various roles within IT including Application Development, Project Management, Team and Operational Leadership.
Rob recently participated in an itSMF panel discussion and shared his unique perspective on what it means to embrace DevOps from an ITSM perspective. In Part 1, Rob covers the definition of DevOps and Agile from the perspective of an ITSM practitioner and talks culture change.
Let’s dive in with Part 1 of a 2 Part series!
What is DevOps to you?
DevOps is all about: how can I get that “thing” out there in a good enough state that somebody else is not going to have to wake up at three in the morning to deal with issues.
For years we’ve been having these huge release events. There’s cake and everyone is celebrating. Except if you look over at the Ops team, they’ve all got grease stains on their shirts from the pizza that got them through the night working on release issues. We want to get rid of that.
How is DevOps different from Agile? And do you have to choose between the two?
Agile and DevOps are two sides of the same coin. The Agile side is how developers and teams build the “thing”. The DevOps side represents the automated process to get that “thing” to release. DevOps informs the flow of getting the shippable code you’re looking for in Agile out to releasable code.
Is it for everyone? If your organization is not using cloud or virtual environments, DevOps may not be for you because you still have to go stand up physical hardware. But if you’re thinking about using virtualization and/or cloud-based implementations, you owe it to yourself to start looking into DevOps and the practices that are there to help get flow throughout the organization.
Agile and DevOps really do go together quite well. You do have a choice, but the way the business and technology is moving now, I’d be surprised if organizations were not looking to leverage DevOps.
What are the most important ITSM processes to address in Agile/DevOps transformation and how should they be addressed?
The configuration management and change process are probably the two areas that are most important. What we’re trying to do is maintain visibility when we get into DevOps. Visibility of what? The thing. The thing could be the application, the container it’s in, the node that is running the container. Not only visibility of the thing, but what that thing is related to. Change management integration from the automated build processes helps bring that visibility to life.
When an event occurs, then clears, then re-occurs, or flaps, often times we hope it has fixed itself. A lot of times it’s not “I don’t know what actually is flapping here.” It’s “I don’t know what’s causing it to flap because I don’t know what it’s related to.” I have an island of things to look at over here and an island of things over there: I need to get it all together so that it can be visible. So just having the change management integration is not enough, we also need to incorporate updates to the configuration management database (CMDB) and allow for relationships to be updated.
And then from the standpoint of change, if you can get to the point where you have recorded all the changes that have occurred, you can identify that those changes occurred on these things. I now have a basis to which I can go and start to look at problem management to find what caused that thing to break. It’s those two that I would focus on, and the other processes are then enabled by them.
Does DevOps circumvent traditional process practices? How can ITSM practitioners leverage a DevOps approach?
The opportunity for process folks is to apply the DevOps lens as a way to actually make process a differentiator for our organizations again. The challenge to you as a process person is how to make the process actually serve the people and business for the desired outcome. But the overall goals are still the same.
We’re not fundamentally changing what we want to do in incident management or change management, but what we’re saying is, are those 14 approvals really required? And what value do approvals #12, 13 and 14 deliver? If there’s a control, is there a critical reason for it? If so, is there a way to limit it so only certain changes have to go through that?
This is an opportunity to really use that creative push for continuous improvement that we’ve talked about for years. We have that opportunity now to do that again and really revitalize our processes.
Will doing DevOps require culture change? How do we get people excited about DevOps?
This will almost certainly require culture change at an organizational level. One of the tenets of DevOps is to have experimentation methodology, a culture of being able to try things in a safe environment. If something breaks, we ask why it broke, not who broke it. It’s about embracing a more collaborative learning culture, that invites trying new things, but in an environment that mitigates risk, so we’re not going to hurt our customers or ourselves.
DevOps is easy to get excited about because it’s impressive to see what teams can do when they are able to move a lot faster with smaller increments of work and reduced risk.
I was at a recent DevOps meetup, and a CTO was talking about his organization and how they had increased their release schedule. When starting their DevOps journey there were performing 20 changes a month–that’s 20X that they had the opportunity to get something right. His response to this was, how can we improve on that? What would happen if they increased to 200 changes a month? The odds of being right drastically increase.
The CTO spoke to the power of intentionally holding off on applying goal measures. They just started measuring how many releases they did per month, and all of a sudden he’s now at 400 releases. Their risk is low: that’s 400 times to get it right.
Stay tuned for Part 2 of Rob’s post where he will discuss ITSM revitalization through DevOps and the associated risks and opportunities.