{"id":223929,"date":"2020-03-14T00:21:43","date_gmt":"2020-03-13T18:51:43","guid":{"rendered":"https:\/\/www.qcsglobal.com\/marketing\/how-itil-devops-and-sre-work-together-for-your-organization\/"},"modified":"2020-04-18T17:10:38","modified_gmt":"2020-04-18T11:40:38","slug":"how-itil-devops-and-sre-work-together-for-your-organization","status":"publish","type":"post","link":"https:\/\/qcsglobal.com\/blogs\/how-itil-devops-and-sre-work-together-for-your-organization\/","title":{"rendered":"How ITIL, DevOps, and SRE Work Together for Your Organization"},"content":{"rendered":"


\n<\/p>\n

<\/p>\n

When someone asks what type of \u201cshop\u201d your organization is, can you answer confidently that it\u2019s ITIL, DevOps, or SRE?<\/p>\n

<\/p>\n

Maybe some people can, but if you\u2019re a large enterprise, the answer is likely a combination of several of these operating models, especially since SRE has become a key implementation of DevOps<\/a>. ITIL can work effectively alongside DevOps and SRE principles, though at first glance they appear to be different species.<\/p>\n

The trick is to ensure that regardless of your organizations\u2019 different operating models or toolchains, there is shared visibility, communication, and collaboration across teams. This will allow your disparate teams to stay aligned while using the best practices from each methodology.<\/p>\n

What\u2019s ITIL? If you\u2019re not familiar\u2026<\/h1>\n

ITIL stands for information technology infrastructure library<\/span>, and is a methodology that was developed to create a single source of best practices for information technology. According to Sarah K. White and Lynn Greiner<\/a>:<\/p>\n

\n

\u201cDeveloped 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.\u201d<\/em><\/p>\n<\/blockquote>\n

ITIL has been updated to the fourth version now, and the approach condensed to nine books. While these books reflect the modern technological era, they are still very centrally focused on ITIL\u2019s original core ideals. These ideals include \u201cautomating processes, improving service management and integrating the IT department into the business.\u201d ITIL is traditionally a very top-down, highly structured, and process-driven methodology, and it remains one of the most adopted IT frameworks today.<\/p>\n

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. All of these practices hold regardless of operating model, but they may manifest themselves differently in the context of different architectural needs and workflows. These practices often are valuable even for organizations that strongly identify as either DevOps or SRE shops.<\/p>\n

What\u2019s the relationship between ITIL and ITSM?<\/h2>\n

ITSM, or Information Technology Security Management, is the process for how a company manages its IT services. This process is very customer oriented and typically contains 5 steps<\/a>:<\/p>\n

    \n
  1. Service strategy<\/li>\n
  2. Service design<\/li>\n
  3. Service transition<\/li>\n
  4. Service operation<\/li>\n
  5. Continual service improvement<\/li>\n<\/ol>\n

    ITIL is a framework for implementing ITSM practices. This framework is organization neutral and therefore can be applied to almost all businesses, even if the only customers that IT focuses on are internal ones. As they are so closely linked, it\u2019s no surprise that ITIL and ITSM align on many issues.<\/p>\n

    According to itiltraining.com<\/a>:<\/p>\n

    \n

    \u201cThere\u2019s 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.\u201d<\/em><\/p>\n<\/blockquote>\n

    How ITIL works with DevOps<\/h2>\n

    When you follow the ITIL process, your focus is on aligning IT with your organization\u2019s business goals. This dovetails well with that DevOps philosophy of breaking down silos throughout the organization. Additionally, by breaking down these silos, you can eliminate bottlenecks in communication, allowing teams to ship features that customers want faster and abide by the CAMS model<\/a> (culture, automation, measurement, sharing) more closely. But how does this actually look when applied to an organization?<\/p>\n

    When to use which?<\/h3>\n

    Your organization will probably rely on ITIL and DevOps for different situations, to come up with the most efficient solution for different scenarios. For example, it may make sense to leverage DevOps best practices between development and operations teams, which need to be aligned on workflows, code pushes, automation, and monitoring.<\/p>\n

    However, when communicating between different parts of the organization that may be running at different speeds, say sales and IT, ITIL practices might come in handy. This graph<\/a> below gives just a few examples of how the two methodologies might be applied in differing situations:<\/p>\n

    \"ITIL<\/div>\n

    Alignment between IT and the rest of your organization<\/h3>\n

    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 \u201cThe Phoenix Project<\/a>,\u201d a novel looking at a fictional organization\u2019s struggles with IT integration, this becomes a central conflict.\u00a0<\/p>\n

    In the book, IT<\/a> was partially responsible for R&D and sales initiatives succeeding. R&D required accurate data and inventory reporting in order to replenish inventory and go to market with new products in a timely fashion. Sales required a CRM<\/a>, phone\/voicemail, and MRP system that was effective. Otherwise, they went without the ability to add or change customer orders and have no way to manage customer health.<\/p>\n

    Without cross-functional communication, there was no way to plan for these necessary changes. Instead, departments made unreasonable demands on each other, balls were frequently dropped, and the company revenue tanked.<\/p>\n

    This conflict was resolved when IT aligned and communicated with the rest of the organization, and other department heads provided high-level buy-in for IT initiatives. By breaking down silos and working together, many of these issues were resolved.<\/p>\n

    Sometimes, the timing of IT initiatives and business initiatives seem asynchronous. However, by utilizing ITIL and DevOps best practices, organizations can create a cohesive timeline. Below is a graph <\/a>that shows how these processes can work simultaneously to satisfy the whole organization.<\/p>\n

    \"ITIL<\/div>\n

    Shared ownership and continuous improvement<\/h3>\n

    Besides the process improvements, creating alignment between DevOps and ITIL frameworks in your organization also leads to another significant benefit: a shift in mindset. DevOps brings new innovations to the ITIL framework by encouraging shared ownership and continuous improvement.<\/p>\n

    When organizational silos are minimized, the goals of the organization become the goals of individuals. Everyone owns the success and failure of the business, because they\u2019re 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, and failure is celebrated and recognized as a learning opportunity.\u00a0<\/p>\n

    \n

    Discover:<\/strong> As you navigate along, discover how software reliability is a top priority<\/a> for your company!\u00a0<\/p>\n<\/div>\n

    How ITIL works with SRE<\/h2>\n

    Now that we\u2019ve covered how DevOps and ITIL align, it\u2019s 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 to help an organization function at peak efficiency. In practice, ITIL and SRE can actually make for a great combination.<\/p>\n

    The first reason why is simple: every organization wants happy customers, and ITIL and SRE can help different functions work together to make that a reality. Embedding reliability throughout the software lifecycle can ensure a higher rate of customer happiness. With the newest revision<\/a> of ITIL, which introduces seven guiding principles, SRE and ITIL align even more closely.<\/p>\n

    The seven tenets of ITIL 4\u00a0<\/h3>\n

    Below are the seven tenets of ITIL 4. Let’s discuss them in more detail.\u00a0<\/p>\n

    1. Start where you are\u00a0<\/h4>\n

    Adopting SRE best practices is not one size-fits-all, and everyone starts somewhere. Taking the first steps and implementing and iterating as you go is what matters most.\u00a0<\/p>\n

    2. Keep it simple and practical<\/h4>\n

    In the Google SRE book<\/a>\u2019s chapter on simplicity, it states:<\/p>\n

    \n

    \u201cUnlike just about everything else in life, \u2018boring\u2019 is actually a positive attribute when it comes to software! We don\u2019t want our programs to be spontaneous and interesting; we want them to stick to the script and predictably accomplish their business goals.\u201d<\/em><\/p>\n<\/blockquote>\n

    Simplicity in both software and business operations streamlines communication, increases velocity, and helps ensure that reliability isn\u2019t compromised. Less is more.<\/p>\n

    3. Optimize and automate\u00a0<\/h4>\n

    One of the goals of SRE is to automate toil-heavy processes, and free up developer time to focus innovation instead of unplanned work. This optimizes workflows and allows new features to ship faster.<\/p>\n

    4. Progress iteratively with feedback\u00a0<\/h4>\n

    SREs set alerts for the most important and user-centric metrics. The metrics, alerts, and SLOs they\u2019re tied to are all iterated upon to satisfy customer needs.\u00a0<\/p>\n

    5. Collaborate and promote visibility\u00a0<\/h4>\n

    SRE is culturally collaborative. It focuses on a blameless work culture that values learning from failure, and trusting that each team member is doing what he or she thinks is best for the organization.\u00a0<\/p>\n

    6. Focus on value\u00a0<\/h4>\n

    Without customers, there is no value in software<\/a>. Business value is created when customers want, and are getting what they need, from a product. SRE best practices ensure that the product is reliable enough to provide value to the customers, therefore providing value to the organization.\u00a0<\/p>\n

    7. Think and work holistically\u00a0<\/h4>\n

    By breaking down silos and focusing on scalability and reliability on a holistic level, SREs are able to provide significant benefits in maturing the organization. Business-wide success is in the hands of every team member, and SREs work to make sure that the company\u2019s product, systems, and procedures are resilient enough to not just meet but exceed customer standards.<\/p>\n

    Flexible and rapid change management<\/h3>\n

    One of ITIL\u2019s best practices is coordinated change management overseen by the change authorization board (CAB). However, as noted by partner at Mindbridge Kaimar Karu<\/a>:<\/p>\n

    \n

    \u201cHaving 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.\u201d<\/em><\/p>\n<\/blockquote>\n

    SRE can help with this, and its core principles help facilitate far more flexible and rapid change management. On-call practices empower teams to be more accountable around the clock for code in production. Rollbacks can be automated as part of rapid fixes. Incident postmortems facilitate critical learning insights such as SLOs<\/a> help teams to align on what matters and cut through the exploding complexities of modern service management.<\/p>\n

    Additionally, error budgets create a guideline for development teams on when it\u2019s safe to ship a new feature. If there is ample room in the error budget, the change is approved, but if the error budget is depleted or nearing depletion, the change is postponed until the next window.<\/p>\n

    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<\/a>. This means that if a business-critical feature must be shipped, it will be shipped.<\/p>\n

    The ITIL, DevOps, and SRE dream team<\/h2>\n

    While some organizations operate in context of only one of these methodologies, many find that a mixture of the three is the most efficient way to align business and IT goals to create secure, reliable services. Below is a graph of the strengths of each methodology. While they may be based on the same principles and are trying to achieve the same result, the methodologies are in fact different, and very complementary.\u00a0<\/p>\n\n\n\n\n\n\n\n
    \u00a0<\/td>\nITIL<\/strong><\/span><\/td>\nDevOps<\/strong><\/span><\/td>\nSRE<\/strong><\/span><\/td>\n<\/tr>\n
    Philosophy & Culture\u00a0<\/strong><\/span><\/td>\n\n
      \n
    • Align IT with business needs to create a symbiotic relationship<\/li>\n
    • Command-and-control and process-driven to mitigate risk<\/li>\n<\/ul>\n<\/td>\n
    		\n
      \n
    • Improve teamwork and eliminate silos\u00a0<\/li>\n
    • Aims to create alignment and minimize silos between development and operations<\/li>\n
    • Often oriented toward helping teams improve velocity and quality of deploys<\/li>\n<\/ul>\n<\/td>\n
    		\n
      \n
    • \n

      Eliminate toil, design for operability<\/p>\n<\/li>\n

    • \n

      Treats operations as a software problem to maximize efficiency<\/p>\n<\/li>\n

    • \n

      Ideal to support distributed services at scale that need to be hyper-reliable<\/p>\n<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n

    Key Practices & Tooling\u00a0<\/strong><\/span><\/td>\n\n
      \n
    • Capacity planning<\/li>\n
    • Service catalog\/CMDB\u00a0<\/li>\n
    • Problem management<\/span>\u00a0<\/span><\/li>\n
    • Change management\/ advisory board\u00a0<\/span><\/li>\n<\/ul>\n<\/td>\n
    		\n
      \n
    • Capacity planning\u00a0<\/li>\n
    • On-call\u00a0<\/li>\n
    • Microservices<\/li>\n
    • CI\/CD\u00a0<\/li>\n
    • Infra as code\u00a0<\/li>\n
    • Monitoring and logging\u00a0<\/li>\n
    • Comms & collaboration<\/li>\n<\/ul>\n<\/td>\n
    		\n
      \n
    • \n

      Matching DevOps key practices alongside: progressive rollouts, SLOs & error budgets\u00a0<\/p>\n<\/li>\n

    • \n

      Observability<\/p>\n<\/li>\n

    • \n

      Chaos engineering<\/p>\n<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n

    Teamwork<\/strong><\/span><\/td>\n\n
      \n
    • Traditional model of centralized process and visibility. Work is typically queued (\u2018waterfall\u2019).<\/li>\n
    • Incidents routed through central NOC team\u00a0<\/li>\n<\/ul>\n<\/td>\n
    		\n
      \n
    • Dev and ops increasingly share the same process and tooling throughout the entire service lifecycle.<\/li>\n
    • Typically, this means devs go on-call for what they build, but may engage ops for L2 support<\/li>\n<\/ul>\n<\/td>\n
    		\n
      \n
    • \n

      SREs often act as consultants to establish reliability-oriented practices<\/p>\n<\/li>\n

    • \n

      Software Engineers and SREs\u2019 roles converge, aligning around shared process and outcomes<\/p>\n<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n

    Key Measures\u00a0<\/strong><\/span><\/td>\n\n
      \n
    • Availability, # incidents, # escalations, etc.<\/li>\n<\/ul>\n<\/td>\n
    		\n
      \n
    • Availability, deployment frequency, etc.\u00a0<\/li>\n<\/ul>\n<\/td>\n
    		\n