Is the CMDB relevant?

Configuration management databases have been around for a couple of decades.

For many very painful as the promise of the golden truth never realised.

The CMDB was first introduced in the early 1980’s with the introduction of ITIL – organisations realised they had to keep track of their ever-changing IT Assets.

The CMDB went through a few iterations and evolved from Asset Register to Configuration Management and finally the understanding configuration relationships (ITIL V3) in the mid 2000’s.  For the first time it was possible to have a documented understanding of the interaction between applications, software, hardware, and components.  Understanding impact and dependencies between these assets gave organisations a clear view of the IT landscape and how everything fits together.

But the hype cycle turned to disillusionment from around 2010 when organisations realised that maintaining the CMDB was a near impossibility – especially if this was done in a manual fashion.  People lost faith in the data that CMDB’s produced – it was inaccurate and out of date.

But does this mean the CMDB is past it’s sell by date and we need something new?

With the introduction of new technology and services (virtual environments, containers, cloud hosting, SaaS services, micro services) the need for organisations to understand what makes up a service they are rendering to business, is critical.

Manually maintaining the CMDB will not suffice.  The complexity of IT and the rapid changing environments require a new approach. 

Enhances in automation technology such as automated configuration discovery and application dependency mapping makes it possible to maintain data accurately within the CMDB. 

Organisations can now depend on the information provided within the CMDB and consume this data in a wealth of related processes such as security, incident impact analysis, problem investigations, change planning, capacity optimisation, service monitoring, cloud migrations and many more.

We can now view technical and business services and the components that make up these services – critical information required in maturing other dependent processes.