Skip to main content

How ITIL 4 and SRE align with DevOps

In the early days of DevOps, there was a lot of debate about the ongoing relevancy of ITIL and IT service management (ITSM) in a faster-paced agile and DevOps world. Thankfully, that debate is coming to an end.

ITSM processes are still essential, but, like all aspects of IT, they too must transform. Recent updates to ITIL (ITIL 4), as well as increased interest in site reliability engineering (SRE), are providing new insights into how to manage services in a digital world.

Here's a look at ITIL 4 and SRE and how each underpins the "Three Ways of DevOps," as defined in The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford.‎

What is ITIL 4? ITIL 4 is the next evolution of the well-known service management framework from Axelos. It introduces a new Service Value System (SVS) that's supported by the guiding principles from the ITIL Practitioner Guidance publication. The framework eases into its alignment with DevOps and agile through a bi-modal approach that retains many of the activities from previous versions but acknowledges DevOps practices such as value streams and continuous delivery.

Site Reliability Engineering (SRE) is Google's approach to service management, introduced in a book of the same name. It is a post-production set of practices for operating large systems at scale, with an engineering focus on operations.

SRE is "what happens when you ask a software engineer to design an operations function." It is both a role and set of practices that have attracted the interest of large enterprises as an adjunct to agile teams and DevOps automation practice

The three ways of DevOps and ITSM Automation is essential to improving flow and service quality. Previously, ITSM automation was used primarily for record keeping and monitoring. In the digital age, most ITIL 4 processes will be underpinned by tools, particularly during transition and operation processes as part of continuous testing and delivery.

Automation is inherent in SRE because it is an engineering practice for operational service management. SREs can code, and therefore will make pervasive use of automation to manage reliability and reduce manual work known, in Google-speak, as toil.

In addition to automation, these other steps are crucial.

1. Increase flow and reliability through change management
The crossroads of agile, DevOps, and ITSM forms the cornerstone of change management. Simplify current change management practices, and you can increase flow many times over.

ITIL 4 and SRE take very different approaches to change management. In SRE, the team is given an error budget that represents the gap between perfect reliability and agreed service level objectives (SLOs). While the team is allowed to regulate its own workload, there are policies and consequences that govern what happens if an error budget is blown or service levels breached. Since error budgets are meant to be spent, the team can make autonomous decisions to increase flow.

ITIL 4 has a stronger emphasis on governance and change approvals. The newest guidance now provides different options for assessing changes based on the change category, ranging from a central decision authority to peer-to-peer reviews.

By definition, the purpose of the ITIL 4 change control practice is "to maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing a change schedule."
ITIL 4 does support the use of automation and rapid decision making to expedite change decisions.

2. Shorten feedback loops by improving incident response
The best way to shorten feedback on the quality of a product or service is through incident management. Fewer incidents equal higher quality.

Both ITIL 4 and SRE refer to incident swarming—a model of networked collaboration—as a means to provide simultaneous and fast engagement to reduce the time and impact of a significant incident. Monitoring systems and dashboards visualize current state and can be shared with key stakeholders. ChatOps systems open engagement opportunities for collaboration, input, and feedback on past, present, and even predictive incidents.

Since SREs are an established role with direct access to developers, feedback on both sides can be fairly continuous. SREs also have the technical ability to diagnose and potentially fix incidents independently, so the ability to capture knowledge at the source is shortened. For its part, ITIL 4 advocates for the breakdown of silos—capturing knowledge at the source—and emphasizes the importance of recording incident activities.

3. Foster continuous learning and experimentation
DevOps encourages a culture of experimentation where "fail fast and learn fast" are the keys to practice, mastery, and improvement. This principle is supported by ITIL 4, SRE, and virtually every agile and ITSM framework. The spirit of continuous learning and improvement is embedded in every ITSM activity. In SRE, failure is an opportunity to improve. In ITIL 4, "improve" is called out as a value chain activity.

Process skills are critical to DevOps
The DevOps Institute’s recent Upskilling: Enterprise DevOps Skills Report proved that process skills are statistically equal to technical and soft skills in the current talent landscape.

It is interesting to note that the upper half of "must-have" process skills do not map to a specific framework or method. These are higher-level, critical process skills that can be applied universally in the management of products and services. While still strongly "nice to have," experience with frameworks such as ITIL, Scrum, and project management was not considered essential by the 1,600-plus respondents to the survey.

Which service management framework is right for you?
Both ITIL 4 and SRE have their merits, and both claim to support the DevOps three ways.

Culturally, SRE is more aligned to DevOps values and agile principles in encouraging self-organization, error budgets, smaller and faster increments, and an engineering mindset. You can also hire SREs.

ITIL 4 promotes a more command-and-control-oriented structure than do DevOps and agile, but it hints at closer alignment. However, for traditional organizations that are not ready to take the leap from change control to self-organization, ITIL 4's bi-modal approach may be attractive, if not sustainable for the long term.

Regardless of the framework you choose, it is imperative that you adopt an agile service management mindset to determine how much is "just enough" or "minimally viable" process for the business.

Either way, IT service management is here to stay.

To learn more: SRE Foundation and SRE Practitioner courses are available through: www.itsmacademy.com/sre


Comments

Popular posts from this blog

The Four Ps of Service Design - It’s not all about Technology

People ask me why I think that many designs and projects often fail. The most common answer is from a lack of preparation and management. Many IT organizations just think about the technology (product) implementation and fail to understand the risks of not planning for the effective and efficient use of the four Ps: People, Process, Products (services, technology and tools) and Partners (suppliers, manufacturers and vendors). A holistic approach should be adopted for all Service Design aspects and areas to ensure consistency and integration within all activities and processes across the entire IT environment, providing end to end business-related functionality and quality. (SD 2.4.2) People:   Have to have proper skills and possess the necessary competencies in order to get involved in the provision of IT services. The right skills, the right knowledge, the right level of experience must be kept current and aligned to the business needs. Products:   These are the technology managem

What Is A Service Offering?

The ITIL4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group .   As a service provider, we can’t stop there!   We must know what the contracts of our service offering are and be able to put them into context as required by the customer.     Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include:     Goods, Access to Resources, and Service Actions Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods.   Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you.   You the consumer own these and they are yours to take with you.               Note: Goods may not always be provided for every Service Offe

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the