I am a bit amazed. At least in some corners of the greater IT universe, there is still heated debate about which is better, or more relevant, or more modern: DevOps or ITSM. Author and DevOps icon Gene Kim wrote a post for SupportWorld in 2013 called DevOps and ITSM Are Not at Odds. And yet here we are, five years later and a decade after the emergence of DevOps still thinking that one has to be better than the other.
The real question is, “Better for what?”
DevOps has been greatly focused on the Dev side of the equation, emphasizing high degrees of automation using containers and other technologies. That’s terrific. Being able to increase velocity, stability, and security is great, especially if producing software is what your organization does. DevOps’ stated objective is to get viable production software shipped, and shipped fast.
But, whether we like it or not, shipping software is not the only work of IT at any level, from elementary schools to the enterprise.
ITSM can bring a broader view, with its history of thinking about and documenting capacity, availability, change, and many other processes, along with the most common processes of incident and request management. IT runs networks, puts laptops on peoples’ desks, mobile phones in their pockets, printers in their hallways, and WiFi in the air. IT handles firewalls and cabling, installs commercial software on users’ desktops, manages access to online resources, and supports all of thatand morevia the service desk.
The day may be coming when everyone uses their own laptops, mobile devices, and tablets; uses nothing but cloud storage and web-borne applications; and is perfectly capable of maintaining themselves technically. That day is not here.
The day is here, however, when ITSM can no longer fuss about the minutiae of processes. Bureaucracy kills efficiency and effectiveness. One big misconception is that ITSM is inherently bureaucratic and has to be. The best minds in ITSM have been saying for years that continual improvement isn’t a “bolt-on” afterthought, just as DevOps proponents say that stability and security need to be built-in, not mandated later.
ITSM learned late in the game that process doesn’t fix culture; DevOps grew up as a cultural change and not as a framework. ITSM done “right” has the same ultimate aim as DevOps: To produce business value. That value is not produced by arguing that one way of doing things is better than another. It is produced by getting things done. Arguing about whether a password reset is a service request or an incident does not reset the password. Having exhaustive Change Advisory Board meetings to review every single change every single time does not reduce risk to zero. Risk cannot be reduced to zero. Good change planning and oversight can reduce risk, and this should be built into thewait for itprocess of getting software into production, whether that software was developed in-house or not.
No framework or methodology fixes everything. No framework or methodology works for every organization, regardless of size, regardless of industry, regardless of business goals and needs.
ITSM was never intended to be a process-bound bureaucracy, butat least in some casesthat’s what it became. It does not have to be that way. “Adopt and adapt,” say the best minds in ITSM. “Adopt and adapt continuously with multiple feedback loops,” say the best minds in DevOps. If nothing else, DevOps has given ITSM a very loud wakeup call that it cannot ignore. If DevOps and ITSM work together (or in harmony), there will be business benefits, and that, ostensibly, is what it’s all about.
“Learn from each other and get on with it,” says the smart organization.