The ITIL Configuration Management is a mature process. It has transformed, improved and has been fine tuned over the years. The ITIL 2011 configuration management process is steady and can readily provide value to organizations.
If we add DevOps to the mix, the configuration management as we know it from the ITIL perspective does tend to change. I had written an article earlier on Plural Sight on Configuration Management in DevOps.
In my opinion, managing configurations will not be limited to the Configuration Management System (CMS) alone, but rather it extends to managing source code and the artifacts. The reason is simple enough.
The objective of configuration management is to ensure that all your necessary configurations are well known so that the dependencies and impacts are well known to avoid making malicious changes. A DevOps project necessarily deals with development and maintenance of software. And this brings into the picture a new dynamic with source code and artifacts (binaries, libraries, test data etc) into the fray.
So, configuration management in a DevOps project will necessary involve -> Design, implementation and maintenance of CMS + Design, implementation and maintenance of a Source Code Management (SCM) system + Design, implementation and maintenance of a Artifact Management System (AMS).
For those unfamiliar with software engineering practices, in SCM, some of the designs include the choice of an SCM tool, branching and merging strategies. In AMS, the focus is on the logical boundaries that we create to store the binaries that get deployed and those that don’t.
Furthermore, one of the key objectives of DevOps is to improve productivity and reduce the defect rate. These objectives apply to not only the software engineering practices but to CMS as well.
How can I build a CMS where the data capture and changes to it are done in an automated fashion? How do I control data in the fastest and simplest way possible? How can I ensure that the data on CMS remains accurate at all times?
Although CMS exists as a separate entity, its entry into the DevOps fold will exalt it to a different level requiring checks and balances to minimize human intervention and nullify errors.
DevOps today is everywhere. Most organizations are going the DevOps way, and ITIL, as I see it, is an inherent part of DevOps, leading the operations framework. So, it is imperative that we stop seeing ITIL as a standalone framework but rather view it through the DevOps lens.
The ITIL 2011 is built for the standalone projects. It is a herculean task to suit the ITIL processes within the DevOps methodology. Well, I have climbed this peak and crossed over onto the other side through my book: Reinventing ITIL in the Age of DevOps (Apress Publishing, 2018). In my book, I have transformed the existing ITIL processes to fit the DevOps mindset and have extensively provided a DevOps fitment to each of the processes. I have reimagined the team structures of ITIL roles in a DevOps environment as well.
I believe organizations can readily redesign and implement their ITIL processes based on my inputs offered in the book. However, I don’t believe that my ideas alone are the DevOps way. I have therefore tried not to be prescriptive but have rather shown how it can be done.
You can purchase Reinventing ITL in the Age of DevOps on any of the leading online shopping portals. Please provide your feedback either as a comment to this post or on the shopping portals on what your experience in redesign of ITIL processes.
