Confessions of a Software Tax Collector

I have to be honest, I have a real confession to make.

For a good chunk of my early career, I was a Software Tax collector, and a rather enthusiastic and successful one as it happens! Now, before anyone gets too excited, I wasn’t wandering around enterprise IT departments demanding money with menaces. Naturally, I was doing something far more respectable... I was helping the world’s biggest technology vendors sell their latest and greatest kit!

You see back in the ‘90s, we sold the latest software, the newest servers, the biggest storage systems and all the wonderful technology that made enterprise IT tick. Mainframes, UNIX servers, SANs, networking, databases, clustering, virtualisation, backup and recovery systems. You name it, we had our hands on it.

We designed it, built it, installed it, we won awards for it (industry and the OEM!) and, when things went horribly wrong at three o’clock in the morning, rest assured we were also the poor unfortunate souls trying to fix it. And we genuinely believed we were doing the right thing, because it’s how we’d been taught.

You see for decades we’ve been conditioned to follow a fairly predictable set of rules. The vendor develops the software, determines the roadmap, decides when support ends and eventually tells everyone it’s time to move on. The customer plans the budget, the IT team prepares the project, and business partners like us turn up with the engineers and the latest shiny objects. Everyone has a role and plays their part. And nobody really questions the rules because, well… because those are the rules.

Now, we weren’t deliberately pushing unnecessary technology onto customers. We actually cared enormously about the environments we built and the people who depended on them. Actually, I correct that… we took HUGE pride in what we did. Our reputations were on the line every time something went wrong.

But never did we question whether the vendor’s technology lifecycle actually needed to become the customer’s business lifecycle.

We honestly didn’t know there was another way.

And I think that’s where my confession gets a little more interesting. Rewind a decade or two, and there’s one particular experience that stands out involving one of our largest enterprise customers at the time, an international BioTech company. Little did I know that years later, I’d find myself back with this customer, helping them avoid prematurely replacing the very software we’d once enthusiastically sold them.

You literally couldn’t make it up! Well, apparently you could… because we did.

The project that was never just a software project

Cue the scene...

An existing backup and recovery environment that was doing its job, but it was getting old. Or, more accurately, it was getting old according to the industry’s definition of old. And in those days, that was enough. So along we came, armed with our expertise and the latest enterprise backup and recovery platform from one of the world’s biggest software vendors. Fantastic!

Now, anyone who’s spent time in enterprise IT will know that the word implementation is doing an enormous amount of heavy lifting here. We didn’t just rock in some day and install some software, configure a few backup schedules and head home for a well-earned pint. Ah, if only!

We needed hardware, tape libraries, storage capacity on the SAN, software agents installed across servers, infrastructure changes and planned outages. Then came the testing. Backups, recovery, clustering failovers, database consistency, yet more testing…. I mean the works.

And because this was a BioTech company, operating in a heavily regulated pharmaceutical environment, we had GMP validation teams, system qualification, standard operating procedures and enough documentation to keep a small library in business. All perfectly legitimate requirements, I should add. When you’re dealing with critical systems in a regulated pharmaceutical environment, you don’t get to cross your fingers and hope for the best.

But step back for a moment and have a think about what was happening. We’d taken a functioning backup environment and embarked on a significant replacement programme, consuming infrastructure, engineering resources, consultancy, validation effort and introducing operational risk into systems that were already working. Why?

Well… because the old system was “old”. Not broken mind you, “old”.

It's just what we did.

The project was successful, we delivered what was required, so everyone was happy, and we merrily moved on to the next one. But there’s something in this that I really didn’t fully appreciate at the time.

The software invoice was only the beginning.

The real cost of that project was scattered across hardware, storage, consultancy, internal resources, testing, validation, operational disruption and all the work those people weren’t doing while they were occupied with the project. Now multiply that by the hundreds, sometimes thousands, of enterprise applications running inside a large organisation.

That’s an awful lot of people, money and effort. And we were doing this sort of thing all the time… every minute, every hour, every day.

Same customer. Same software.. but this time a completely different conversation.

Fast forward a number of years. Tomás and I had founded Origina in 2012, and we’d started challenging something that had been accepted as gospel across enterprise IT for decades. The notion that somewhere along the journey someone slapped a “best before date” on software.

And one of the first customers to join us on that journey? Yes.. the very same BioTech company.

And rather wonderfully, it was the very same backup and recovery environment we’d previously sold and installed. Except this time we weren’t there to sell the next shiny object to the benefit of someone else’s shareholders. We were there to help them avoid buying one.

You see, their software had reached the end of the vendor’s support lifecycle, just as the customer was undertaking a wider technology transformation that involved upgrading its operating systems. Now, anyone familiar with enterprise software will recognise the problem immediately. The existing (old!) backup product version wasn’t supported by the OEM on the newer operating system, and by God you can't be seen to run an “unsupported” version. I mean let’s face it… in traditional enterprise IT thinking, that’s pretty much the end of the conversation.

