Chef and Puppet Won't Fix Your CMDB Problem

Last updated by Alan Sharp-Paul on November 20, 2019

scroll down

Most Enterprise CMDB offerings are a joke. They've always been a joke. Just another white elephant system sucking time and money out of IT Budgets. What most, if not all, become are simply inventory systems. They're not even good for that half the time.

"Sure, we'll keep it updated. We'll wire it into our change process." - How's that working out?

"Hey, cool. We can add relationships too." - Awesome, you've just added an order of magnitude to the amount of information you won't be keeping up to date.

OK, so to date our experiences with Enterprise CMDB offerings have been less than rosy. We live in the future though. Disruption is rife. New players challenge the dinosaurs of old in almost every area. Has someone solved the CMDB problem? What about new wave configuration management tools like Chef and Puppet. They truly do represent configuration. When they are used to actually build servers then they should be up to date. They integrate with CI and CD processes, rather than being reliant on the traditionally more hands on ITIL release and change processes. Are they the answer for the Enterprise though?

Well, yes and no. There's no doubt that, assuming a good understanding of their current state, a move to implement automation tools like Chef and Puppet would be beneficial they are still lacking from the perspective of a CMDB. At this point I'll point out that this is not a criticism of either tool as neither claim to be a CMDB. Taking them in consideration is useful in highlighting what the true missing ingredients for fixing the CMDB are.

Puppet vs. Chef: Which Is Better?


The one true lesson of documenting anything in IT is this. If the documentation is not executable then it will very quickly become out of date. Your CMDB may be fancy. It may have all the bells and whistles. It won't matter. If it's still just a dumb store of information it will become stale. No one will enjoy updating it. So it won't always happen. When it does there will be no in-built quality mechanism so no one will be rewarded for being accurate.

If you can make your documentation executable, something magical happens. Your documentation validates your systems. Great! But the real value comes from the fact that the inverse is also true. Your systems validate your documentation! This beautiful cycle means both your systems and documentation guarantee the other's quality. This is documentation nirvana.


If keeping your CMDB up to date involves specific skills or is isolated to certain teams then it is doomed to failure. Configuration management is the one area of IT that truly spans all functions. Architects, developers, operations and security staff all have a stake in it. They all need to contribute and the best results will be achieved if they actually collaborate. The ultimate CMDB will be social. It will reward collaboration, not prevent it.


The perfect CMDB will not care where your systems are hosted. Whether in your own datacenter or up in the cloud, it will only care how they are configured. It will go further than this though by providing true portability. As an accurate definition of your systems' configuration it will naturally become the means by which migration between hosting providers is simplified.


So automation is a great thing but the future CMDB will go much further. It will guarantee the state of systems, not just document them. It will become the hub through which collaboration in IT is fostered and it will help free corporate systems from their datacenter shackles. The future is bright.

Related posts

Learn more about the latest issues in cybersecurity