Veteran tech leader Ola Chowning has seen how the everyday task of releasing updated code can lead different factions within enterprise IT to square off. The DevOps teams, charged with quickly deploying software improvements, doesn't have the time to check with the change advisory board, as ITSM requires, for its change to the IT environment. Yet the operations people, charged with maintaining a stable, reliable environment under ITSM, can't let changes just skate by without any record of them.
"So, what do you do?" asked Chowning, a partner at Information Services Group, or ISG, an IT research and consulting firm.
When ITSM and DevOps are in place within the same IT organization, it's a question without a simple answer. Some companies respond by abandoning their ITSM practices, which limits their ability to oversee the IT environment. Others put speed-killing requirements onto their DevOps teams.
To Chowning, neither route is optimal.
"ITSM is prescriptive -- this is how you're going to do it. But in DevOps, you need flexibility to do what's right in your own area. And that's where there's a rub," Chowning said.
IT departments have been following ITSM, short for IT service management, practices for years, with many using the ITIL framework and various ITSM software applications to build, deploy and manage IT services in a consistent, reliable manner.
But as IT departments in recent years aimed to be more responsive to market needs, they've adopted DevOps to create and deploy software improvements as quickly as possible.
ITSM adherents and DevOps practitioners find that they're often at odds over both their processes and objectives.
"These are two different constituencies that normally don't see eye to eye," said Eveline Oehrlich, research director at the DevOps Institute and Research in Action.
Why there's conflict between ITSM and DevOps
Experts listed several reasons for the tension that can arise between DevOps and ISTM within enterprise IT.
First, they're different in nature. ITSM is a top-down practice, usually implemented by IT leaders to formalize the department's policies, processes and procedures. On the other hand, DevOps started as a grassroots movement to bring more flexibility into application development and to enable teams to fix problems in ways they think would work best.
Next, they have different values. ITSM values stability and lower risk over speed; DevOps prefers speed and experimentation -- even if it introduces some risk.
Then there's the issue of control. ITSM establishes centralized control and accountability, while DevOps encourages each team to take on those responsibilities.
Despite the differences, ITSM and DevOps each deliver useful results, and Chowning doesn't expect either practice to fade away. Many organizations continue to have a mix of cloud computing, which is well suited to DevOps, and legacy systems, which need the stability and reliability that ITSM provides. This means IT leaders should be motivated to make the two disciplines work together.
The case for both ITSM and DevOps
Organizations typically find value in both ITSM and DevOps, and experts aren't advocating for one to be dropped in favor of the other. Instead, business leaders need to understand where interests overlap and how to address points of conflict.
"It's an emerging relationship," said Gregg Siegfried, research director on the cloud and IT operations team at Gartner.
There's good reason for CIOs to retain both. A 2020 Gartner whitepaper "Extend Agile With DevOps for Continuous Delivery" co-authored by Siegfried acknowledged the "natural tension between the agility objectives of DevOps and the more control-oriented ITSM." Even so, the report argued, "these programs can coexist and even strengthen each other, with ITSM providing a base set of operational requirements that ensure that the output produced by each product team is stable, operable and supportable."
Indeed, skilled IT departments find ways to have ITSM and DevOps work together, experts said.
IT operations teams increasingly embrace flexibility and evolve practices to better mesh with DevOps. Ultimately, this allows an IT staff to deliver the types of technology services that let the business adapt to market dynamics.
At the same time, smart IT teams adjust ITSM processes to accommodate DevOps. Siegfried pointed to ITIL 4, the latest version of the IT services framework, which emphasizes flexibility much more than its predecessors. ITIL 4 even incorporates some DevOps concepts and terminology, including iteration and value stream mapping.
Similarly, vendors have updated their ITSM software to support DevOps practices within an enterprise, making it easier for an IT staff to unite both practices.
IT departments are also willing to automate more of their change processes, which further enables coexistence between ITSM and DevOps. Plus, they create more self-service development environments to keep pace with DevOps teams that see waiting for servers as being antithetical to their modus operandi.
At the same time, experts said IT departments continue to improve their DevOps practices, bringing development and operations together more completely. This can better align DevOps decisions with the needs established by their organization's ITSM initiative.
"As long as there's no handoff, as long as you have the you-build-it, you-run-it [mindset], then that conflict between development and operations goes away," Siegfried said.
Seeing ITSM and DevOps evolve together
Experts recommend CIOs and CTOs refresh their ITSM practices to better blend them with a more modern, adaptable mindset. Otherwise, the ITSM discipline could find itself sidelined.
In its whitepaper "3 Steps to Agile IT Service Management," Gartner predicted that by 2023, 80% of ITSM teams that have not adopted an agile approach will find their ITSM practices are ignored or bypassed.
Chowning said she, too, advises CIOs to modernize their ITSM disciplines, but she also calls for changes in DevOps practices. ITSM has traditionally put up high guardrails to ensure control, while DevOps often favors none; they both need to accept at least low guardrails, Chowning said.
"They should coexist," Oehrlich agreed. "And if the organization is thinking holistically about development, design, delivery, development and continuous improvement, they will understand what problems there are and they'll use whatever processes, automation, cultural changes and metrics they need for velocity, quality and the reduction of risk. That's the goal."
That doesn't just happen, though.
"It takes leadership," Oehrlich said. "It is not serendipity. It has to be designed."