The compatibility matrix says No, the vendor says No. And, as we’d all been taught for decades, the natural assumption is that the answer must be No, right? Time for another upgrade. 

Except you see, we weren’t entirely convinced. After all, we’d installed the bloody thing! We knew how it worked, we knew how good it worked, its dependencies, its architecture and what it was actually capable of doing. We also understood the context of how the customer depended on it.

So we asked a rather obvious question.

What if it actually works?

I mean not according to the OEM's published support matrix. We knew what that said. No, I mean technically. Could the existing backup software operate reliably with the newer operating system? And could we prove it?

That became one of the earliest outings of what we called our Interoperability Validation service. Rather than accepting that an unsupported combination was automatically an incompatible combination, we set about independently validating whether the technologies could operate together. And guess what?

They could! No magic, no hocus pocus… it just worked. We demonstrated that the existing backup & recovery software could continue operating with the newer operating system, despite that configuration falling outside the OEM's supported combinations. You see, a vendor’s interoperability matrix isn’t proof that something technically won’t work. It merely tells you what the vendor is prepared to support, not necessarily everything the technology is capable of doing. And ask yourself this… do you think vendors keep updating those matrices once their software reaches End of Support?

The outcome? Well, the customer was able to progress its transformation without being forced into another major backup and recovery upgrade. A major replacement project, with all the additional infrastructure expenditure, engineering effort, testing, validation and operational risk that would have come with it? Avoided.

And here’s the really lovely part.

When the customer upgraded its operating systems again a few years later, we repeated the very same exercise. Another new version, another compatibility challenge, another opportunity for the industry to declare that the old software had reached the end of the road. Except it hadn’t. We validated it again and extended its useful life even further.

Think about the irony.

The same people who’d originally sold and installed the software were now helping the customer avoid replacing it.

And somewhere along the way, we’d fundamentally changed how we thought about enterprise technology. We’d stopped asking, “What does the vendor say we need to do next?” and started asking, “What does the customer actually need?”

They are two very different questions. And, as we discovered, potentially two very different answers.

The great enterprise technology fugazi

There’s a brilliant scene in The Wolf of Wall Street where Matthew McConaughey’s character describes the stock market as a “fugazi”.

Something that looks real but isn’t quite what you think it is. Now, of course I’m not suggesting enterprise software is imaginary. I’ve spent far too many sleepless nights fixing the bloody stuff to make that claim.

But I’ve often thought about that scene when sitting in meetings discussing the cost of enterprise technology because the number everyone can see is the invoice. The number nobody can see is everything that follows it. The infrastructure changes, integration work, testing, retraining, compliance, downtime and operational risk.

I've never seen that appear in a spreadsheet.

What didn’t get done? What was the missed business opportunity? What new product wasn’t developed because the engineering team spent six months preparing for an upgrade? What AI initiative was delayed? What customer experience wasn’t improved?

Since we founded this business, we’ve tried hard to explain this hidden economic burden to customers. We could demonstrate the direct maintenance savings from avoiding unnecessary upgrades, but quantifying the wider impact was... well, much much harder. You see through our lens we could see it as clear as day… we knew it was happening because we’d actually lived it. Our customers knew it was happening because they were paying for it. But we couldn’t demonstrate just how widespread the problem had become.

Until now.

Twenty-eight percent. Seriously?

Today, Origina, in partnership with Thinkers50, has published the first paper in our Software Tax research programme. Written by Tomás and Professor Marshall Van Alstyne of Boston University, and drawing on research commissioned by Origina and conducted by Censuswide among 2,018 senior IT decision-makers across the US and UK, it puts some extraordinary numbers behind a problem we’ve been talking about for years.

On average, 28% of enterprise software budgets go on vendor-driven upgrades, migrations and licensing changes that organisations would not have actively chosen (base 2,018).

Twenty-eight percent!

Imagine running a business where more than a quarter of your software budget is being consumed by changes you wouldn’t otherwise have prioritised. And remember, that’s before considering the wider disruption and opportunity cost.

What’s very interesting is that the research also found that 95% of respondents said their organisations had paid for a vendor-driven upgrade, migration or licensing change in the past three years that they believed at the time would reduce performance, reliability or business value (base 2,018). More than half (53%) have done so more than once. Now, that one really stopped me in my tracks.

Not because I haven’t witnessed it. I have, many times. But because we’ve finally quantified just how widespread this has become. Think about the absurdity of that for a moment.

We have some of the most experienced technology leaders in the world authorising expenditure on changes they believe will leave their organisations worse off. And I understand why. I’ve sat in those very same meetings, faced those same decisions and felt the responsibility that comes with keeping critical systems running.

When the consequences of getting it wrong could be catastrophic, following the vendor’s roadmap often feels like the only responsible decision. Particularly when nobody has shown you a credible alternative.

And that’s what troubles me. Not the judgement of the people making these decisions, but an industry model that has made the alternatives so difficult to see, let alone pursue. As the research highlights, this is less about poor decisions and more about the incentives and constraints that shape them.

