Matt Fisher, Chief Marketing Officer, Certero
Don’t build a SAM Frankenstack this Halloween!
Let’s face it, Dr Frankestein’s experiment wasn’t exactly an unqualified success. Yes, he managed to create a living breathing thing by stitching together an assortment of limbs and other body parts. He somehow got blood flowing and managed to spark the ‘borrowed’ brain and heart into life with a massive surge of electricity. But the resulting “monster” wasn’t quite all there in terms of fully-integrated functionality and intelligence.
Dr Frankenstein’s creation was a warning to us all about not only messing with the laws of nature, but the concept of randomly stitching pieces together and expecting them to work seamlessly.
So why do so many organizations think it will work with their Software Asset Management and IT Asset Management technology stacks?
When you bring together multiple inventory tools, some kind of data collection/aggregation service, a separate software recognition database, a disconnected license management application and a third-party reporting or analytics interface, is there ever any real chance of it delivering real SAM value?
It’s what we refer to as a ‘Frankenstack’, a disparate collection of technologies that are forced to work together in a way that they were not originally designed to do. These days, we’re used to the idea of integrating multiple applications, to having a seamless data flow across them and to be able to build solutions that might our exact use cases.
But the problem is that the concept is often much better than the reality. Especially in the SAM and ITAM worlds. When it comes to building (and maintaining) a Frankenstack, there are several common issues:
- Technology footprint – by using multiple tools, it is likely that the combined apps, databases and middleware will consume far more resources than a Unified Platform approach would. This creates cost and overhead many budgets can’t support.
- Integrations are brittle at best – it’s often the case that changing the configuration or upgrading one part of the Frankenstack has a negative impact on the flow of data through it, with brittle integrations easily broken by the smallest of changes.
- Problem resolution means finding a needle in a haystack – when things don’t work as intended, finding the cause of the problem can be a real challenge, trying to identify which part of the stack – or the wet string connecting it all together – is the culprit.
- Increased security fears – the more layers to your Frankenstack, the more apps that need to be maintained separately and the more data transfers that need to be protected. It’s an unnecessary security headache.
- Poor user experience – managing multiple data sets and working in multiple UIs decreases the user experience and affects productivity. It’s even worse when different parts of the Frankenstack are managed by different teams who have no real mandate to work together.
- More work gets done in spreadsheets than tools – as users can’t perform the necessary calculations or automated workflows, Excel becomes a major part of the Frankenstack, upping the manual overhead and slowing down the process of achieving usable data.
Not all Frankenstacks are created by the end user organization!
It’s easy to think that Frankenstacks are created by the end user, cobbling together bits of existing technology in the hopes of creating an effective solution to a new business need. That isn’t always the case. Even tools vendors can create Frankenstacks! Tool sets (or call them ‘platforms’ or ‘portfolios’ if you prefer) that have grown through acquisition or alliances are often guilty of becoming Frankenstacks, as vendors rush to create integrations between their organically-developed technologies and those that they have acquired or licensed. These integrations often cover over the cracks and disguise the fact that different parts of the product portfolio have entirely different code bases (or are even sometimes coded in entirely different languages!) and don’t share any commonality in how the collect, store or process data. But those cracks often reappear when one part of the stack is upgraded or when customers try to implement (or maintain) custom integrations.
Don’t create a SAM monster!
In certain circumstances, using multiple tools as part of your SAM technology stack is inevitable (at least in the early days as you prove the value of the SAM discipline), but it’s important to understand the downsides of working with multiple technologies, even if they are from the same vendor. The alternative is to look for a truly integrated solution based on a Unified Platform. The complete opposite to a Frankenstack, the many parts of a Unified Platform have been designed from the outset to work together, to share a common data source and code, to provide the user with a better experience through a single UI and easier analysis of data. What’s more a Unified Platform is actually easier for the vendor to support as well, which means faster resolution of support calls. Accelerated development times mean that customers get access to new features more often and upgrading is much simpler. If you want your SAM program to be more less trick and more treat this Halloween, beware of building or buying a Frankenstack!
