The problem of legacy systems — the ABC of technological debt
‘Legacy systems’ —this name perfectly reflects both their obsolete and problematic nature. These applications and software are sth inherited and relatively old, and because of it, also have stagnated as a result of stillness - no updates, no bug fixes and no changes. What's worse, the more time passes, the more problems they cause. The incurred technological debt is being racked up.
Legacy systems = heritage that nobody wants
Apparently, almost every company that has been operating on the market for at least 4-5 years, has some legacy system. It is based on outdated technologies and what is worse, it is also a key system for its business.
When it appeared in the company, it seemed to be the best possible solution - the company was just starting up, and the software supplier recommended a stable, central monolithic system, in which you did not need to worry about separating individual functions or services. Nobody even knew what the company would be doing in the following decade and what its needs would be.
However, time has passed. The company was developing. Its surroundings were changing. So did the technological standards. And so, at one point, a system that used to be versatile became bad for everything.
Even worse, the more time passed, the more problems it started to cause. Each subsequent problem was ‘patched up’, usually ad hoc, because deep changes would devour a sea of time and money. This is what the story about legacy systems looks like in practice - a story that repeats itself in a surprisingly high number of companies all over the world.
The most common problems generated by legacy systems that companies are currently facing are:
- difficult, long-term changes to the system that only increase the technological debt instead of helping - legacy systems are by their very nature not flexible, which means that even such a trivial thing as e.g. a change in the format of a given accounting document forced by new regulations grows into a large (and very expensive) project. Once built, the existing monolith lasts in its unchanged form for years while everything around changes (among others regulations, legal requirements, additional applications). All this creates a gigantic, internal pain - instead of fighting for new, better areas, we constantly fight to stay afloat,
- the unavailability of data from the legacy system for integration with other newer systems that would increase the company's competitiveness on the market. Data stored in outdated systems are characterized by a lack of standardization - they cannot be simply "sent" to another application or software. First, data need to be extracted, processed and cleaned, and this is not likely to be done by our system provider or our internal IT department for one simple reason: they often lack the necessary experience and skills to work with data. Therefore, the company has important data, but practically does not use this data or uses it in a difficult, manual way, causing fever in every employee. The chance to develop more products based on this data is close to zero,
- high failure rate of the system, and thus high, constant costs of its maintenance - as the system has some years, something goes wrong in it every now and then. Due to the fact that most existing systems are in the form of monolithic systems, consisting of millions of lines of code, even the smallest failure is associated with many hours of searching for the source of the problem. As a result, a large part of the company's IT budget goes not for investments in modernization, but for patching regularly appearing holes in the current system. The statement "the system has fallen again" becomes everyday life of the company and ceases to surprise anyone,
- hanging like a shadow overhead, the fear that the day will come when the system will crash so much that the company's losses will run into millions - user data leakage or production lines stopping not known for how long, this is chaos and paralysis of the enterprise's work. How much such a stagnation costs is well known to every business owner or board member. People from management don't enjoy forced free time and don't make coffee quietly, like regular employees, when the system is down,
- become dependent on the services of one solution provider - due to the fact that the system was written in archaic technologies and usually lacks current technical documentation, which would also include "newly added" applications and interfaces, replacing the supplier with a new one is a miracle. And when someone has a kind of "monopoly" on the system, then he can dictate higher and higher prices of repairs and changes. As a result, many companies decide to stop updating the existing system at some point, which over time raises further problems,
- no employees who "remember how it was done" - as long as someone still works in the company, who was at the time when the monolith was created, knows the system for years and is able to find a given line of code from memory, maintenance of the legacy system still works. However, when this person leaves - and now we do not live in times when employees spend their entire lives in one company - everything begins to fall irreversibly,
- frequent security holes that are difficult to remove - all systems should be kept up-to-date to cope with the latest threats. And as we mentioned above, legacy systems are resistant to changes. Due to outdated technologies, frameworks and solutions used in them, removing some security holes usually turns out to be a challenge and takes a lot of time, creating a potential threat to the company.
The legacy problem and the problem of technological debt
For the above reasons when one talks about legacy systems, one often talks about the technological debt incurred by the company.
The term 'technological debt' is a term strictly derived from the IT industry and means 'no project'. In other words, the company consciously (or not, because it also happens) decides to skip any update, analysis or design stage, take shortcuts and tries to make savings, thus taking a kind of technological loan.
In terms of software architecture, such a debt is, for example, patching a defect quickly or adding something to the system, which was not originally foreseen in the architecture of the whole. So this is not actually done as it should.
In theory, such a loan is temporarily taken, for example, to allocate more funds from the budget to another area or because at the moment the company cannot afford such expenditure or there is no time to implement the best possible solution.
In practice, as with any loan, in the case of technology loans, interest increases and the debt is created. Badly made corrections and functions of the system (or lack thereof) accumulate, leading to the moment when the system really barely breathes. Finally, all these unpatched updates or the choice of a worse solution will have to be paid back someday probably in leaps and bounds to catch up with others on the market. I will be a fat sum necessary for a large investment. An amount that most managers would like to never hear of because everyone is constantly feeling the pressure to reduce costs rather than generate them.
The problem of legacy systems and the constant pursuit of being up to date is well illustrated by the current situation of the financial sector: quick transfers and contactless payments appeared in Poland earlier than in the West, because Poland did not have such huge legacy systems as other countries. Poland had neither checks nor technologically advanced banking. It didn't have to suddenly adapt to the new requirements of reality. Now, however, Poland is constantly chasing Africa, which has become the leader of mobile banking. This continent has overrun Europe, just like Poland used to do, because at the time of the popularization of smartphones, they did not have such a huge skeleton in the closet as the rest of the players.
Why don't companies just replace legacy systems with new ones?
In the context of what we have written above, the only right solution seems to be to actively address the problem: choose code refactoring or comprehensive replacement of the system with a new one by gradually separating it piece by piece which will work independently and which can be connected later (and with external software applications that the company currently has no access to) as a microservice network.
When we write about it, it seems easy. In reality, however, it is not.
As a reminder, the legacy system is often the main core of the company - the central ERP, which is still currently used by the finance, purchasing, sales and, for example, logistics departments. It cannot be simply cut and replaced with a new one in one day. Many people feel just overwhelmed by such a large challenge and prefer to focus on patching smaller holes.
Absolutely everyone knows that the current legacy system generates a lot of problems, is inefficient, unsuited to current realities and will eventually fall by itself, making a right mess. Few, however, want to step out and risk their own careers, saying ‘I have such an idea...’.
Why? Because the process of change will definitely be:
- expensive (as we wrote above, nowadays there is a trend to cut costs, not to generate them, even if it can be easily shown in Excel tables that a larger investment will return in 2 years and will be more profitable in the long run),
- long (half a year, one year, two years - it all depends on the change strategy, the size of the existing system and its complexity),
- not easy (requiring additional work from the manager and his team). Of course, a specialized software company that will take up the challenge, will take on all technological problems and will advise on how to improve the flow of processes with such and such architecture, but at the beginning it will also need to map these internal processes with the client. What, how and who it serves in the company it is know-how that no one from outside has.
And most importantly, if the planned work does not go as smoothly as it was assumed, then there is a possibility that not the one who ‘hides the skeleton in the closet’ will loose his job, but the one who decided to pull the skeleton out of the closet! Sadly, you would be surprised how many companies are still not mature and wise enough to reward innovators, not comfortable lazy people! It is only the development of an organizational culture that focuses on long-term thinking that allows the company to develop effectively.
The legacy problem is not a problem of technology itself, lack of money for digital transformation or the fact that the company will have to adapt to change. These things really can be done if the company wants it. The legacy problem is mainly a problem of responsibility and sweeping uncomfortable issues under the rug. ‘I will not be the one who risks, since so many before me did not ...’ - that's what many managers think.
The effect? The management are changing, but the problem remains.
You might also like:
