Differentiating Configuration Management Tools

Michael Gerards · 2026-09-10

Your project has frantically rolled back a production update and it “succeeded”. But deep down, everyone is uneasy because they know it’s going to happen again with exactly the same amount of chaos. Configuration Management is supposed to minimise these scenarios and it’s not working for you. Something’s wrong and you don’t know what.

Is Configuration Management the actual problem? Are the tools that you’re using the problem? This article will explore whether tools that are as varied as Ansible and ServiceNow can be categorised in a more useful way and even whether they are Configuration Management tools (hint: they’re not). And then the article will provide you with heuristics to know what types of tools are right for you, and whether you even need Configuration Management.

Anything is a Configuration Management tool?

It’s genuinely confusing when the market treats tools with varied capabilities (Ansible on the one hand and ServiceNow on the other) as all falling within the category of Configuration Management. Cloudaware’s article ( here) is a good example and the reasoning is summarised below. As you go through the table, try and see if all the tools have something in common.

The tools in this table have almost nothing in common. What does an enforcement engine share with an inventory database, beyond both touching technology? Not enough to sit under one label — yet all of them are sold as configuration management. That breadth defeats the one thing the label should do: tell a buyer what they’re actually getting. Tellingly, the article concedes the point itself — its own summary admits configuration management software is “not one category with one job” — and then proceeds under the same umbrella anyway. The comparison that follows is genuinely useful, but it starts from the assumption that all of these implement configuration management. Unlike Cloudaware’s review, this article begins with a different assumption: these are good tools, but configuration management promises something they don’t deliver — and for the organisations that need that something, the gap is expensive. The next sections are about what it is and why the label hides it.

“Configuration Management” tells you almost nothing

The tools are categorised under the Configuration Management umbrella because two incorrect definitions are being used.

Definition 1 says that a Configuration Management tool is one if it has a database of Enterprise ICT assets.

The logic is as follows:

1. A database of ICT assets is what ITIL refers to as a “Configuration Management Database” or a CMDB
2. A product with a CMDB that provides some overlay of value across items and relationships is useful and the usefulness suggests that it is doing some part of Configuration Management.
3. A product that has a CMDB and provides value must be part of CM (Configuration Management)
4. Therefore a product which has a database of Enterprise ICT assets is a Configuration Management tool.

This logic is flawed. A CMDB, as ITIL defines it, is one component the discipline of Configuration Management relies on — the record of items and their relationships. But holding that component is not the same as practising the discipline, which is about controlling change against an approved baseline (see What is Configuration Management). You can get real value from the CMDB and still do none of that change control. The definition “feels” natural only because the discipline’s name is buried inside the tool’s name — “Configuration Management” read straight out of “Configuration Management Database.” Saying a product is a Configuration Management tool because it has a CMDB is as absurd as saying eating buffalo wings means buffaloes fly — except the first absurdity hides where the second is obvious, and hidden absurdities are the ones that cost you.

Definition 2 says that a Configuration Management tool is any tool that allows settings or other technical content to be deployed to specified ICT targets.

The logic is as follows:

1. The product configures things — it sets and deploys the technical configuration of servers, apps, devices.
2. Setting and maintaining configuration is “managing configuration.”
3. “Managing configuration” is Configuration Management.
4. Therefore the product is a Configuration Management tool.

The logic here is also flawed in a similar way to Definition 1 - it’s based on conflating terms. Simply put - managing the configuration of things is not the same as “Configuration Management”.

For example, an Ansible playbook can describe the desired state of things in detail, but it isn’t designed to be traced back to an approved design baseline. So there’s no approved baseline to check the playbook against — you can see what it declares, but not whether that’s what was approved. A review can then only catch technical errors in the code; it can’t judge the change against an approved state, because there isn’t one.

An analogy that brings the absurdity to life. Imagine you’ve just bought a nice Toyota Camry and it arrives at your door. You go out excitedly with your family and take a walk around. And you notice something - the front right wheel is missing. But being a diligent professional, you check the manual and sure enough, there is a front right wheel that is prominently referred to in the manual. You call the company; they send an engineer and he takes a look and agrees there’s something very wrong. But, he can provide an instant fix - he gives you an updated manual with the right wheel missing. Sadly, some version of this happens in software organisations every day because managing configuration settings (building the car) is confused with Configuration Management (knowing for certain that a built car is subordinate to the approved design).

Both definitions ignore hallmarks of Configuration Management

Both definitions ignore the hallmarks of Configuration Management which I summarise as:

1. It is a subset of corporate risk management.
2. It knows what is important to risk - which items, if changed incorrectly, cause material harm.
3. Every change is traceable to, and controlled against, an approved baseline of what is important. (When something goes wrong, your team doesn’t reach for the Ansible definitions — they go looking for documentation of what the state was supposed to be. That set of things that provide clarity on what the state is supposed to be is the baseline. Usually they find it missing, stale, or out of sync with what’s actually deployed — which is the whole problem.)

