The Future of IT Service Management

By Myles Suer

IT Service Management has been around for a long time. When I joined Peregrine Systems in the mid-2000s, I learned – to my amazement – that the embedded database for Peregrine’s Service Manager was nonrelational. Peregrine was founded in 1981, a few years before IBM brought DB2 to market. ITSM was clearly updated in 1989 when the British Government standardized many ITSM concepts and processes with the introduction of ITIL. ITIL itself has been updated on 7-8-year centers.

This author for example was a reviewer for ITIL Version 3. And Version 4, which was introduced just last year, aims to make ITSM easier for organizations to integrate with DevOps, Agile, and Lean Work Methods. The question is where does ITSM go from here? This was the question that I posed recently to the #CIOChat.

How Does Public Cloud Usage and DevOps Change ITSM?

• CIO Rick Osterberg believes “the biggest win of deploying ITSM has been getting everyone onto a common language. In a cloud/DevOps world, you still need everyone to understand the difference between a P1 incident and a P4 service request.”

• Former CIO Joanna Young agrees and suggests “the ITSM basics remain relevant. I look at them as good guidance and foundation.” With this said, Young claims “if we want to talk about ITSM system implementations. Having ITSM built into the delivery process encourages/forces the conversation about ongoing operational support.

• CIO Carrie Shumaker agrees with Young. She insists it is “still critical to understand all the components, dependencies, and relationships. Also, it is critical to have processes and communications for significant incidents. Finally, changes still happen, and still create excitement.”

• With this said, CIO David Seidl claims, “where you do ITSM, and the specifics of how you do it may change, but I think the core concepts remain. The same sort of changes you need to make for agile you likely have to make for DevOps, and you’ll need to do it again when we make another change. This assumes everything you’re doing uses DevOps, which frequently isn’t true. Instead, a lot of the time you’re doing DevOps as a container in an ITIL-esque organization, or some other hybrid/componentized model.”

DevOps Transforms How ITSM Looks

• CIOs seems to believe DevOps transforms what ITSM looks like. Seidl claims that “while the ticketing side of ITSM may still exist, the process it feeds and how and where capability is deployed will have a lighter governance structure.”

• For CIO Jason James, “we have moved from server sprawl to VM sprawl and now to cloud sprawl. ITSM can effectively be used to tie back departmental requests and approvals to help understand cloud consumption when the first confusing bill comes in from the vendors. ITSM today helps support as a result your internal auditing.”

• Former CIO Isaac Sacolick takes a different point of view. He contends that “help desk has largely been about handling end user computing.” However, he believes, “as digital transformation has made technology/data business critical; the importance of the service desk has only increased. And with COVID, ITSM has become mission critical.” Having said this, Sacolick suggests that change management must now be a part of transformation management. Additionally, the Configuration Management Database (CMDB) which has always been a mess, now it is almost untenable when factoring in cloud elastic compute, serverless, and SaaS.” Given this, Sacolick says, “ITSM should support users, help with applications, and compensate for poorly implemented/selected technologies.”

• Splunk’s Andi Mann said in response, “we used to pretend opening a ticket would start to solve a problem. I’m not sure that was ever really true, but certainly isn’t anymore. DevOps solves problems by swarming them with data and with people. Today, the Service Desk has become a system of record.”

• With this said, Forrester’s ITSM/DevOps Analyst, Charlie Betz, suggests the following:

1. Desktop support (edge/end use compute) will always be a thing

2. Information management is a big problem for large scale digital, but a monolithic CMDB has never been the answer. There are subsets of the problem where a CMDB is useful

3. Change Management as a mostly an automated process needs to stay

4. The Change Advisory Board is not essential and can be done away if legitimate coordination is handled elsewhere. For example, it can be a standing item in a Scrum of Scrums agenda.

Historically, ITIL broke ITSM into Discrete Processes. Is a More Systematic View Needed?

• Mann compared ITSM, at this point, to 2000 century time and motions studies. He said, I feel like ITSM was created for a world of monoliths because it was built upon a Tayloristic data center. It worked for that. But I feel it doesn’t work as well for a world of cloud, DevOps, microservices, analytics, remote, edge, without a mass of duct tape and bailing wire. Young too finds “Taylorism and the Hawthorn Effect outdated notions but still solidly entrenched within many IT organizations.”

• Given this, CIO Jason James says “a modernization of ITSM is required. There needs to be more automation to allow for greater self-servicing including cloud provision when it is needed. Additionally, “all of the workflows have to be designed to support responsiveness and eliminate unnecessary approvals and delays. The need for an AI driven ITSM is there, but we still have a way to go to make it real.”