You see, you can’t just drop support and hope for the best. There are genuine concerns about security exposure, contractual consequences and potentially jeopardising critical business systems. These are serious responsibilities, and I completely understand why CIOs take them seriously.

So they make what seems like the safest decision. They follow the roadmap, and the cycle continues.

Perhaps the most depressing finding for me was that 84% said their senior engineering talent was always or often diverted to maintaining vendor-driven change rather than building future capability (base 2,018). Now that is a tragedy. We’ve spent decades building extraordinary technology capabilities inside businesses, only to have some of our brightest people continually occupied with keeping pace with somebody else’s commercial timetable.

Imagine, just imagine for a second, what those people could achieve if we gave them back that time.

And if that wasn’t bad enough, nine in ten respondents said their organisations had retired or scrapped perfectly functioning hardware simply to meet a software vendor’s support deadline, losing an average of 1.65 years of potential hardware life (base 2,018).

Think about the environmental waste in that alone. All that embodied carbon, all those resources, and perfectly good technology that could have continued delivering value. Retired prematurely, not necessarily because it had stopped working, but because someone else’s support calendar said it was time.

And I’ll be honest, I’ve never met a CIO who wanted to spend millions upgrading something that already worked. But I’ve met plenty who felt they had no choice.

Hang on. Isn’t this a CFO problem?

For years, we’ve been having this conversation primarily with CIOs. And rightly so, because they’re the people who understand the technology, the complexity and the operational consequences better than anyone.

But increasingly, I’m beginning to realise we need to bring someone else into that conversation.

The CFO.

Because when a vendor-driven upgrade consumes millions in capital and months of engineering effort, that’s no longer simply an IT decision. It’s a business investment decision.

And I think that’s where we’ve been missing a trick. The CIO understands the technology and the risk, but the CFO needs to understand the full economic consequences of the decision. They need to be having that conversation together, rather than treating it as another unavoidable IT expense.

So... if a business is about to drop $15 million upgrading a system that’s already working, surely the first question should be whether that’s the best possible use of $15 million? What would happen if we didn’t upgrade? What other options exist? And what could the business genuinely achieve if that money, and all those talented people, were invested somewhere else? Could we maintain the existing environment? Could we address the specific security or compliance requirement without replacing everything around it? Could we invest that money somewhere that would actually make the business more competitive?

Those are questions every CFO should be asking. Because the true cost of an unnecessary upgrade isn’t just the money that leaves the bank account, it’s everything the business sacrifices to make that upgrade happen. And I've never seen that cost appear on a vendor’s proposal.

The roadmap was never ours

I often say that at Origina, we’ve earned the right to be in the room. Not because we’re somehow smarter than the technology vendors, to the contrary, they’re full of extraordinarily talented people who build remarkable products.

But because we’ve experienced this industry from both sides. We sold the technology. We designed the environments. We installed the software. We dealt with the outages, the integrations, the testing and the inevitable surprises that arrived at the worst possible moments.

You see we know what it takes to make these systems work, and more importantly we see very clearly the risk within these enterprise IT systems, and we know what happens when you change them.

For the last 14 years we’ve been challenging the status quo and proving that there are other ways to maintain and protect those investments. Has it been easy? Not remotely. Has it been rewarding, absolutely!

But here’s what gives me enormous optimism. For much of my early career, I genuinely didn’t know there was another way. In fact, when Tomás first came to me with the idea for Origina, I laughed at him! I mean, seriously, how could we possibly support enterprise software better than the very people who built it?

But thankfully, I was curious enough to listen, open-minded enough to challenge everything I’d been taught, and willing to explore what might actually be possible.

And I now recognise that same mindset I once had in so many of the CIOs we meet today. Not because they’re wrong, but because we’ve all grown up following the same industry playbook.

The difference is that today we can show them something we couldn’t show ourselves back then. There are alternatives, and they have a choice.

And perhaps that’s the biggest lesson I’ve taken from this journey. Don’t wait for someone to tell you there’s another option. Ask the awkward questions and find out what’s actually possible. Because sometimes the biggest breakthrough isn’t a new piece of technology, it’s simply looking differently at what you already have.

So here’s my challenge to every CIO, CFO and CEO reading this.

The next time a software vendor tells you it’s time to upgrade, migrate or replace your infrastructure, don’t automatically assume they’re wrong. But don’t automatically assume they’re right either.

Sit down together. Understand what the business actually needs, calculate the full cost, not just the invoice, and be curious enough to explore the alternatives.

And before committing millions of dollars and months of your best people’s time, ask one simple question:

Are we doing this because it’s right for our business, or because it’s right for our software vendor?

Because I can tell you now that after more than 30 years in this industry, I’ve come to believe something that would have sounded almost heretical to the younger version of me. Just because the vendor says it’s time doesn’t mean it’s time.

The next time a support deadline arrives, the right answer may well be to upgrade. But don’t mistake the deadline for the decision.