A raw discovery list is not an inventory. Why inconsistent titles, editions and publishers make software data unusable for licensing decisions, and what normalisation has to do before the data is worth acting on.
You almost certainly have hundreds, and quite possibly thousands, of installed software titles across your organisation. Each of them may exist in several versions. Some are stand-alone, some are components of a suite, and some are recorded under a name that bears little resemblance to what you actually bought.
Identifying and inventorying all of that correctly is a genuine logistical problem. It is also unavoidable, because a normalised software inventory is the step that turns a list of installations into something you can make licensing decisions from.
Some organisations still try. It takes a very long time, and the result is out of date before it is finished, because the environment does not stop changing while you count it.
That gap is what pushed ITSM tools into offering discovery and inventory. The data they produce is useful for service management. For software licence optimisation it is nowhere near enough, and the reason is worth being precise about.
The same limitation applies to older ITAM tools and to products like Microsoft SCCM. Initial discovery returns a long list of software names, editions and publishers. That looks helpful. It is not, because the output is not consistent: the same product appears under several names, publisher strings differ by installer, and there is no intelligence layered over the raw strings. You cannot make a management decision from it.
A concrete example. Your discovery tool reports that SQL Server is installed on a machine, but cannot tell you which edition. SQL Server Express is free. Other editions are emphatically not, and are licensed by core with virtualisation and cluster rules attached. A tool that cannot separate them is not giving you a compliance position — it is giving you a question.
Then there is the problem of multiple inventories. You may have one tool for Windows desktop software, another for Oracle databases, and a third for Linux in the data centre. Each produces its own inventory in its own format. Reconciling them by hand produces a cross-referenced report that is stale by the time it is circulated, and an argument about which source is right.
To learn anything from software data, you have to filter out the noise and turn data into information. Specifically, normalisation has to:
An automatic, current, consolidated and normalised software inventory pays for itself in fairly ordinary ways:
Time back. The effort that went into building and reconciling the picture by hand goes into work that is worth more.
Visibility that holds up. Better visibility of software and hardware together reduces the risk of a non-compliance finding when a publisher audits you.
A CMDB worth trusting. Improved data can populate the CMDB, which improves every service process that depends on it.
Licence re-harvesting. You can identify installed software nobody is using and recover the licence for someone who needs it, under policy rather than by negotiation.
Shadow IT under control. Unauthorised software can be identified and removed before it becomes an unpatched security problem or an audit finding.
Normalisation is what makes optimisation possible. It reduces manual work, and it is the precondition for re-harvesting: you cannot reclaim a licence you cannot confidently identify.
The consolidated inventory the original version of this article described as desirable is now what CerteroX ITAM and CerteroX SAM do by default. It is worth being specific about how.
One recognition library. The Software Recognition Database carries over 3.5 million titles with centrally maintained categorisation, publisher normalisation and version recognition. Recognition resolves against that library rather than against whatever string the installer happened to write.
Lifecycle facts attached to the title. The Software Recognition Service adds release date, end-of-support and extended-support dates, so a normalised title carries the information you need to plan against it, not just to count it.
Standards-based identification. Software identification (SWID) tags are read and carry UNSPSC classification, which gives you a categorisation that is not private to one vendor.
Every source in one schema. Ten discovery methods — native agent, command-line inventory, agentless, standalone, Active Directory import, network scan, third-party ITAM import, cloud and SaaS connectors, browser monitoring and file metering — land in the same data model. Twenty-eight named system connectors, including SCCM, bring existing inventories in rather than replacing them. There is no consolidation project afterwards, because there is nothing left to consolidate.
Usage, not just installation. AppsMonitor meters actual file-based usage with
first-used and last-used tracking, and reports a % Used utilisation figure over
a rolling 90-day window. That is what makes re-harvesting defensible: you are
removing software on evidence, not on a guess.
Data you can take elsewhere. A read-only API with a documented Power BI data source means the normalised inventory is available to your own reporting, rather than trapped behind someone else’s dashboard.
A discovery list tells you what strings were found. A normalised inventory tells you what you own. Only one of those is a basis for a licensing decision, and the distance between them is where audit findings live.
Book a demo, or read more about CerteroX SAM and CerteroX ITAM.
Other posts covering the same ground.
Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.
A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.
An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.