IT: All hail the CMDB

After some many years working in IT (I dare not mention how long, it makes me feel old) one thing has remained a constant factor in that time. From my first days writing and developing code, we were required to “Version Control” our code. When I think back to that time in the early 90’s, not only were the tools primitive and DOS based, but so was the widespread knowledge of what it was we were really dealing with – Configuration Management and the CMDB (Configuration Management Database).

It was only a couple of years later I got offered my first position as a Configuration Manager. I remember the conversation well. “We’ve had an audit done,” Said the Programme Director, “It seems we have a problem with Configuration Management. We don’t know what it is but it is something to do with a tool called PVCS and we see you have had experience with this. Do you want the job?”. As I do, I said yes!

It was probably my first exposure to the concept of tools being thought of as a universal panacea, an incorrect concept as I have discussed in an earlier blog on “Don’t use a hammer to drill a hole”. It was also my first exposure to the universal integrator that is Configuration Management. I like to stress that point of a universal integrator because, despite the many different definitions, Configuration Management is a constant in all accepted methodologies, frameworks and concepts for IT Development and Management.

In those early days, however, Configuration Management was seen as a bit of a necessary evil by many companies. It is something they were told they needed, but not something they wanted, as it didn’t make money and didn’t seem to actually produce an end product. The result was a cycle of Configuration Management teams being created when things were going wrong and they were needed, to teams being disbanded at the point when everything seemed ok and so what was the point in paying for that resource – chaos theory in operation if ever I saw it.

But as I mentioned, back then, the true vision of how Configuration Management could, or should, be used, was primitive. Since then, methodologies like CMMI and ITIL have done more to provide a clearer definition of the requirement and need for the discipline, defining the concept of a CMDB and placing the discipline as a core value. However, even in these examples, their vision differentiated. The focus for CMMI was on the development of the systems and the control of source materials – Version Control. The focus for ITIL was on understanding the components in our Operational Systems so we could support them in the event of a problem – Issue Management.

The result has been the creation, typically, of diverse CMDB systems. As the development teams close out their delivery, the compiled and built system is released into production. Call it Release Management or Service Introduction, but typically this action, in terms of management, is to “Throw it over the Wall”. The silos of Development and Operations maintaining their own CMDB’s resulting in a break in relationships between how it was created and how it is supported. The result has led to conflict between support and development teams, quality issues re-occuring and breaks in design and reduced user satisfaction.

Later initiatives, such as Agile methodologies, which became popular, attempted to redress this, amongst other things by introducing development teams co-located with the business units they are developing for, but still the break between Development and Operations existed.

And so we turned to DevOps.

DevOps has certainly been the greatest step the IT industry has taken towards breaking down this barrier, however, much of the concentration has been on introducing support systems and people into the Agile process (Quite correctly as a first step). To fully enable a DevOps culture we must ensure that the integrated people are supported by the correct integrated process and technology to enable them. This is where Configuration Management must play its part as a universal integrator. The CMDB is a key resource which must be used to unite all of the artefacts used as part of any decision making process. Think about it – What makes up an IT software system? It is not just the code, it is also the requirements, the designs, the architectural concepts, the planned tasks and actions, the test scripts and the test results. It is everything we have ever used to create the system. But it is also so much more. It is the components that make up our production systems – The infrastructure, the compiled executables, the Issue Logs, the Problem reports, the Capacity Measures, and so on.

If we are to have a true DevOps culture, then in making decisions on what we do next, we must have DevOps information and facts to enable those decisions, and the ideal source is the CMDB. This creates something of a revolution in how we must think of Configuration Management and its greatest asset, the CMDB. This data source is now our one true source for all information, all data in one source and related in a way to allow impact assessments to be based on objective data and not subjective concepts. The CMDB is now at the heart of not just all we have done, but also all we do now, and all we will do. It is not just an integrator of information, but an integrator of the full lifecycle for a system, from the first spark of an idea, to the final switching off of the power.

The CMDB is the true Universal Integrator!

Steve W