Points 2 and 3 are deliberately simplified to cut to the heart of a technical and much-misunderstood subject; the full treatment is in What is Configuration Management

The reason neither definition delivers hallmark 3 is that an approved baseline is made of artifacts these tools don’t model. The things that legitimise a particular configuration are often not ICT assets at all — design documentation, approved binaries with verified hashes, written approvals. These are configuration items too, and both definitions ignore them entirely. So the authorisation that makes a configuration the approved one lives outside the tool, and a tool can’t control change against a baseline it can’t see. It’s also why these tools only ever speak to a deeply technical audience: they model the settings an engineer touches, not the approvals a risk owner signs — and Configuration Management is the risk owner’s concern.

Asset management and technical productivity — not configuration management

Neither definition describes Configuration Management — but both describe something real and useful. So rather than sorting these tools by a label none of them earn, it’s more honest to sort them by what they actually do.

Asset Management tools

The Definition 1 tools — the ones built around a CMDB — are asset management tools. Their core strength is knowing what exists across your estate and how it connects: discovery, inventory, dependency mapping, and the reporting that sits on top. That is genuinely valuable, and for many organisations it’s exactly what’s needed. But don’t expect it to tell you whether the current state was approved — it will tell you the server exists and what it’s connected to, not whether its configuration is the one someone signed off on. Knowing what exists is not the same as controlling change against an approved baseline.

Technical Productivity tools

The Definition 2 tools — the ones that declare and deploy configuration to targets — are technical productivity tools (this isn’t an industry term, but is being used deliberately so that their benefit is obvious and apparent - the industry terms are provisioning or orchestration tools). Their core strength is enforcing a defined state quickly, consistently, and at scale: automation, drift correction, reproducibility. Also genuinely valuable, and for the teams that live in them, indispensable. But don’t expect the enforced state to be a reviewed one — the tool will push whatever the playbook declares, flawlessly, whether or not anyone assessed the risk of that declaration. Enforcing a state is not the same as tracing it to an approved baseline.

The category in the right-hand column is the tool’s primary capability — the thing it’s genuinely built to do. Read it as what you’re actually buying, regardless of the “Configuration Management” label on the box.

Notice what no column contains: a baseline. Not one of these tools maintains, on its own, the approved reference — or the documentation, approvals, and verified artifacts that legitimise it — that a change must be controlled against. Baseline management isn’t a feature any of them is missing by oversight; it’s outside what either category is built to do. So expecting these tools to deliver the discipline of Configuration Management isn’t a matter of picking a better one from the list — none of the list is suited to it, and assuming otherwise is exactly the assumption that ends in a production rollback nobody can explain.

Which tools do you need?

Knowing that none of these tools is a Configuration Management tool only helps if you know which of them — if any — you actually need. These are three independent questions, not a single choice. You might need one, two, or all three, and the answer to one tells you nothing about the answers to the others.

Do you need an asset management tool?

Ask: are you responsible for IT assets — hardware and software — that exist to run normal business operations? Email, workstations, file sharing, HR systems, the internal tooling a company needs to function.

If yes, you need to know what you have, where it is, and how it connects — which is what an asset management tool (the Definition 1 group) gives you. The larger and more regulated the organisation, the more formal that need becomes.

Do you need a technical productivity tool?

Ask: are you responsible for deploying and maintaining the state of software or hardware at a scale where doing it by hand is slow, inconsistent, or error-prone?

If yes, you need automation and reproducibility — which is what a technical productivity tool (the Definition 2 group) gives you. This is largely independent of the first question: a small SaaS team may need heavy automation and almost no asset management; a large corporate IT department may need the reverse.

Do you need Configuration Management?

Ask two things:

1. Do you have a product or system that generates income — directly, or by being critical to operations?
2. If a change to that system goes wrong, is your organisation likely to lose a material amount of money?
   1. This question is deliberately simple because you can assign the category of material financial loss to anything serious - e.g. direct financial loss, reputational loss, operational loss, liabilities from harming people, liability from regulatory non-compliance, loss of strategic advantage.

If yes to both, you need Configuration Management: the discipline of controlling change against an approved baseline, because the cost of an uncontrolled change is material. Note this is not a question about company size, industry, or whether you run ITIL. A two-person company running a payment system needs it; a large enterprise running only internal email may not. What triggers the need is consequence, not scale.

And note what this question is not: it’s not “do you have a CMDB” or “do you use Ansible.” You can have both and still not be doing Configuration Management — which is the entire point of everything above.

Without knowing precisely what your software is supposed to be — the approved baseline — how can you be confident it’s running reliably? “Reliable” only means something against a definition of correct. Configuration Management is what supplies that definition; everything else operates on top of it.

