The problems of legacy systems
Many companies do not understand that they actually are “technological companies”. The fact that their “product” (meaning whatever item or service they base their business on) is not directly tied to software development weights so heavily in their mindset that all development efforts are pushed back down in their priority list.
However, the reality of current corporate models makes all financial efforts dependant of the programs they work with. Nowadays we cannot imagine a bank succeeding without strong online support, or a retail company with no e-commerce in place making any profit at all.
Cutting down corners in their infrastructure only limits their possible growth in the future. Startups got it right: software must adapt to the business needs, and not the other way around. But that insight is not something that larger and older companies could afford to put to the test a few years ago. Having an urgent need, investments in systems now obsolete were made, and today they struggle to keep up with the new development paradigms and architecture strategies.
Slowly, those companies are now understanding that it was a mistake. Let’s take a look at what I consider the most pressing issues of legacy systems:
- Reliant on outdated hardware: the first one is pretty obvious. Having a special snowflake in your server cluster or virtualizing a specific setup in order to run your programs is a pretty good indicator that you need to upgrade your software.
- Poor integration capabilities: if including new pieces to your architecture puzzle becomes a struggle, and you must invest more hours to make new programs work together with your already existing ones, than the time you used to make any new software, you’re wasting your team’s effort. Money that could be spent on new features is instead thrown down the drain validating quirks, bugs and unusual behaviours.
- Lost knowledge: due to either bad documentation, lack of knowledge transfer, or both, you’ve lost track of how certain parts of the system work. These applications become some “strange magic” that does work and nobody knows how or why. While this may feel like a lesser issue, you’re building upon a house of cards. It might be a good exercise to take into account what could be done if one day, for whatever reason, this program stops working.
- Frankenstein’s Monster: this is a personal nickname for those heterogeneous systems that rely on different bits, technologies, languages and architectures to solve a single requirement. Two different databases tied to each other, along with a compiled program that exposes an API that a front-end then parses to show data, for example. Spinning up servers to hold these chimeras may not be worth it in the long run, and designing a brand-new application to do the same thing might be cheaper than what you think.
- Bad performance: finally, for some businesses, your application performance can be tied to your profit. Users are whimsical, and dealing with services that do not meet their expectations will have an impact on your image.
If some of these issues, or all of them, apply to your company, change is a necessity. The harsh reality is that the cost to fix your legacy system will only increase with time.
But don’t get depressed by this message: change is always possible. There is talent available that can help through the process of transformation, allowing you to start reducing your technological debt before it becomes too late.
Originally published at Álvaro G. Cachón.