“Sometimes you just have to push through: a deep dive through the sh**, and you come up holding a gold nugget.”
(Richard Seidl)
It’s a shame, every time. I visit companies and look at their IT and software landscapes: legacy systems that grew hysterically rather than historically, and hardly anyone dares to modernize them. Instead of the lovely Shire, with its lush meadows, fruitful orchards and well-kept front gardens, I see Mordor: sulfurous swamps, ash-covered land and barren soil. And every so often an orc peers around the corner.
People keep bolting adapters onto long-outdated systems that barely anyone can maintain anymore, just so data can be shoved back and forth in every direction. Batch jobs transform data sets of dubious quality. And when a system doesn’t fit at all, someone builds an equally complex wrapper in-house and lays it over the top. The overall architecture doesn’t deserve the name, because every system is so tightly meshed with the others that they all just somehow live in symbiosis.
DevOps, Agile and AI Don’t Solve the Problem
And then comes the wish to introduce DevOps and CI/CD. But the systems depend on each other so heavily that nobody knows where to start. So a few isolated solutions get piloted, and the rest stays as it is for the time being.
Sadly, this is no one-off, and it is especially common in larger companies. And rather than tackle the issue, they distract themselves: with an agile transformation (which quickly hits its limits in this setting, too) or, more recently, with AI. Neither solves the actual problem: the legacy of the last 20 to 30 years. Quite the opposite. The whole patchwork of add-ons piles up even more technical debt.
Why Legacy Systems Rarely Get Modernized
So far, I haven’t met a single company that seriously dares to go through this valley of tears, meaning one that puts energy, effort and money into cleaning up the toxic waste of the past. (If you’re a counterexample, please get in touch!)
Granted, there are some real arguments against it:
- Features: Complexity could be reduced in many places. If only it weren’t for “Maybe someone will need this feature again” or “We don’t even know whether anyone still uses it, so let’s leave it in.” Even when the cost-benefit analysis says the feature should go, a voice from the back pipes up: “But I need that.” And it stays.
- Politics: Surprisingly often, these initiatives aren’t blocked by technical constraints but by people not wanting them. In the end, it’s about power. Project manager, team lead, head of department or division head: everyone has their turf, their budget, their responsibility. That’s the end of any view of the IT as a whole. Coalitions, trench warfare, proxy battles and a lack of backbone are on display across the board.
- ROI: With AI and agile, it’s fairly easy to make the short-term benefits add up on paper. Coming to terms with old systems is a different story, because in the end nothing new gets built. The systems do the same as before, or less (because some of it isn’t needed), albeit probably more efficiently, transparently and sustainably.
Why Modernizing Is Worth It Anyway
So why bother at all? For me, a lot speaks in favor of it. Short-term profit isn’t one of those reasons, and that’s probably the problem. But the value software creates today is about more than that: the long-term survival of the company, being attractive to new hires, scalability and flexibility. I think many companies don’t even realize that their “value” actually lies in their software, whether they’re banks, insurers or energy companies.
Well, I haven’t given up hope that the industry will start moving and a few gold nuggets will come to light.
