In our article “DevOps is stalling, is ITIL a solution?” we posited whether the latest iteration of the ITIL framework version 4 could help bridge the gap between Development lead DevOps teams and traditional Operational teams that followed traditional ITSM procedures and processes.
While at a high level ITIL and DevOps may seem incompatible at first glance especially when the ITIL version used is ITIL 3. With the refocus undertaken when ITIL was updated to version 4, DevOps and ITIL can now actually complement each other and enable an organization to achieve better and more streamlined and dovetailed outcomes. In this article, we will explore some practical advice for getting DevOps done in an operational environment by melding the practices of ITIL 4.
We will also explain with examples how to overcome the various pain points that may arise along the way. As is usual we will refresh our minds with a brief over view of our two main protagonists in this article ITIL4 and DevOps.
ITIL 4 is the latest version of the IT Infrastructure Library, a set of best practices for IT service management (ITSM). ITIL 4 provides guidance on how to design, deliver, and improve IT services in a way that aligns with business goals and customer needs. ITIL 4 covers aspects such as service value system, service value chain, service management practices, and guiding principles.
DevOps is a set of practices that aims to deliver software products and services faster and more reliably by fostering collaboration and automation across the development and operations teams. ITIL 4 is a framework for service management that provides guidance on how to create, deliver, and improve value for customers and stakeholders. How can these two approaches work together in an operational environment and overcome the common challenges they face?
ITIL 4 and DevOps: a case for collaboration
As we have already intimated the latest version of the IT Infrastructure Library version 4 and DevOps are no longer mutually exclusive or competing methodologies. In fact, they now share many common principles and goals, such as:
- A Focus on value creation and customer satisfaction
- The Adoption of thinking which is focused on overall system behaviour and engendering an holistic view of service delivery
- The need to Embrace change and innovation, rather than fearing it and viewing it as the antheses of good
- Leveraging feedback loops to understand what went right or wrong, without a judgemental approach or a need to Find the “Culprit”, which feeds into a mantra of continual improvement, pushing the barriers of Good towards Great. Or otherwise known as performance and stability improvements.
- A Focus on the removal of up and across communication paths, empowering workers decision making and promoting cross-team collaboration and enabling the breaking down of silos and knowledge towers.
- Removing drudgery and repeated work by automating processes and workflows where possible
- Optimizing quality and performance
As such, ITIL 4 and DevOps can complement each other and enable organizations to achieve better business outcomes. ITIL 4 provides a flexible and adaptable framework that can support DevOps practices by offering guidance on:
- Defining the service value system and the service value chain
- Aligning the service strategy with the organizational vision and goals
- Designing and delivering services that meet customer needs and expectations
- Managing risks, issues, and changes effectively
- Measuring and improving service performance and value
- Developing the organizational culture and capabilities
DevOps practices can enhance ITIL 4 by offering guidance on:
- How to Apply the agile and lean principles learned by the Development community to better serve service delivery
- How to Implement the necessary processes to enable continuous integration, delivery, and deployment pipelines
- Automating testing, monitoring, and remediation processes
- Establishing cross-functional teams that share ownership and accountability
- Encouraging experimentation, learning, and innovation
Practical advice for getting DevOps done in an operational environment
Getting DevOps done in an operational environment can be challenging, especially if the organization is used to a traditional or siloed way of working. Here are some practical tips to help you get started:
- Assess your current state and identify your gaps and opportunities. Use tools such as maturity models, assessments, audits, or surveys to understand where you are now and where you want to be in terms of DevOps adoption. Identify your strengths, weaknesses, opportunities, and threats (SWOT) and prioritize your improvement actions.
- Define your vision and goals for DevOps. Communicate clearly what DevOps means for your organization and why it is important. Align your DevOps vision with your ITIL 4 service strategy and your organizational objectives. Define your key performance indicators (KPIs) and success criteria for DevOps.
- Establish a DevOps team or a community of practice. Identify the roles, skills, responsibilities, and expectations of your DevOps team members. Ensure they have the necessary tools, resources, training, and support to perform their tasks. Encourage collaboration, communication, trust, and empowerment among your team members.
- Implement a DevOps pipeline. Design and implement a DevOps pipeline that covers the entire service lifecycle from planning to operation. Use tools such as version control, configuration management, orchestration, testing, monitoring, feedback, etc. to automate your processes as much as possible. Ensure your pipeline is secure, reliable, scalable, and compliant with your policies and standards.
- Adopt a DevOps culture. Foster a culture of learning, experimentation, innovation, feedback, improvement, and customer focus among your team members. Celebrate successes and failures as opportunities to learn and grow. Reward collaboration over competition. Promote transparency over secrecy.
Examples of overcoming pain points
Here are some examples of how you can overcome some common pain points that may arise when implementing DevOps in an operational environment:
- Resistance to change: Some people may resist changing their ways of working or adopting new tools or practices. To overcome this resistance, you can involve them in the change process from the start, listen to their concerns and feedback, address their fears or doubts, show them the benefits of DevOps, provide them with training and coaching, and recognize their contributions and achievements.
- Lack of alignment: Some teams or departments may have different or conflicting goals, priorities, or expectations. To overcome this lack of alignment, you can establish a common vision and goals for DevOps, align your DevOps strategy with your ITIL 4 service strategy and your organizational objectives, create cross-functional teams that share ownership and accountability, use common tools and platforms to facilitate communication and collaboration, and define clear roles and responsibilities for each team member.
- Technical debt: Some legacy systems or applications may be difficult to integrate, maintain, or update. To overcome this technical debt, you can assess the value and risk of your legacy systems or applications, prioritize the ones that need to be modernized or replaced, use techniques such as refactoring, reengineering, or migration to improve their quality and performance, and then how to apply those DevOps practices such as continuous integration, delivery, and deployment to ensure their reliability and security.
Summary
DevOps and ITIL 4 are not incompatible or contradictory approaches. Rather, they can work together to help organizations deliver better software products and services faster and more reliably. By following some practical advice and overcoming some common pain points, you can get DevOps done in an operational environment by melding the practices of ITIL 4.
This is by no means a simple task, there are still many hurdles and pitfalls. Issues like and “FUD” (Fear, Uncertainty and Doubt) spread by those with vested interests in keeping the status quo. A genuine (in their minds) fear of losing their jobs due to automation and delivery by code. A fear that they are no longer upto the task of “learning” a new way to do something. But I have found that the biggest pushback is in middle and senior management layers; who have their ivory towers and known methods of proving their worth. In their world where tickets are currency, a moved to Automated deployments and auto approved changes are an athema to a legacy minding manager.
