The more that DevOps matures, the more it looks like IT service management (ITSM).
What? For some time, DevOps has been challenging the old ways of doing ITSM. DevOps has been shifting the traditional ITSM mindset from one of "control" to one of "enablement."
But the disciplines are increasingly merging. Here's why and how.
What is ITSM—really?
Much as with DevOps, if you ask five different people for their definitions of ITSM, you're likely to get five different answers.
The biggest misconception about ITSM is the belief that it is only about IT operations, or that it's just something the service desk does. The second biggest misconception is that ITIL is the only approach to ITSM.
Neither is correct.
ITSM is a means of ensuring that organizations realize business value in their use of and investments in technology. In other words, it is a collection of interrelated practices that allow organizations to exploit the use of technology to help meet their business goals and objectives.
ITSM is an operating model for how to run good IT. Good ITSM takes a holistic view of what IT is (or should be) doing, and how it facilitates business outcomes and value. ITSM is an approach for developing, delivering, managing, and supporting valuable products and services, from ideation to retirement, in the most appropriate, effective, and efficient manner for an organization.
Good ITSM promotes continual improvement. What’s more, good ITSM consists of a set of methodologies, not just a single one, for helping organizations realize value. This means that a good ITSM toolbox has more in it than just ITIL.
[ Special Coverage: Service Management World 2019 ]
The tools you need
You should have tools for quality assurance, such as acceptance testing and regression testing. You also need tools for information security, such as ISO 27001.
Then there are project management methodologies, such as the Project Management Body of Knowledge (PMBOK) and agile. And governance frameworks, including ISACA's Control Objectives for Information and Related Technology (COBIT) framework. And software development approaches including Scrum and Kanban. And methods such as lean to ensure that IT runs with minimal waste. And more.
Think about it. Is DevOps about running IT in the best possible way? Is DevOps a way for developing, delivering, managing, and supporting valuable products and services? Does DevOps leverage many of the methodologies and tools listed above? Has DevOps morphed into ITSM?
Yes, it has.
The similarities are increasing
For one, many DevOps adoptions are repeating the history of many ITIL implementations from a few years ago.
One example is the "us versus them" approach. Many DevOps or ITIL adoptions started from the exact same point, with one camp within IT trying to impose its approach on the rest of the organization, often with little or no inclusion of others in the planning and strategy.
Many ITSM implementations started from within the IT operations organization. Whether it was a way to control and protect the production environment, or even to protect the group itself from the seemingly endless and constant barrage of requests and changes to the environment, the IT operations group essentially used "ITSM" (note the quotes) to put a protective wall around the production environment.
Development teams were often either excluded or exempted from the effort.
Similarly, many DevOps adoptions have started from within the IT development group, then attempted to expand into other areas of IT. In some cases, the IT operations teams were either run over or excluded from DevOps strategizing and planning.
Tools crossing over
DevOps tools are emerging at a staggering rate. One need look no further than the brilliant Xenia Labs' "Periodic Table of DevOps Tools" graphic to visualize the myriad tools that cover many aspects of IT, from incident resolution to release management to configuration to monitoring—areas that have traditionally been the domain of ITSM.
There are two main reasons why DevOps vendors are entering what has been traditionally the domain of ITSM tools. (And granted, many ITSM solutions are far from comprehensive, having only an operations focus.)
The first reason is that the vendor community perceives an opportunity to provide solutions that fulfill a technology need or gap. The second is that the user community is encountering challenges in its ability to support business needs, and people are demanding such solutions.
Sounds just like the ITSM vendor environment from just a few years ago, doesn't it?
The leapfrog game
When ITIL v3 was announced in 2007, many organizations jumped on it as a way to better align what IT was doing with the needs of the business, to reduce the longer-term costs associated with technology, and to ensure that the production environment remained stable by regulating changes to that environment.
For some organizations, it worked. But for many others, their adoptions of ITSM based on ITIL simply made a difficult working relationship between the IT organization and business colleagues even worse. (By the way, this was not the fault of ITIL, but of those adopting and adapting it.)
ITSM was perceived as a roadblock. Many implementations addressed only operational aspects of IT and essentially put up a very tall wall around the production environment. Then they defined only a single, narrow gate by which the rest of the organization could access that environment.
At the time, perhaps, it was a good idea. But those implementations either failed to consider—or ignored—the fact that technology and business needs are constantly evolving and changing.
As the DevOps movement began to take root around 2013, it was seen as a way to satisfy the pent-up demand of organizations to respond to changes in business needs and to rapidly deliver solutions and improvements. DevOps was seen as a way to better align what IT was doing to the needs of the business, to reduce the longer-term costs associated with the use of technology, and to ensure that the production environment remained stable—just as ITSM was once viewed.
And the leapfrog game continues. The recent release of ITIL 4 reflects a significant influence from DevOps. "Change management" has morphed to "change control," value streams are emphasized over processes, and the flow of value is triggered by demand or opportunity.
DevOps is ITSM
DevOps morphing into ITSM is not a bad thing. But as you get comfortable with this idea, keep some things in mind.
First, don't just blindly (or stubbornly) follow a methodology or approach. Don't try to cut and paste what someone else has done, or what you did at a previous organization. Don't simply buy and implement tools and believe that all of your service management challenges will be magically solved.
Second, it should not be a "DevOps versus ITIL" conversation; it must be about business value. Develop your ITSM toolbox knowing that different value streams within your organization may require different approaches, or a blend of them, to achieve the outcomes and value that are required. And that is a good thing.
Join me at Service Management World, where I'll be hosting a two-day tutorial on incident management. The conference runs November 11-13, 2019. TechBeacon readers get $200 off the main conference by using registration code TECHBEACON.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
