ITIL Processes DevOps Organizations May Want to Reinforce
In today’s agile business world, many organizations might assume that ITIL’s rigid approach method is outdated. However, frameworks such as DevOps can gain insights from the ITIL methodology that can apply structure and discipline to agility.
In its most recent update, ITIL 4 was revised to reflect modern business values, recent trends in software development, and how organizations today actually work. However, this new release doesn’t mean that ITIL v3’s more prescriptive processes are obsolete. In fact, organizations can still find value from the legacy ITIL v3 as well as ITIL 4.
In DevOps organizations, IT teams can benefit from referencing both ITIL v3 and ITIL 4, using the principles and practices within to guide strategy as well as changes to everyday processes. Organizations can learn from and perhaps incorporate some of the following ITIL practices into their own strategies.
ITIL Business Relationship Management
ITIL v3’s business relationship management includes customer satisfaction surveys and complaints, among their key subprocesses. With a focus on meeting service concerns and objectives, business relationship management establishes a feedback loop by using regular customer satisfaction surveys as well as through the handling and monitoring of customer complaints. Along with subjective survey information, end-user data sourced from key systems of record can be incorporated into the feedback loop to identify sources of IT pain, delays, or satisfaction.
These concerns are not just IT service related, but extend into DevOps, which also has an obligation to gather end user data to ensure that they are satisfied.
Data on customer concerns can also be used to allocate sources and prioritize certain changes, similar to how concerns based on the production environment are provided in a feedback loop to DevOps.
IT Service Continuity Management
IT Service Continuity Management (ITSCM) is one of the main processes under IT Service Design. The ITSCM process consists of a single feedback loop and aims to manage risks that could seriously impact IT services.
The main goal of ITSCM is regularly auditing service continuity processes to ensure that the best-fit practices are being developed and that measures are in place to effectively address sudden disruption threats. It also ensures that appropriate continuity measures are established.
There are four subprocesses in ITSCM containing critical ideals. These subprocesses, including objectives, are as follows:
- ITSCM Support Process Objective: To make sure that all members of IT staff with responsibilities for fighting disasters are aware of their exact duties, and to make sure that all relevant information is readily available when a disaster occurs.
- Design Services for Continuity Process Objective: To design appropriate and cost-justifiable continuity mechanisms and procedures to meet the agreed business continuity targets. This includes the design of risk reduction measures and recovery plans.
- ITSCM Training and Testing Process Objective: To make sure that all preventive measures and recovery mechanisms for the case of disaster events are subject to regular testing.
- ITSCM Review Process Objective: To review if disaster prevention measures are still in line with risk perceptions from the business side, and to verify if continuity measures and procedures are regularly maintained and tested.
Change Management and Change Evaluation
By becoming familiar with the often cumbersome and bureaucratic ITIL v3 change management process, IT teams can compare and revise their own change management to be more efficient and streamlined. In other words, the inefficiencies revealed in traditional ITIL v3 change management can inspire optimizations in modern DevOps practices.
One example of a legacy process that can be simplified is the change evaluation process, which recommends an evaluation at each of the following stages:
- Prior to planning
- Prior to build
- Prior to deployment
- After deployment
Modifications to make this process more efficient include replacing manual reviews with automated testing and the modelling of pre-approved standard changes that negate the need for manual review.
While this ITIL v3 process illustrates how not to handle the change process, it also shows what steps can be taken for granted and how relying on automation and standard change models can be used to modernize the change process.
Service Validation and Testing
This ITIL v3 process focuses on testing and trial balloons for new product builds or release deployments. The objective of this process is to develop criteria for end user satisfaction to rate the performance for the new build when compared to targets and benchmarks.
In an era where new changes come rapidly, testing iterative changes can produce reams of data feedback from trial users to improve the change before global deployment, or inform the next iteration if the change is to be revised by future changes.
ITIL 4’s Service Value System Model
The service value system model is one of the key new concepts introduced in ITIL 4. It encompasses many of the most essential activities, functions, and components needed to produce value in the form of services. This new model focuses on how all components needed to deliver services can work together to co-create value with service consumers.
According to the ITIL Foundation publication, “the ITIL SVS describes how all the components and activities of the organization work together as a system to enable value creation. Each organization’s SVS has interfaces with other organizations, forming an ecosystem that can, in turn, facilitate value for those organizations, their customers, and other stakeholders.”
ITIL 4 moves away from the previous ITIL v3 IT services lifecycle. In ITIL v3, continual service improvement initiatives were defined according to opportunities identified by IT leadership. However, ITIL 4 places continual improvement within the realm of the guiding principles for the entire IT organization, not just a handful of leaders.
The service value system can be described as a concentric model. The service value chain, the core of the model, includes the activities and functions that produce value, for example, ongoing DevOps processes. Surrounding the service value chain are governance and practices, which serve to support and shape the service value chain.
Finally, guiding principles and continual improvement surround the other components, illustrating the concept that CSI should be a part of the vision for the entire organization and not an activity conducted in a vacuum.
Learn From ITIL — Even Its Past Mistakes — To Become Better at DevOps
DevOps focuses on deriving value from repeated processes that constantly evolve an existing product. Without careful scrutiny of these processes, inefficiencies or a lack of strategic guidance could hamper the value production of DevOps outputs.
Unless all factors are accounted for and considered, DevOps teams might not be living up to their full potential. Production data that sources objective information to draw conclusions should be part of examining DevOps processes.
Data modeling can help verify whether the intended benefits of certain changes are being realized. For example, custom metrics such as IT Service Delivery Friction can be used to identify service elements that have a high amount of friction and then subsequently rank and prioritize these user sources of pain.
Furthermore, research into frameworks such as ITIL and using system of record data can eliminate silos while introducing quality assurances to the DevOps pipelines – all with minimal risk of introducing new bottlenecks to the system.
At a point in time when many businesses are not surviving, constantly improving and exceeding customer expectations is imperative. Without consideration and reflection of techniques that have brought success to others, “Good Enough” can be the epitaph that leads your organization to becoming another statistic.
Learn more about how we can learn from and improve upon ITIL processes while remaining lean and efficient in our recent webinar made in partnership with Pink Elephant: “DevOps & AI: Do we still need ITIL Change Management?“
Agile, DevOps and the Future of Change Management
Today, change is an expected and significant part of the business world — it’s the…
Focus on Stakeholder Value to Optimize IT Strategy
The traditional impression of IT departments is that they maintain the value someone else creates….
The New Role of Change Advisory Boards in an Automated World
In a constantly changing world, processes that worked well a short time ago no longer…