So, I’ve reached the final part of this three-part series of change-related articles. In case you missed them, the first – “The Win(d)s of Change Management – Part 1” – looked its purpose, ITIL 4 and change management/enablement, change management for Agile development, and Agile for change management. The second – “The Win(d)s of Change Management – Part 2” – covered keeping change simple and practical, what are and aren’t changes, and treating changes like small projects.In the final part of this change management article series Gary Percival looks at change and configuration management, and change management and DevSecOps. Click To Tweet
Now, as part of helping your organization to take a practical and pragmatic approach to change management, this final article looks at change and configuration management, and change and DevSecOps.
Change and configuration management
These two IT management capabilities go together like a loving couple. One without the other is incomplete, and will never find true happiness. Marry these two practices together and you have a powerful duo in your IT service management (ITSM) team.
As a guide, consider the two concepts:
- A change must alter the state of one or more configuration items (CIs) in your configuration management database (CMDB) – this leads to the question of the scope of your CMDB.
- Altering a CI can only be done via a change – otherwise, you have an unauthorized change.
If you’re raising changes when modifying items not in your CMDB, then these items should be there. If they’re important enough to raise a change record, they’re probably important enough to track as a CI.
If you’re altering a CI without a change, perhaps it’s so unimportant that it shouldn’t be a CI. Don’t build a CMDB that includes items not under change management. The related data will soon become out of date and meaningless.If you marry change and configuration management together you'll find yourself with a very powerful #ITSM team – Gary Percival Click To Tweet
When introducing configuration management to an organization, I’d first ask, “What items do you most need to keep track of? What are the top three types?” The answer was usually applications, databases, and servers. This became my initial CMDB scope.
Having this simple CMDB blueprint allows us to prove that the change management processes required to maintain the CMDB worked. The integration was solid. Including additional CI types was then easy. Both change and configuration had proven themselves, and other areas wanted to get on board. They wanted their data to be included in the CMDB and managed by changes.
There’s also the possibility of maintaining two CMDBs. One as the authorized or “golden” copy, and one used as a temporary audit tool. The golden copy is automatically updated by authorized, implemented changes (and by any changes backed out). The second is created by discovery tools. Any discrepancy between the two is an unauthorized change to a CI being managed. Such an event must be investigated.
Don’t ignore the tight link between change management and configuration management.
Links with DevSecOps
The change management practice must not hinder the flow, feedback, and continual learning of DevSecOps. Rather, it should integrate with and optimize these activities.
What DevSecOps is doing redefines what a change is. Similarly, change management must define the scope of a DevSecOps team. Collaboration between the two is essential.
DevSecOps (which highlights the need of security considerations early, and throughout the development lifecycle) must have a highly efficient flow, where updates to the service are delivered quickly and safely. It must have feedback from the service users, to ensure rapid response with either additional customer value, or revert where an update proves to be undesirable. And it must have continual learning from this feedback, so as to better target future updates.
Change management must be designed to enhance these qualities of DevSecOps, not retard them. If you think this is impossible, then you’re not thinking outside of the box.Change management must automate and remove any unnecessary human intervention. It must also adopt #DevSecOps practices to improve its effectiveness and efficiency. This article explains. #ITSM Click To Tweet
The purpose of change management is to promote changes while reducing risk. Therefore, it’s incumbent upon change management to help develop solid and reliable DevSecOps processes and tools. Including what can, and cannot, fit into the scope of frequent DevSecOps releases. Remember, such releases are to be frequent and small. Hence the impact of any one release must be small and very manageable. The risk must be inherently small. This leads to a common goal.
The DevSecOps capability becomes a service in itself. Rather than changes to the end service, the responsibility for which is now completely in the realm of the DevSecOps teams. Change management then becomes governance for the practices that deliver the DevSecOps services.
The need for the change advisory board (CAB) is then only required where the DevSecOps process or mechanism needs to change. Reviewing, understanding, and authorizing modifications to the DevSecOps service with all of the potentially impacted stakeholders (which is what the CAB purpose has always been).
Change management must automate and remove any unnecessary human intervention. It must also adopt DevSecOps practices to improve its effectiveness and efficiency. This may be hard for traditionalist Change Managers to accept.
Get used to it, the world has changed!
So, that’s it from my three-part series of change management articles. What else would you have liked to have seen covered? Please let me know in the comments.