In 1944, the CIA’s precursor, the Office of Strategic Services, distributed the Simple Sabotage Field Manual, a pamphlet containing instructions on how Allied sympathizers in Nazi Germany might weaken the companies they worked for.
Such advice included avoiding shortcuts and doing everything through channels, advocating caution, and making sure approvals required multiple people.
Ironically, for many IT organizations, such counterproductive measures may sound surprisingly familiar, and in fact, may be part of a formal approach to IT Service Management (ITSM) known as ITIL.
ITIL (which once stood for Information Technology Infrastructure Library, but is now simply ITIL) is a set of ITSM practices and procedures for core IT processes like change management, service-level management, incident management, and several others.
ITIL has actually been around since the 1980s, and has matured substantially in the intervening time. Today it belongs to AXELOS, a joint venture between the British Government and Capita plc. In spite of these years of progress, however, today’s Agile, DevOps context for IT makes the current version of ITIL from 2011 look to some people like a recipe for roadblocks and busy work.
ITIL: Part of the Problem?
In fact, ITIL skeptics abound. “Frameworks like ITIL create the illusion of control that results in [the] organisational delusion that IT is efficient and manageable,” says Greg Ferro, long-time consultant and co-founder at Packet Pushers Interactive. “The single biggest problem in ITIL [is that] the creation of silos creates ‘not my problem’ attitudes.”
One such silo is the change advisory board (CAB), a team that has the responsibility for making thumbs-up or thumbs-down decisions on numerous different activities across the IT organization. “Having the CAB review every single change request isn’t efficient,” according to Kaimar Karu, Head of ITSM at AXELOS, “and it’s definitely not common sense, especially when their costs can run to tens of thousands of deployments per hour in some organizations.”
One organization that has struggled to transform their ITIL process as it moved to a DevOps model is financial services firm ING. In fact, its CABs were a point of contention for it. “We were just like an insurance company, always rejecting your first claim,” quips Mark Heistek, IT specialist at ING. “And then come back if you have good arguments.”
ING found that it was able to modify ITIL to work within its new DevOps approach. “Don’t do everything the ITIL book says,” advises Jan-Joost Bouwman, ITSM process owner at ING. And yet, following ITIL for practices like incident management are “still the best way to do it, because everybody knows what to do and you don’t get confused about the rules.”
Or Part of the Solution?
In spite of the skepticism, there are plenty of proponents of using ITIL with DevOps. “The DevOps Movement fits perfectly with ITSM,” according to Gene Kim, DevOps thought leader and coauthor of The Phoenix Project. “ITIL and ITSM still are best codifications of the business processes that underpin IT operations, and actually describe many of the capabilities needed into order for IT operations to support a DevOps-style work stream.”
Kim, however, focuses more on human capabilities than on the ITIL processes and procedures themselves. “ITSM practitioners are uniquely equipped to help in DevOps initiatives, and create value for the business,” Kim continues. “ITSM skill sets are ever more important in a world where there is an ever quickening business tempo.”
Phil Tee, CEO and co-founder of Moogsoft, agrees with Kim – and also echoes the experience of Heistek and Bouwman at ING. “ITIL is not in conflict with DevOps,” Tee says, “but it must be adapted to DevOps practices in order to define clearly where issues arise and how to solve problems efficiently.”
Adapting ITIL to work within the context of DevOps – without slowing it down – has become the crux of the discussion. “ITIL is not explicitly opposed to Agile and DevOps,” explains Charles Betz, principal and CEO of Digital Management Academy LLC. And yet, he finds that “the overall ITIL narrative is still sequential, plan-centric, and deterministic.”
Karu has a pragmatic perspective. “Processes don’t remove the need for common sense,” he posits. “The way to ensure the process is both fit for use and fit for purpose is to ask: ‘What is the simplest process I could design that would support the control requirements while ensuring that customer value is created?’.”
Processes for Improving Processes
In other words, Karu is recommending that IT shops apply an Agile-type refactoring process to ITIL processes themselves – a type of feedback loop that is a characteristic of both ITIL and Agile approaches.
ITIL’s continuous service improvement feedback loops, however, typically operate at longer timeframes than Agile iterations. “The feedback loops in ITIL cover the wider lifecycle of the software system, including specific improvements based on how the software works in operation,” explains Matthew Skelton, co-founder and principal consultant at Skelton Thatcher Consulting. “By finding ways to use feedback from existing Agile and ITIL practices, and making these feedback loops tighter and more rapid, we move towards a DevOps model of continual improvement.”
It’s not clear, however, whether most IT organizations are up to the task of implementing processes for improving their own processes. “We’ve been asked many times to provide a DevOps framework for ITIL in large enterprises,” says Barry Crist, CEO of Chef Software. “ITIL was highly relevant during the previous compute era, but it is far less relevant in today’s high velocity IT world.”
Ferro doesn’t mince his words on this point. “DevOps is, in large part, a reaction to the failure of ITIL and very much about finding a working solution to ITIL’s unsolvable limitations,” Ferro says. “It removes silos through cooperative activity where each person commits to delivering something to their peers. It promotes community and communication where ITIL prevents and restricts.”
Betz agrees. “The assumption is that functional silos will continue to exist, with specialized ticketing processes ensuring delivery and alignment,” Betz says. “The idea of loosely coupled, cross functional, two-pizza product teams using lightweight, unified workflow (e.g. Kanban) is not well supported in ITIL.”
In the final analysis, then, many organizations have been able to modify ITIL to work within the DevOps context, but it’s unclear whether such rework will provide much value long-term. “ITIL isn’t part of the success patterns for the fastest moving, most innovative organizations,” Crist adds. “In fact, ITIL represents an anti-pattern of success today.”
As the transformation of IT organizations continues unabated as part of broader digital transformation initiatives, the days of linear, methodical management approaches like ITIL may be numbered. The question still remains: what if anything will replace ITIL? Only time will tell.
Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, Chef Software and Moogsoft are Intellyx customers. None of the other organizations mentioned in this article are Intellyx customers. ITIL is a registered trademark of AXELOS.
