Skip to main content

How ITIL 4 and SRE align with DevOps

Image
By
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


Labels:

Comments

Post a Comment

Popular posts from this blog

Four Service Characteristics

By
Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.”  Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services, which is people. Because the people element adds variability, the service is variable. This holds true, especially for the value proposition—not eve...
Post a Comment
Read more

What Is A Service Offering?

By
The ITIL 4 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 1. 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.      ...
Post a Comment
Read more

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

By
This article was originally published in 2015. With the Introduction of ITIL 4, some of this best practice has changed. See  ITIL 4 and the Evolving Role of Roles . Updated Definitions in ITIL 4: Process Owner: In ITIL 4, the concept of 'processes' has expanded into broader 'practices.' Consequently, the Process Owner is now often referred to as the 'Practice Owner.' This individual is accountable for the overall design, performance, integration, and improvement of a specific practice within the organization. They ensure that the practice achieves its intended outcomes and aligns with the organization's objectives. Process Manager: Now commonly known as the 'Practice Manager' in ITIL 4, this role is responsible for the day-to-day management of the practice. The Practice Manager ensures that activities are carried out as intended, manages resources assigned to the practice, and oversees the practitioners performing the work. Process Practit...
Post a Comment
Read more