When someone asks what type of “shop” your organization is, can you answer that it’s ITIL, DevOps, or SRE? Some people can, but if you’re a large enterprise, the answer is likely a combination of these operating models. ITIL can work alongside DevOps and SRE principles, though they appear to be different. The trick is to ensure that regardless of your organizations’ different operating models or toolchains, you have shared visibility, communication, and collaboration across teams. This will allow you to stay aligned while using the best practices from each method.
ITIL (information technology infrastructure library) is a method developed to create a single source of best practices for information technology. According to CIO writers Sarah K. White and Lynn Greiner, “Developed by the British government's Central Computer and Telecommunications Agency (CCTA) during the 1980s, the ITIL first consisted of more than 30 books, developed and released over time, that codified best practices in information technology accumulated from many sources (including vendors' best practices) around the world.”
ITIL is in its fourth version now, and the approach condensed to nine books. While these books reflect the modern technological era, they still focus on ITIL’s original core ideals. Ideals include “automating processes, improving service management and integrating the IT department into the business.” ITIL is a very top-down, structured, and process-driven method. It remains one of the most adopted IT frameworks today.
Some of the key practices of ITIL include service catalog and design, monitoring and event management, incident and problem management, release management, configuration management, and more. These practices hold regardless of operating model. Yet, you can alter implementation depending on your organization's needs. These practices are valuable even for organizations that identify as DevOps/SRE shops.
ITSM is the process for how a company manages its IT services. This process is very customer oriented and contains 5 steps:
ITIL is a framework for implementing ITSM practices. This framework is organization neutral. It's applicable to almost all businesses, even if the customers that IT focuses on are internal. According to itiltraining.com, “There’s a big emphasis on continual improvement. This involves consistently measuring and improving processes, IT services, and IT infrastructure. Doing so maximizes their efficiency, effectiveness, and cost effectiveness.”
With the ITIL process, your focus is on aligning IT with your organization’s business goals. This dovetails well with the DevOps philosophy of breaking down silos in the organization. By breaking down these silos, you can prevent bottlenecks in communication. This allows teams to ship features that customers want faster while abiding by the CAMS model (culture, automation, measurement, sharing) more closely. But how does this actually look when applied to an organization?
Your organization will rely on ITIL and DevOps for different situations. For example, it may make sense to leverage DevOps best practices between development and operations teams. These teams need to align on workflows, code pushes, automation, and monitoring. But, when communicating between different parts of the organization, ITIL practices might come in handy This graph gives a few examples of how the two methodologies are applicable in differing situations.
The result of employing a mixture of ITIL and DevOps best practices is better alignment on organization-wide goals. When IT and the rest of an organization function as totally independent entities, one side will likely always feel overworked and under-supported. In “The Phoenix Project,” a novel looking at a fictional organization’s struggles with IT integration, this becomes a central conflict.
In the book, IT was partially responsible for R&D and sales initiatives succeeding. R&D required accurate data and inventory reporting to replenish inventory and go to market with new products. Sales required a CRM, phone/voicemail, and MRP system that was effective. Without cross-functional communication, there was no way to plan for these necessary changes. Instead, departments made unreasonable demands on each other, and the company revenue tanked.
At the end of the book, IT aligned and communicated with the rest of the organization. By breaking down silos and working together, many of these issues were resolved.
Sometimes, the timing of IT initiatives and business initiatives seem asynchronous. But, by using ITIL and DevOps best practices, organizations can create a cohesive timeline. Below is a graph that shows how these processes can help the whole organization.
Alignment between DevOps and ITIL frameworks also leads to another benefit: a shift in mindset. DevOps brings innovations to the ITIL framework by encouraging shared ownership and continuous improvement.
Without silos, the goals of the organization become the goals of individuals. Everyone owns the success and failure of the business. They’re all members of the same team, oriented around the same outcomes. Departments are no longer pitted against one another. Continuous improvement becomes a part of the company culture. Teams celebrate failure and recognize it as a learning opportunity.
Now that we’ve covered how DevOps and ITIL align, it’s time to talk about how SRE and ITIL align. As SRE is an implementation of DevOps, many of these alignments are similar. It's possible to use the best practices from all three methodologies.
In practice, ITIL and SRE can actually make for a great combination. The first reason why is simple. Every organization wants happy customers, and ITIL and SRE can make that a reality. Embedding reliability throughout the software lifecycle ensures a higher rate of customer happiness. The newest revision of ITIL introduces seven guiding principles, further aligning SRE and ITIL.
One of ITIL’s best practices is coordinated change management overseen by the change authorization board (CAB). But, as noted by partner at Mindbridge Kaimar Karu, “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.”
SRE can help with this. Its core principles help codify far more flexible and rapid change management. On-call practices empower teams to be more accountable for code in production. Rollbacks can be automated as part of rapid fixes. Incident retrospectives facilitate critical learning insights. SLOs help teams to align on what matters. Error budgets create a guideline for development teams on when it’s safe to ship a new feature.
This added flexibility is also inspired by the SRE leadership mindset. Instead of the command-and-control philosophy, SRE recognizes the need for flexibility in a constantly changing environment and focuses on context over control. This means that if a business-critical feature must be shipped, it will be shipped.
While some organizations operate with only one of these methodologies, many find that a mixture of the three is best. Below is a graph of the strengths of each method. You'll see the methodologies are in fact different, and very complementary.
By identifying which practices make the most sense for your team, and with some trial and error, you can find the ultimate combination that ensures your organization will operate at maximum efficiency.
If you liked this article, you might also enjoy these:
Originally published on G2.