Functionality gets a tool onto your shortlist. Architecture decides what it costs you afterwards — in onboarding time, in time to value, and in what happens the day you want to add a discipline you did not buy.
You would be forgiven for thinking a shortlist of SAM or ITAM tools should be built purely on functionality. You need a tool that covers the right platforms, collects the right data, has a large enough software recognition library and supports licensing for the publishers you care about most. If it cannot support what your programme is trying to achieve, it is a non-starter.
But what about the architecture of the tools on that list? How much thought should you give to how they are actually built and deployed — and does it matter?
Here are a few reasons why the architecture of SAM and ITAM tools is more important than it first looks.
Many ITAM and SAM vendors have grown by acquisition, and what they now sell is a collection of integrated products — integrated in varying senses of the word — rather than one platform. The discovery and inventory module may have a completely separate interface and codebase to licence management, workflow automation or analytics. There may not even be a single database behind it, with data sitting in different places and different formats while the whole thing is presented as one product.
Why does that matter? Several reasons.
SAM and ITAM are not one-trick disciplines. Success usually requires a range of capabilities brought to bear on the same question, and if those capabilities do not work together properly, the work of joining them falls to you.
If you want to collect and then use inventory data from across the network, you need something that collects the right data in the first place — and by that we do not mean Windows PCs and servers, we mean every platform and every IP-addressable device — and then keeps it in a single source that can serve a wide range of both software and hardware asset management use cases. Products assembled from parts struggle here, because they tend to be restrictive about what is collected, what is retained, and what is made available to stakeholders outside the module that gathered it.
Architecture, in other words, directly limits which use cases a tool can support.
The answer. Look for a genuine platform, where collection, processing, storage and availability of data are foundational rather than per-module. Identify platforms where multiple use cases run off one data source without maintaining integrations between parts of the same vendor’s portfolio, and where data that matters to someone outside the SAM team is not discarded on the way in.
That is the design decision behind CerteroX. Five products — ITAM, SAM, SaaS Management, Cloud Management and AI Management — over one data model. Ten discovery methods, from the native agent to network scanning to cloud and SaaS connectors, all resolve into one schema. There is no reconciliation project between them, because there is nothing to reconcile. Software resolves against a Software Recognition Database of more than 3.5 million titles, and it is the same recognition for every product that needs it, not a separate library per module.
If you have budget sign-off and you are ready to go, the last thing you want is to wait months. Yet that is what routinely happens — waiting on internal teams to stand up servers or create service permissions, or waiting on the vendor’s professional services team to come on site, install technology, or provision cloud resources.
It gets worse when the technology needs multiple application and database installs. Worse still when getting different parts of the same vendor’s portfolio to talk to each other requires bespoke integration work.
Suddenly the software asset management project you signed off and paid for in March is still delivering nothing by the summer.
The answer. Look for a vendor and a platform that removes as much of the onboarding work as possible — either by using a true SaaS architecture to bypass standing up internal infrastructure almost entirely, or by using that same architecture to keep an on-premises install simple. The question to put to a vendor is specific and answerable: what has to exist in our environment before your product can collect its first record, and who has to build it?
Whether you run it in the cloud or on premises, an architecture designed for SaaS delivery is what gets a programme running in a reasonable time rather than a quarter.
Even once you are installed, you can be a long way from delivering anything back to the organisation. Tools that depend almost exclusively on client agents for inventory are especially prone to slow time to value.
Configuring and preparing agents for deployment is laborious, particularly in data centre scenarios or environments where multiple customers share cloud instances. And even once they are ready, agents can only go to machines the SAM or ITAM team already knows about. Remember Rumsfeld’s unknown unknowns. If the tool has no real discovery capability, your chances of full coverage are small, because the coverage is bounded by the list you started with.
Getting agents onto sensitive parts of the infrastructure — data centres in particular — can be close to impossible. And once deployed, it is common to spend the following months on agents that will not report back to the inventory server, or that drift out of date.
All of which means it takes a long time to build an accurate picture of what you own, and longer still to do anything useful with it.
The answer. Look for a platform that gives you flexibility: effective alternatives to deploying a client agent, and an easier route to collecting and processing the agent-generated data where you do use one.
Then deal with the unknown unknowns directly, with something that does not merely inventory what you already know about but actively finds devices you have no record of — again, not just Windows PCs and servers.
Concretely, this is what that looks like in CerteroX ITAM. Network Discovery sweeps a class-C subnet in under five seconds across NetBIOS, SNMP and ICMP, then probes port 22 to establish where an agent could actually be deployed — so discovery runs ahead of deployment rather than after it. Where an agent is not an option, there is agentless collection and a command-line collector (csinvcli) for locked-down machines, and standalone inventory for air-gapped and offline systems. Active Directory import brings in users, groups, computers, sites and subnets, and cross-references against an independent scan so that AD is a source rather than the source. Non-persistent VDI is handled as its own case, and duplicate system detection and stale device archiving keep the record from inflating.
The native agent itself covers Windows, macOS, Linux, IBM AIX, HP-UX and Oracle Solaris. Unix platforms are not an integration project here — they get the same agent, the same inventory cycle and the same licence engine as everything else, which is usually where a data centre-heavy environment finds out whether a tool was designed for it or adapted to it.
As you deliver results, you will want to widen the scope. Perhaps you start tracking cloud spend, or bring mobile devices in, or begin optimising a new publisher, or start doing deeper analysis of inventory, entitlement and spend data.
With some products, adding functionality feels like the original implementation again: new applications to install, configure and connect to the parts of the portfolio you already run. That is delay and cost at exactly the moment the programme has momentum.
You may also want to increase the number of devices being inventoried — through acquisition, new business units, new platforms. If you are running on premises, you need to think ahead about whether the product can process that volume in a sensible window, and whether the hardware underneath it can too. It is worth asking a vendor directly what happens to interactive users while an inventory load is being processed, and how long that window is at your device count.
The answer. It makes far more sense to reach new functionality the moment you want it, and the only way to get that is a platform where the functionality is already there, waiting to be switched on.
That is what the five-product structure is for. Adding cloud cost management is not a new implementation: CerteroX Cloud Management covers twelve cloud and data platforms, applies twenty-six named optimisation checks — abandoned instances, obsolete snapshot chains, instances stopped but not deallocated, and so on, each individually tunable — and ingests the FinOps Open Cost and Usage Specification natively. Across cloud environments under management the average saving is 38%.
Mobile is already in ITAM, covering iOS and Android including Apple DEP. Publisher depth is already in SAM, with dedicated engines for Microsoft, Oracle, IBM, SAP, Adobe and Salesforce. SaaS is already there, with 47 vendor connectors shipping and applications resolved against a catalogue of more than 35,000. And if the deeper analysis you want is in a tool you already use, there is a read-only API with a documented Power BI data source rather than an export routine.
For organisations deploying in the cloud, scaling to process more data is much less of a concern, since the resources behind it can be increased without a hardware conversation.
The functionality of a SAM or ITAM tool is unquestionably important. If you need to optimise Oracle data centre licensing and the candidate cannot inventory the data centre or model Oracle licensing, that is an immediate red flag.
But once a vendor claims it can support your scenario, what matters is the longer experience of buying, onboarding, running and supporting the thing. That is where architecture makes a real difference — to cost, to what you can actually do with it, and to the sanity of the team using it.
At Certero we treat architecture as one of the most important differences between us and the alternatives. The portfolio is built on one platform designed for how organisations operate now, not how they operated ten years ago. One data model, built rather than bought, with five disciplines reading from it.
The test to apply, to us or to anyone else, is simple enough. Ask what has to be built before the first record arrives. Ask what happens when you want the second discipline. If the answer to the second question sounds like the answer to the first, you are buying an integration project.
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.