DevOps Is ITSM (Like It or Not)

ITSM seems to have many definitions. The definition you get depends upon who you ask.

My friends here at SysAid have defined ITSM as “the craft of implementing, managing, and delivering IT services to meet the needs of an organization. It ensures the appropriate mix of people, process, and technology are in place to provide value. In other words: ITSM is the art of making a business run.”

They’ve also made a great video on this:
My definition of ITSM is similar: ITSM is about providing and managing the right combination of people, process, and technology to enable a business to meet its objectives and deliver measurable value.

Many treat the term “ITSM” as a synonym of ITIL. While ITIL may tout itself as the “de facto” ITSM standard, I would argue that ITSM and ITIL are two distinct concepts. ITIL is more about the what and how; ITSM is more about the what and why. In other words, ITIL is just one approach for ITSM.

And there’s been little reason to make that distinction – until recently. Because DevOps has shaken up the ITSM world.

That’s ITSM, so What’s DevOps?

If you ask five different people, you’ll likely get five different answers to the question “What is DevOps?”.

Some will say it’s about automation. Some will say that it’s about eliminating IT operations. Some will say that it’s about microservices or containers or continuous deployment or any number of technology-related concepts.

Everyone agrees that DevOps started with a simple idea – getting the IT development and operations teams to work better together. At the core, is that really any different than what ITSM is trying to do?

But many in DevOps think that ITSM is just something that the “IT Help Desk” does.

Why do some insist on looking at ITSM and DevOps as two disparate things?

Isn’t ITSM an Operating Model?

According to TechTarget.com, an operating model is:

“A visual representation of how an organization delivers value to its internal and external customers. Operating models, which may also be called value-chain maps, are created to help employees visualize and understand the role each part of an organization plays in meeting the needs of other component.”

The Operating Model Canvas (OMC) is a popular framework for designing operating models. An OMC captures six elements that play important roles in delivering value:

1. Processes – the work steps need to create and deliver value to customers
2. Organization – The people who do this work and how they’re organized
3. Location – Where the work is done, and what assets are present in these locations
4. Information – The information systems that support and enable the work
5. Suppliers – External suppliers that support and enable work
6. Management System – Ensures that the organization runs smoothly, including planning, budgeting, target setting, performance management, people assessments, risk management, and continuous improvement

I’d argue that ITSM is an operating model for running the business of IT. Things like ITIL or DevOps or Agile or COBIT or whatever are simply ways for delivering that value. But too many IT organizations put the focus on the tools or processes and less on a holistic view of what a business needs from IT.

DevOps Is Driving a New View of ITSM

The DevOps movement is driving a new way of ITSM thinking. Here are a few examples.

• Continuous Deployment – DevOps promotes the concept that deployment shouldn’t be an “unusual” event; in fact, organizations could deploy new functionality multiple times a day if needed.
• Testing and Validation – Traditionally, testing and validation occurred towards the end of a development cycle. In a DevOps approach, testing and validation is an everyday part of the development cycle. Nothing is put into a production environment without having been tested and validated.
• Incident Resolution – Many DevOps advocates utilize a “swarming” approach for resolving incidents. Swarming an incident eliminates the waste that comes from queuing the work that is going to have to be done (eventually) anyway – why make a consumer wait?
• Kanban – Isn’t a Kanban everything that a traditional ITIL Change Schedule ever aspired to be? In a quick glance, one can see what work is in progress, where there are blockers to getting work done, what work has been completed, and what work is planned.
• Product teams – By aligning IT teams by product (dare I say “service”?), DevOps works to eliminate the so-called “wall of confusion” that often exists between developers and operations teams.

Is History Repeating Itself?

I’m also seeing a number of parallels between what’s happening today with DevOps and what happened a few years ago with ITIL adoption.

One group within IT is trying to impose its approach on others – with little to no inclusion of those groups in planning and strategy. Many ITSM implementations based on ITIL began in IT operations, then met significant resistance with attempts to expand into the other parts of IT. Similarly, many DevOps adoptions are being driven from the development side of IT, with little to no inclusion of the operations, security, or quality assurance teams. But what’s the most significant mistake happening all over again? Not including business colleagues as part of the design and effort of delivering IT services.

Tool vendors and solutions seemingly emerge every day. It wasn’t that long ago in the ITIL-based ITSM space that there were literally dozens and dozens of software solutions to manage every aspect of service management. Reporting tools. Analytics tools. Workflow management. Alerting.

The same thing is happening with DevOps. There’s tools for deployment. Testing. Integration. Alerting. Analytics. Workflow management. Tools to manage tools. Tools to integrate other tools. Are more tools really the answer?

The leapfrog game between business and technology continues. Business needs drive new technology capabilities. New technology capabilities enable new ways of meeting business needs, which in turn drive the next round of new technology capability. While this game has existed since the days of the abacus, each leapfrog cycle is becoming shorter and shorter. Even with the introduction of DevOps, many IT organizations continue to struggle to keep up with business demand.

The More Things Change…

But then again, the more things change, the more things stay the same. The issues that DevOps adoptions are encountering are the same issues that ITIL-based ITSM implementations encountered, and still do. For example:

• Need for cultural change – Getting people to work together in new or different ways is always a challenge.
• Need for strong executive support – While “grass root” efforts can have success, that success will hit a definitive ceiling in the absence of strong executive support.
• Need for willing innovators and adopters – New approaches need individuals willing to try it on, learn by doing, with an attitude of continual improvement.
• Need to fit the solution to the problem, and not develop a solution looking for a problem. Just like with an ITIL-based ITSM approach, DevOps may not be the right approach for all situations.

Call to Action

The bottom line is that ITSM is ITSM.  The need to deliver and practice good ITSM is just as important as it ever was – perhaps even more so! This means that organizations must do the right things using the right tools – regardless of what methodology those tools are founded upon.  To do that, organizations must do two things:

• Stop looking at DevOps and ITIL as opposites. Both DevOps and ITIL have some great concepts for managing and delivering value. So do other service management approaches. Stop the DevOps or ITIL conversation – rather, put effort into building a holistic approach to ITSM.
• Thinking is required. Don’t just blindly follow a methodology. Don’t just buy and implement tools believing that all of your service management challenges will magically be resolved (they won’t). Don’t just try to “cut and paste” what someone else has done (or what you did at a previous company for that matter). Thinking is required. Discussion is required. Don’t work in isolation. Using tools like OMC will not only help you build the ITSM operating model, it’ll make you think about what really needs to be done.

ITSM is DevOps. ITSM is ITIL.  ITSM is potentially many other approaches too. Like it or not.