I get a lot of inquiries from I&O pros on configuration management. It’s a broad topic. Tools such as Chef and Puppet solve configuration management problems: what is the intended state of a given resource? There’s general agreement that this form of configuration management is essential. However, my inquiries also cover the Configuration Management Database (CMDB). The CMDB concept originates in the IT Service Management world, and has a mixed reputation.

There is a long distance, tool-wise, between the Chefs and Puppets and the CMDBs underlying IT Service Management tooling. Some time ago, I was working with the SVP for availability at a major US corporation. She had a problem with the enterprise auditors. They were assuming that since she owned the CMDB, she was responsible for securing Unix servers! Ludicrous? Yes! But that was their understanding. They had been reading industry standards such as ITIL and COBIT. These standards had lumped a wide variety of problems under the overall term “configuration management.”

Industry guidance has always seen software and systems configuration management as distinct. But the CMDB started off too broadly scoped, with both platform-independent and platform-specific implications. This was partly solved when ITIL v3 proposed the “Configuration Management System.”  ISACA’s Configuration Management Using COBIT 5 proposed distinguishing between “enterprise” and “element” configuration management.

As we update Forrester’s coverage of these critical concerns, we have developed a new taxonomy. We divide configuration management into three primary areas:

  • Service
  • Software
  • Element

Service configuration management (the function of the CMDB) is about inventories and dependencies. It supports objectives such as planning, accounting, and coordinated operations. It is platform independent by necessity: there is too much detail otherwise!

Software configuration management is also evolving. Simple version control tools once might have held both source files as well as compiled software. Now, DevOps professionals distinguish between source control and package management. Furthermore, using tools like Chef, engineers define infrastructure “as code.” This means source control is now a critical capability for I&O as well as software developers. Finally, “code complete” increasingly means “available as a service.” Organizations must track the deployment of packages onto infrastructure resources (release automation).

Finally, element configuration management is where the rubber meets the road. Platform-specific infrastructure automation tools manage the internal state of CIs. They support lower-level use cases like technical provisioning, discovery, and control.

So what does the future hold for configuration management and the CMDB? At the software and element levels, configuration management’s future remains assured. Service configuration management is another story. I have heard DevOps professionals say, “GitHub is our CMDB.”

Accounting and planning do not go away, nor does coordination. However, the role of a central operational data store such as the CMDB is a big question. Inventories and dependencies are hard to track across increasingly dynamic infrastructures. Creating a CMDB record for a Docker container that lasted all of 15 minutes seems pointless. However, how do we make sense of a 70-million line Cloud billing statement? How do we map our business objectives onto technical resource consumption? These goals do not go away. How do we solve for them in a digitally transforming world of Cloud and DevOps?

I go into further detail on these topics in my latest report (with the esteemed Chris Gardner), Refine Configuration Management And CMDB For The Modern Digital Organization. Let me know your thoughts!