Multiple inventory tools, an aggregation service, a bolt-on recognition database, a disconnected licence application and a third-party reporting layer. Stitched together, animated by a large surge of integration effort, and not quite all there. Six reasons a Frankenstack fails.
Let us be honest about Dr Frankenstein: the experiment was not an unqualified success. He did produce a living, breathing thing by stitching together an assortment of limbs and other parts. He got blood moving, and sparked a borrowed brain and heart into life with an enormous surge of electricity. What he did not produce was fully integrated functionality and intelligence.
The creation was a warning about more than meddling with the laws of nature. It was a warning about assembling pieces at random and expecting them to work together.
So why do so many organisations think it will work with their Software Asset Management and IT Asset Management technology?
Bring together multiple inventory tools, some form of data collection and aggregation service, a separate software recognition database, a disconnected licence management application and a third-party reporting or analytics interface — and ask honestly whether that arrangement was ever going to deliver real SAM value.
We call it a Frankenstack: a disparate collection of technologies forced to work together in ways they were never designed for. We are all comfortable now with the idea of integrating applications, moving data between them and assembling something that fits our exact use case. The idea is sound.
The problem is that the idea is consistently better than the reality, and nowhere more so than in SAM and ITAM. Building and, more painfully, maintaining a Frankenstack runs into the same six problems every time.
Multiple tools mean multiple applications, multiple databases and the middleware between them. Combined, they consume far more infrastructure and far more administrative time than a single platform doing the same job. That is cost and overhead that many budgets simply cannot carry, and it grows with every component you add rather than staying flat.
Change the configuration of one component, or upgrade it, and the data flowing through the chain suffers. Integrations that were built against a specific version behave unpredictably against the next one. The smallest change in the wrong place breaks something three steps downstream, and it usually breaks quietly — the data keeps arriving, it is just wrong.
When the output does not look right, the diagnosis starts with working out which part of the stack produced the error — or whether it was the wet string connecting it all together. Every component has a different vendor, a different log format and a different support desk, and each of them can plausibly point at the others. Time to resolution is measured in weeks.
More layers means more applications to patch and maintain separately, more credentials held in more places, and more data transfers to secure. Every integration point is a place where data at rest or in flight has to be protected by somebody. It is an avoidable security burden taken on for no benefit.
Managing several data sets across several interfaces is slower and more error-prone than doing the same work in one. It gets worse when different parts of the stack are owned by different teams with no shared mandate — at which point getting an answer requires a meeting rather than a query.
This is the tell. When the stack cannot perform the calculation or run the workflow, Excel fills the gap and quietly becomes the most important component in the architecture. The manual overhead goes up, the data ages between refreshes, and the position you present is a spreadsheet that somebody maintained by hand — which is precisely the situation the tooling was bought to eliminate.
It is tempting to assume Frankenstacks are an end-user creation: existing technology cobbled together in the hope of meeting a new business need. That is not always where they come from.
Vendors build them too. Tool sets — call them platforms or portfolios if you prefer — that have grown through acquisition or alliance are frequently guilty of it, as the vendor rushes to build integrations between organically developed technology and whatever was bought or licensed. Those integrations paper over the cracks. They disguise the fact that different parts of the portfolio have entirely separate code bases, are sometimes written in entirely different languages, and share no commonality at all in how they collect, store or process data.
The cracks reappear on schedule: when one part of the portfolio is upgraded, and when a customer tries to build or maintain a custom integration across it.
The practical test is simple and worth applying during any evaluation. Ask how many databases the product has. Ask whether the SAM module and the ITAM module were written by the same team. Ask what happens to your custom reports when one component goes up a major version. The answers are usually more revealing than the demonstration.
In some circumstances, using more than one tool is unavoidable — particularly early on, while you are still proving the value of the discipline. That is a reasonable place to start. It is a bad place to stay, and the point is to understand the downsides you are accepting, even when everything carries the same vendor’s badge on the front.
The alternative is a platform whose parts were designed together from the outset. CerteroX is five disciplines — ITAM, SAM, SaaS Management, Cloud Management and AI Management — on one platform with one data model, built rather than acquired. In practice that means specific things rather than architectural adjectives:
There is a benefit on the vendor side too, and it reaches the customer. A single platform is far easier to support, so support calls get resolved faster. Development is not spent maintaining integrations between internal products, so features arrive more often. And upgrades are one upgrade, rather than a sequencing exercise across components that each have opinions about what version everything else should be on.
If you want your SAM programme to be less trick and more treat, be wary of building — or buying — a Frankenstack.
Book a demo and see the whole thing running as one.
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.