Do we need ITSM Change Management in DevOps?
In my last article on DevOps & ITIL both are essential in Enterprise IT, we discussed on how DevOps and ITSM are completing each other to achieve the Enterprise IT goal, to improve the speed and stability in Enterprise IT processes.
In this article, let’s focus more into ITSM Change Management process (or change control practice in ITIL 4). This process has long been a debate between professionals to decide whether it’s needed or not, or how is the most suitable process in modern enterprise that adopts Agile and DevOps.
Let’s start from the basic, What is Change Management and “Why” Enterprise need to implement Change Management process.
Based on the purpose of minimizing the risk, Enterprise implements change management process, some implements Change Advisory Board (CAB) meeting to review the changes, some have dedicated change team, some even just implement local review in the team from their Product Owner (PO) role. In the change review process, they review the risk and the impact of changes, the readiness and the schedule of the release that will modify current production environments.
I have the opportunities to work with some large financial institutions to design their IT process with ITSM, Agile and DevOps, and some of them still have old-fashioned process, with tons of manual approvals. One of them even has more than 20 approvals for just normal change management for medium or low risks.
With the demand of today’s business, the big question “is this process even still relevant in today’s world?” This is also has been a debate in DevOps space for some time.
Let’s move a bit to DevOps, DevOps is famous for its Continuous Delivery practice, the practice that emphasise your changes should always releasable to the user anytime. This practice is coined by Jez Humble and enables by the help of CI/CD pipeline automation to deploy incremental changes fast and transparently.
With all this modern practice and automation, do we still need change management process? from my experience with DevOps and Enterprise IT process, I believe it’s still needed and essential to address the risk, the readiness of all parties, as well to avoid implementation of several high risks changes at the same time, and Enterprise need to understand the main purpose of this process : to understand and minimize risks while making IT changes”, so it should assess and minimize the actual risk, not just introducing waste in the process.
To improve your current change management process, ask these following questions:
- If we have manual approval gates, is it really reducing the risks? Or we just reviewing document completeness instead of the “actual” changes?
- Do we have sufficient data and expertise to assess the risks? Or we just implement some kind of risk theatre?
- Do we introduce waste (waiting) in our process because of this change management process? How to reduce the waste?
- If we have implemented DevOps with CI/CD pipeline, do we have proper governance in pipeline process to reduce the risk?
- Do we implement proper agile practices and focus on quality?
- If the implementation failed, do we have enough data to improve the next release process?
- If the implementation success, is it bring bad impacts to current service health? Do we have visibility in-place?
- How to implement leaner process in change and release management? Can we integrate this process closely to achieve leaner process?
These are some questions that you can address to improve current change management process, and of course to achieve its true objective. DevOps facilitate all of these questions with its CI/CD pipeline as the automated governance and proactive monitoring capability, but again, we need to implement it properly – not just some or “silo” automation in our processes.
Then map your current change management process into these categories, with in my experience, most of large enterprises are in governance focused.
To improve your current change management process to Engineering driven change management, design proper release process with CI/CD pipeline and introduce more automation in current delivery process, and leverage the CI/CD pipeline data to assess the actual risk of change request.
After the implementation of proper CI/CD pipeline as our automated governance process, the next step is to calculate the risk properly based on pipeline data, Configuration Item (CI) changes and the health of services as well the surrounding based on our monitoring tools. Implement proper deployment strategy and shift right the testing (not just shift left it!) to reduce the risks of deployment.
Based on actual data, we can assess the actual risk of change, and gradually improve to achieve automated adaptive capability in our change management process, then integrate the data into ITSM tool to ensure end-to-end visibility in our process.
I strongly believe change management process is still needed and essential to address the risk, the timing and the readiness of all parties, and Enterprise need to improve this process with DevOps to achieve the main goal of change management : to understand and minimize the actual risks” with the demand of business, fast and accurate.