Fragmented functionality, lengthy implementations and datasets that have to be stitched together by hand. Why the architecture of a legacy ITAM or SAM tool becomes your problem, and what a single data model changes.
Incumbent ITAM and SAM tools struggle to support business transformation, cloud migration or a serious security programme. That is not a failure of intent. It is a consequence of architecture, and it is why the gap between what these tools promise and what they deliver has been so durable.
The common perception, after more than a decade, is that the established vendors over-promise. They keep doing it because the alternative is admitting the constraint.
Innovation in hardware and software has consistently outpaced the ability of legacy tools to absorb it. Virtualisation, then SaaS, then multi-cloud, then containers, then AI — each arrived faster than a mature codebase could be reworked to accommodate it.
Faced with that, a vendor has two options: rebuild, or bolt on. Almost all of them bolt on, either through unsatisfactory modifications to the existing product or by acquiring somebody else’s. The outcome is the same in both cases — functionality that sits outside the core, does not share its data model, and does not deliver the value the datasheet claims for it. The gaps between the pieces get plugged by people doing manual work.
It is like a house built decades ago that has had extension after extension added to it, by different architects, using different materials, to house a growing number of residents. Each addition made sense on its own. The result is a disorienting, poorly constructed complex that does not meet anyone’s needs. If you were designing it today, knowing what you now know, you would not design it that way.
The same is true of software built by successive teams in different languages, using different methods and different architectures.
There are many, but the ones that consistently do damage are:
Each of those looks like an inconvenience. Together they determine whether your asset management function is capable of supporting a strategic programme, or whether it is fully occupied keeping itself alive.
Without end-to-end SaaS delivery, you cannot automate. So you hire people to bridge the gaps. The cost of running ITAM and SAM goes up, and the proportion of that cost producing insight rather than maintaining data goes down.
Some SAM tools are delivered as SaaS but discard the hardware data. Software asset management depends on knowing what the software is installed on — the processor type, the core count, the virtualisation topology, the cluster membership. A SAM tool that throws that away is computing a licence position from half the inputs. Getting it back means procuring a separate on-premises ITAM tool, which means server provisioning, which means sign-off cycles that push implementation out by months before configuration has even started.
Configuration is then handed to the customer. This is more consequential than it looks. When the vendor does not configure the system, the vendor is not responsible for the data it produces. If the tool returns a poor or inaccurate licence position, that is now your problem — and you will discover it during an audit.
Day-to-day operation stays manual. Basic tasks need data entry. Datasets from different sources cannot be merged automatically, so analysts stitch them together by hand to answer questions that should be queries. Every manual join is an opportunity for an error that invalidates the analysis downstream, and nobody finds those errors until something expensive depends on them.
And nobody gets the whole picture. With several tools and several datasets, each behind its own login, there is no single view of what the organisation owns. Without that, transformation programmes, cloud migrations and security improvements all become harder than they should be, because each one starts with weeks of establishing the baseline.
In 2013 Certero scrapped its version 3 products. Rather than extend a codebase that could not accommodate what was coming, the team rebuilt from the ground up around a single data model.
That decision is why the platform looks the way it does now.
One schema, ten ways into it. Agent, command-line, agentless, standalone, Active Directory, network scan, third-party ITAM import, cloud and SaaS connectors, browser monitoring and file metering all land in the same schema. There is no reconciliation project between discovery methods, because there is nothing to reconcile.
Six operating system families, one agent. Windows, macOS, Linux, IBM AIX, HP-UX and Oracle Solaris get the same native agent, the same inventory cycle and the same licence engine. Most platforms treat Unix as an integration problem. It is where the expensive licensing lives, so it is treated as an operating system like any other.
Publisher depth, not generic recognition. Dedicated licence engines for Microsoft, Oracle, IBM, SAP, Adobe and Salesforce. A generic tool can tell you that you have 400 installations of Oracle Database. It cannot tell you which options are enabled, which cores are licensable under which core factor, or which hosts are covered down by an Enterprise Edition pool. That gap is where the audit finding lives. Software recognition resolves against the Software Recognition Database — over 3.5 million normalised publisher, product and version titles.
Five disciplines, not two. When this was written the portfolio was ITAM and SAM. It is now ITAM, SAM, SaaS Management, Cloud Management and AI Management, on the same platform and the same data model: 47 SaaS connectors against a catalogue of more than 35,000 applications; 12 cloud and data platforms with 26 individually tunable cost recommendation types and native FOCUS support; and AI governance covering agents, models, compute and seats. The point is not the breadth. It is that adding a discipline did not require adding a tool, a login or a reconciliation step.
Delivered as SaaS, with the full product. No on-premises servers to procure, so there is no infrastructure sign-off cycle standing between the decision and the data. On-premises and hybrid deployment remain available where policy or regulation require them, and they are the same product rather than a reduced version of it.
Governance as code. Governance Policies evaluate conditions continuously across everything discovered, built on a reusable filter builder and exportable as JSON. Zones segment data by entity; Reporting Levels restrict visibility by organisational unit or location. Across the platform there are 452 documented entity types, which is a fair proxy for how much of the real world the data model actually represents.
Not “can you do SaaS management?” — every vendor says yes.
Ask instead: is it the same data model? Is the hardware inventory the licence engine consumes the same record your discovery tool produced, or a copy that has been transformed twice on the way? When you add a discipline, do I add a tool? And when the answer to a licensing question is wrong, whose responsibility is the configuration that produced it?
The architecture answers those questions long before the roadmap does.
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.