Is ITSM too bureaucratic to work in DevOps environments?
June 1, 2017 | By Jay Long
As an IT leader with increased responsibility for driving innovation, you probably need to clear the bureaucratic hurdles that slow it down. But do you really want your developer team making big decisions by themselves?
As IT organizations increasingly embrace a DevOps philosophy—which advocates breaking organizational siloes and is suspicious of bureaucratic process—some leaders wonder if they should eschew ITSM’s orderliness in favor of speed and agility.
If you’re confused or even skeptical about how well ITSM and DevOps work together, you’re not alone. While the ITSM vs. DevOps debate has many proponents on either side, I think the controversy is misguided. Good ITSM hygiene can enable DevOps’ speed and innovation—while minimizing organizational risk.
Of course, the two philosophies have differences. While both strive to break down barriers, ITSM typically follows long-established ITIL principles that focus mainly on the production side of the house, and DevOps seeks to break down organizational bottlenecks within development as well as between development and production. But they’re both about serving the business effectively.
Your developers probably hate ITSM, at least in theory, while many on the infrastructure side are wary of DevOps. But DevOps is coming, ITSM is here to stay—and mature IT organizations need both.
The indispensable role of change management
As organizations speed up their applications release cycle, you still need some measure of predictability, or risk downtime and other major issues. But you certainly don’t want every team to slow down to the lowest common denominator—which is the situation an operations-first, bureaucratic environment can create.
Of course you need reliable networks and efficient resource utilization, which require heavy planning, but you also need a fast lane for application development and release—basically, bimodal IT.
But it’s not like these lanes exist on separate highways. What makes it all work is having rules that govern how you use both lanes.
Change management is key to making this work. While ITSM’s change advisory boards (CABs) have a reputation for slowing things down, the ITIL framework is less prescriptive than people think. One tool that ITIL recommends is a “standard” (or pre-approved) change structure that can build some agility into software releases. Your dev and ops teams should both participate in the CAB and decide together—along with business stakeholders—which changes don’t need continual authorization. It’s a chance to enforce early communication and flag which changes have a low likelihood of causing negative impact to your environment and providing a fast lane for them.
It’s important to understand that the standard change mode isn’t one-size-fits-all. Your organization can decide your own tolerance for risk and what calls for more study. This approach allows room for iteration, because standard changes that do cause problems can get their preapproved status pulled.
High-functioning CABs also help monitor and, critically, communicate the changes to the right people early enough to prevent problems.
While your development team might object that new process will stifle their creativity, the structured method to change management actually frees them from having to figure it out every time they do it, they just simply have to follow what’s been laid out for them, thus giving them more time to focus on innovating. If you manage it well, it reduces unplanned work—the fire drills that happen when things go haywire—as well as building in crucial communication early in the lifecyle of application development.
How should IT leaders handle DevOps transition?
The biggest tip I have for IT directors instituting DevOps or ITSM is to get infrastructure involved with DevOps conversations early. It’s being championed by apps teams, but if your ops side waits for developers to do all the planning, they’re not going to be happy with the outcomes.
Also, it helps to get your ITSM house in order before you start implementing DevOps. Make sure you have a change manager who embraces both philosophies and can communicate the benefits to each side.
While some people debate whether DevOps belongs a job title, people say hiring a DevOps engineer or training someone on your existing team can help smooth the way.
Finally, understand that achieving a DevOps culture takes time. The ideas are still evolving and there’s no set of true best practices yet, so keep your expectations reasonable, focus on small wins and start building for the future now.
Related reading
ITSM case studies
Starting your DevOps journey?
We can help accelerate adoption.