Out with the Old Software

Buildings are renovated, vehicle fleets replaced, machines exchanged. Only the software that runs the core processes has stayed the same in many organizations for decades. Using two examples from our consulting practice, this article shows why building on top of old systems ends up costing more than replacing them, what technical debt actually costs, and which barriers must fall before an organization can become a self-driving company.

One ticket, one hundred million: what building on top costs

A public transport operator wanted an app that lets passengers search for a connection on their phone and pay for the ticket with a single tap. The task sounds manageable, and it is: an app with this functionality is usually budgeted at around 70,000 euros. In the end it cost the company more than 100 million euros. I described the example in my book "Das selbstfahrende Unternehmen" (Springer Gabler 2021, in German) because it shows the mechanism so clearly.

The app had to be built on five large and countless small existing applications, classic legacy backend systems written in programming languages that were decades old. That alone might have multiplied the effort by five, to roughly 350,000 euros. Even if connecting each of the five large systems had cost a million euros, we would have arrived at five million. Where did the remaining 95 million go?

The answer does not lie in the technology alone. Each of the large legacy applications belonged to one business unit and was owned by its own department head. These managers pursued different goals and did not pull in the same direction. Instead of rebuilding the overall system from the ground up, the app was placed on top of the tangle of legacy systems. Cross-border traffic added further interfaces to international connection data. The number of external and internal implementation teams grew, and with it the number of interests, and the internal power structure blocked decisions that had long been technically obvious. The result is an overpriced, error-prone application that is not intuitive to use and, on top of that, slow.

The lesson is not that apps are expensive. The lesson is that the cost of an initiative is determined not by the new part but by the old part it has to be built upon.

Hundreds of people keeping the old systems alive

Almost all banks face the same problem, only on a larger scale. Their basic software structures are outdated, and instead of renewing them, the institutions maintain IT and software departments with several hundred employees who build new applications around the old cores. Managing these departments requires, in our experience, around ten percent middle and senior managers; for a software department of 700 people, that is 65 to 75 managers. Coordinating with the business departments takes hundreds of meetings per year. Launching a fundamentally new process often requires three years of the most laborious work.

Add to this the resistance of the users. People are creatures of habit. Paradoxically, many have grown fond of their old software with its black command window and clumsy commands and have no intention of opening up to new solutions. Taken together, this is a broad mass that puts up considerable resistance to large software initiatives, and in many organizations it is the majority.

One detail makes the scale of the problem tangible: the most important core banking applications of a large share of Europe's systemically relevant banks are written in COBOL or related programming languages from the 1950s. The technology behind COBOL is based on punched cards, and punched cards were historically developed to control mechanical looms. At their core, banks are therefore working with a technology carried forward several times over that goes back to looms, while outwardly they try to offer the same modern omnichannel service via smart glasses, WhatsApp, app, website, telephone, and branch counter. According to my assessment in the book, around 80 percent of all banks still run on this legacy base. It is easy to see why this does not produce much agility.

Technical debt: the bill always arrives

There is a precise term for this condition: technical debt. Whether building services, vehicles, or software, every technical system that does not receive ongoing investment accumulates technical debt. Skip the services on your car and you save in the short term, then pay for the engine damage later because the lubrication was missing. Software is no different, only less visible.

As a rule of thumb, around 15 to 20 percent of the original build value of a piece of software must flow continuously into improvements and renewal, known in the trade as refactoring, to prevent technical debt from accumulating. This ratio comes from our experience in software strategy projects and is described the same way in the book. If it is set to zero for years, the debt does not disappear. It grows with interest and eventually falls due, either as a major replacement project or as an initiative like the ticket app whose costs nobody can explain anymore. In software in particular, many organizations, up to and including large corporations, have ignored this rule for decades. They carry enormous technical debt in their "belly" in the form of heterogeneous systems.

Three observations from our practice explain why the debt goes unnoticed for so long:

• Business-critical software lives a long time. Backend systems typically have a life cycle of 15 to 20 years; the major ERP vendors also release a generational change at roughly this rhythm. Anyone who postpones the renewal decision easily stays tied to the legacy base for years to come, because the next window opens only with the next generational change.
• Projects are systematically underestimated. In our experience, more than 80 percent of industrially produced software projects are estimated incorrectly, and the estimates are usually 40 to 50 percent below the actual effort. When decision makers are told the true costs up front, many projects are never started at all, and the legacy base remains.
• Software has no inspection sticker. Almost every technical device is subject to a periodic inspection of the kind a vehicle inspection agency performs; software is not, even though the functioning of entire industries depends on it. While the vehicles in the fleet carry a current inspection sticker, the company's processes run on software that is hopelessly outdated. Because this has been the case for so long, many organizations lack both the awareness and the expertise to address it.

Six barriers and what counters them

All the executives I talk to want a modern foundation. Hardly anyone is prepared to take the decisive step. The reasons repeat from company to company, and there is a remedy for each of them.

The fourth point deserves an addition. A business case that only calculates the build is incomplete. It must cover operation, refactoring, and the eventual replacement across the entire life cycle. Only then does it become visible that the supposedly cheaper option of continuing to build on top of the old system is, in total, the more expensive one.

Renew instead of building on top

In the book I put the consequence in a single sentence (own translation from the German edition):

The path to truly self-driving companies is only possible if these outdated systems are radically modernized.

Radical does not mean reckless. It means putting the core processes on software that reflects the current state of the art and can absorb refactoring for the next 15 to 20 years, instead of stacking further layers on a foundation nobody understands anymore. Software robots, which I classified in the book as a bridging technology, span the transition period but do not replace the rebuild.

The sequence is decisive. In the previous article in this series, I showed how automated software documentation creates transparency about an existing system. That transparency is the prerequisite for deciding what from the legacy base is carried into the future and what is not. Only those who know their legacy system completely can estimate the scope of renewal seriously, plan the stages, and secure day-to-day operations during the rebuild.

Why does this still happen so rarely? Because top management usually lacks the technical knowledge to assess the situation, and because IT departments that have grown around a legacy system for years frequently pursue their own goals. In my experience, almost every case calls for independent advice from people who sell no licenses, have no implementation resources to place, and have a clear idea of what a company can achieve with a modern foundation: an intelligent, learning, and responsive organism as a whole, whose performance is simply out of reach on the legacy base.

I am convinced that the companies that renew their core systems in the coming years will pull away from the rest. Not because new software is a competitive advantage in itself, but because intelligent software can only unfold on a foundation that has not itself become a driver of complexity.

The next step

How technical debt, enterprise architecture, and cognitive software are connected in the self-driving company is described in the book "Das selbstfahrende Unternehmen": About the book. If you are facing the question of whether to keep building on top of your core system or to renew it, we can clarify in a conversation how large the accumulated technical debt actually is and in which stages it can be paid down: Book an expert consultation.