DevOps and ITIL: Two paths to a common goal

Author: Kaimar Karu

The DevOps movement has done the IT industry a great favor. Its philosophy brings important concepts like collaboration and transparency into the spotlight. But DevOps isn’t the first movement to tackle these issues. Earlier approaches such as IT Service Management (ITSM) and ITIL have been addressing these areas for decades—and they’re more relevant than ever in the current context of DevOps, Lean, and agile.

The path that led us here

Let’s take a step back—about 15 years or so. We’re at the turn of the century, with no Facebook, no Twitter, and no iPhones. Desktop applications are the primary medium for users to interact with IT solutions. In other news, the human genome sequence has just been released.

With the millennium bug behind us—although it was a lot less troublesome than we feared—the awareness of the potential impact of fragile IT solutions on the rest of the organization is very much in the spotlight. IT is struggling, and confidence in IT is declining fast.

From a technological perspective, there are no auto-scaling, automation-ready, audit-friendly AWS- or Azure-based solutions available. Hardware is getting more affordable and data centers have become a mainstream solution to support the increasing role of IT in business operations.

This is a good thing, because the burst bubble has put a lot of focus on cost reduction, and with Sarbanes-Oxley (SOX) compliance due to become a mandatory requirement for many organizations—taking audit-led effort to completely new levels—the challenges IT face are manifold.

Organizations are starting to realize the importance of understanding what’s inside the “black box” of IT. The details of what IT delivers and whether it’s worth the investment are keeping many a business leader awake at night.

“Organizations are starting to realize the importance of understanding what’s inside the “black box” of IT.”

Discussions about servers, switches, licenses, and such make little sense to most, and supported by familiarity with the application service provider (ASP) model, the peak of IT outsourcing has arrived. Enter service management.

Aligning IT and business goals

ITSM quickly became the common language for outsourcing companies and business leaders to identify and achieve their shared goals. Within this movement, the ITIL framework—which had up to that point been primarily used for IT operations management—became the de facto guidance for achieving IT and business alignment.

Much of the content within the two main ITIL v2 publications, Service Support and Service Delivery, was adopted by organizations, but in many cases, the balance fell heavily on the side of processes and procedures. Less focus (if any) was given to the “soft” parts of ITIL and ITSM, which were often perceived as optional.

The next release of ITIL, published in 2007 and updated in 2011, delivered a more holistic framework, with greater focus on previously overlooked aspects of ITSM. The concept of the “service lifecycle” was introduced to explain how various processes are interlinked and could be aligned for the successful delivery of services.

In ITIL, success is measured in terms of customer outcomes. When evaluating whether a service is valuable, it’s the customer’s perception of value that counts. Unless the service provider, whether an internal IT department or an external partner, has understood their customer’s requirements, it’s unlikely that real value is delivered.

“In ITIL, success is measured in terms of customer outcomes.”

Addressing the customer experience is another key component of ensuring value delivery. It’s not enough to cover only fitness-for-purpose; fitness-for-use is an equally important concept. A solution that delivers on every point in terms of functionality but is a pain to use, isn’t an example of a service that delivers value as it should.

Processes don’t remove the need for common sense

I can see you nodding in approval, but the logical next question is this: Considering that these great concepts have been a part of the ITSM world for a long time, is it reasonable to ask why some organizations fail to see IT as an integral part of the business, rather than a cost center? And why has the word process become something scary?

There are two key concepts behind many successful ITSM initiatives. The first is “adopt and adapt.”

A head of a public sector organization from Estonia recently told me, when explaining the organization’s approach to ITSM, that the framework they’re using is ITIL, while the methodology is “common sense.” It’s a great illustration of the meaning behind adopt and adapt. While the service management mindset should be adopted, the guidance in the publications should be adapted to the specific needs of each organization.

In the past few years, I’ve had the opportunity to speak to many IT professionals from around the world. I wanted to understand what they see as their main challenges and where we could help them to be more successful. Regardless of whether the person I talk to is from development, QA, operations, or any other part of IT or rest of the organization, possibly the most common challenge is getting approvals from the Change Advisory Board (CAB). It seems a CAB can cause unfathomable levels of pain.

“Every change request needs to be documented, and it’s then sent to the CAB. It then waits for the next CAB meeting, which could be several weeks away, and meanwhile we can’t do anything.” If you recognize this situation, I have great news for you—it doesn’t need to be like that. Change requests don’t need to be manually created by people responsible for delivering the changeand change approvals don’t need to be granted by those sitting in biweekly committees.

Take the pain out of change management

Understanding the changes happening in your IT infrastructure is important. Risk assessment, issue tracking, and learning are difficult if there’s no visibility. Teams both small and large have built tools to support the required levels of tracking and visibility. Xbox Live’s operations team, for instance, has a great one.

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?” You can view it as an Occam’s razor, of sorts. In today’s IT, the almost inevitable follow-up question is, “And what can I automate?”

Standard change is a helpful concept to reach for here—preapproved, fully automatable, and fully pain-free. While some changes have an unknown risk and impact, there’s an increasing number where both risk and impact are known.

Having the CAB review every single change request isn’t efficient, and it’s definitely not common sense, especially when their costs can run to tens of thousands of deployments per hour in some organizations. However, having the CAB review change requests of unknown risk, when parts of the business need to be consulted because they might be impacted, makes a lot of sense.

ITIL aligns with agile and Lean

Read full article: techbeacon.com/devops-itil-two-paths-common-goal