Choosing well means expecting the right things

Disappointment doesn’t come from the tools; it comes from asking a tool to be something it was never built to be. Tools are not solutions - start with the problem, and use the tool to the extent that it addresses the problem.

If you need asset management, the Definition 1 tools are built for you — ServiceNow, Cloudaware, Device42, and the rest. Use them to know what you have and how it connects. Don’t expect these tools to be the basis of a risk review. They can tell you what your systems currently are — but not what they were approved to be, and without that approved reference there’s nothing to assess a change against.

If you need technical productivity, the Definition 2 tools are built for you — Ansible, SaltStack, and the rest. Use them to enforce state at scale. Don’t ask them to make your change reviews meaningful from a risk perspective; a reviewer can check the code, but without a baseline there’s nothing to check the change against. Used as a Configuration Management tool, these quietly make the implementation the standard of truth — but an implementation can’t be a self-referencing baseline.

If you need Configuration Management, none of the categories above is your answer — and it’s important to be clear-eyed about that rather than talked into a tool that wears the label. Here are some alternative approaches:

• Borrow from industries that already do this. Configuration Management is a solved discipline in aerospace, defence, and medical devices, and the PLM tools built for them — such as Teamcenter, Aras Innovator — do it properly: baselines, controlled change, traceability. They prove the discipline is real and can live in a tool. But they were built for slow-moving physical products, not software, so adopt them judiciously: take them only as far as they genuinely improve your control over change, and no further. Push past that and you’ll spend more time fighting the tool’s assumptions than managing your configuration.
• Assemble it yourself from what you have. Hold the baseline and its approvals in documents, a spreadsheet, or a configured Jira project, and run change control by hand on top of your asset and automation tools. This works — at small scale, with discipline. Be honest that it strains as the system grows: the spreadsheet drifts from reality, the approvals lag the deployments, and the traceability you set out to maintain quietly erodes under deadline pressure. That erosion is the gap, and it’s the reason the discipline so often fails in practice even when people mean well.

Choosing well, then, isn’t finding the one tool that does everything. It’s knowing which of the three needs you have, buying the right tool for the two the market serves, and going in with your eyes open about the third. And whatever set of tools you land on, apply each to the right scope. This is all an expansion of an old IT saying: “When tools lead, fools follow!”.

Asset management tools track your core IT; they won’t tell you what your bespoke software was approved to be. Technical productivity tools give you speed and reproducibility; they shouldn’t be dictating what’s approved. Configuration Management tools borrowed from other industries can strengthen your baseline management; most of their features won’t apply to software, so take the ones that deliver measurable benefit and leave the rest.

Conclusion

If you take one thing from this article, let it be this: “Configuration Management” on a product page tells you almost nothing about what the product does. The label spans an inventory database and an automation engine — tools with almost nothing in common — and it’s applied to both by vendors who, in their own words, admit the category isn’t one thing. So the label is practically useless. Decode the tool by its actual capability, not its claim, and you won’t be the person expecting risk control from something built for inventory or speed.

For most needs, that’s the end of the story. If you need to know what you own, buy asset management. If you need to enforce state at scale, buy automation. Both are mature, both are excellent, and neither is pretending to be anything if you stop reading the label as a promise.

But if you need Configuration Management proper — if an uncontrolled change to your system costs real money or does real harm — you’re in the position this whole article has been circling. The discipline is necessary, it’s decades old, it’s solved in other industries, and there is no tool built to carry it for software. That leaves you either adopting a tool from a different industry or assembling it by hand. This is the status quo and it’s not ideal. It’s our opinion that for a software business exposed to that risk, the Configuration Management discipline — and the tool you use to hold it — is among the most consequential decisions you’ll make. Without a tool built for the discipline, you are forced into developing (or fighting) a tool and a method for managing baselines, and maintaining both which was never planned for and no-one was hired to do.

That gap is what we’re building for. We spent years watching good tools fail to do the one thing we actually needed — hold an approved baseline, with real traceability and the system-level relationships that make a change reviewable — so we’re building the tool we couldn’t find. It isn’t ready yet. In the meantime, we’d genuinely like to know how you’re handling it: most people we talk to are holding it together with spreadsheets and good intentions. If you’re interested in our progress or would like to try our tool at the earliest opportunity, let us know.

And if none of that applies to you — if your needs are asset management and automation, cleanly met — then take the simpler win: you now know what those tools are for, what they aren’t, and why the label confused the question in the first place. Either way, the next time a production change goes sideways and the room goes quiet, you’ll know exactly what was missing.

References

1. This article quotes the Cloudaware piece “The Best Configuration Management Software: Top 15 Tools Review” as it appeared in July 2026, archived here.