• Seidl says in response he has “always looked at ITIL as useful language, not necessarily completely distinct silos. The concept versus the reality of implementation means that those are blurred, and the language is useful as a handle to make sure we’re somewhere close when acting on it.”

• Osterberg takes fundamentally the same position, when he says, “it’s still all about language. It doesn’t matter what your backend is, you still have interruptions, deeper problems, changes, and transactional requests that all intersect and overlap. You need to have a shared language to talk about all of it.”

ITIL Overcomplicated Things?

• Sacolick believes “ITIL overcomplicated things with too much jargon and process. The tools today, especially integrated DevOps and Agile along with AIOps, greatly simplify incident support. Agile isn’t about scaling up. It’s about culture and mindset. Organizations need to be making smart decisions about where agile teams can self-organize versus what standards are in place.” For this reason, he says that “ITSM should focus upon the big rocks in a cloud world. And not send just a chatbot to the rescue. Self-service things properly.”

• Given this, James suggests that “ITSM must be highly automated and mobile-ready. Today, many of the functions of ITSM can be done with bots. These include password resets, equipment provisioning, and basic Q&A. These all can be automated so the Service Desk team can focus on more complex issues.  Many in-place ITSM solutions still lack these capabilities. Chatbots, if effectively implemented can be much less painful than opening a ticket, waiting on hold, or talking to someone. The few times I have interacted with Amazon in the last year have been done via their bots and each time my issues were corrected quickly.”

In terms of what functions continue to belong in ITSM, I received varying responses:

• Young said “ITSM needs to have master data management and integrated processes across problem, change, service request, asset, supplier, and configuration’. However, Pitt narrows the list to “incident, problem, change, and request.” Taking a more integrative view for things, CIO Carrie Shumaker says “incidents become problems and lead to changes; changes cause incidents, and round and round we go. I’ve considered the unifying factor to be the service, or at times, the CMDB element.”

• With respect to change management, Betz says “the problem is we equate change management with the change advisory (sometimes approval, yuck) board. The CAB is an inefficient, cadenced, synchronous, face to face dedicated communication channel. There are better approaches for solving the coordination problem.”
• With this said, CISO Michael Oberlaender suggests that adding “an end-to-end concept that focuses on the value creation/chain is definitely needed. We do too many things in ITSM that are not adding enough value.”

Is There an Expansive Role within ITSM For a Catalog of Consumable Digital Business Services?

• Seidl says “for some organizations, sure. The trick remains to pick and choose components and models that work well for your organization, your goals, and your capabilities. I’ve seen more organizations fail to roll out ITSM and more succeed figuring out how to work.”

• CIO Martin Davis believes it depends on how you define ITSM. Should its scope be limited to just helping people with IT related problems, services, or is it wider than that. Where is the boundary? However, with the business becoming IT and IT becoming the business, the catalog is a great approach if you have a lot of discipline and strong vision. With this said, it can go very wrong if you’re disjointed and the kind of company that makes exceptions for everything. You need to be a process driven company to make this a success.”

• Young has a similar perspective and says “potentially. However, many organizations are not even close to being able to tackle or afford this. For them, DevOps and agile are still nascent or wish list items. The question is what are vendors doing to provide bite sized pathways in particularly for small-mid cap organizations.”
• Likewise, James sees “the potential for ITSM to evolve and interact with more systems and cloud services to provide more services all the while providing greater insights and responsiveness.” An open question remains. Does the service catalog become the catalog of APIs and consumable business services described in Jeanne Ross’s Designed for Digital?

• Sacolick suggests that “IT has been trying to develop a catalog of consumable digital business services through many technology generations from before SOAP through Microservices. I believe that it won’t happen at scale until there are easy buttons.” A vendor opportunity?

Parting Words

Clearly many aspects of IT operations are experience change as more and more work loads move the public cloud. ITIL and ITSM are no different. CIOs see the opportunity for ITIL and ITSM to do more. And the next five years, ITSM will experience change.

• According to Dion Hinchcliffe of Constellation Research, ITSM must and will evolve to be well-reconciled with DevOps. This means being inclusive of all IT, including SaaS, Public Cloud, and Shadow IT. This means, according to Dion, ITSM will become a proactive support and management network while enabling choice and competition. Doing this will create a highly usable approach including potentially, an expansive notion of service catalog.

ABOUT THE AUTHOR:

Myles Suer is the Head, Global Enterprise Marketing at Boomi. He is also facilitator of the #CIOChat, and is the #1 influencer of CIOs according to LeadTails. He is a top 100 digital influencer. Among other career highlights, he has led a data and analytics organization.