Replacing Legacy. Part 1: Definition, Reasons, Characteristics
This essay combines a public speech I made in 2019 describing BA challenges in a Legacy replacing project and my 2023 speech at the BA Warsaw meetup as a postmortem to that project.
As usual, let’s start with a definition of “Legacy”:
A legacy system is an old method, technology, computer system, or application program, “of, relating to, or being a previous or outdated computer system,” yet still in use.
Our understanding of Legacy depends on what we consider “old” and “outdated.” From some perspective, a service you deployed last week to production might already be the Legacy.
Sorts of Legacy systems surround us. You can co-exist with a legacy by integrating it into your environment. Or you can replace it with a new system (which ironically will become the Legacy soon).
In this and the following article, we will define what the Legacy-replacing project implies for a Business Analyst and other participants.
Why do we need to replace a Legacy system?
There are multiple reasons for replacing the Legacy:
The system must be more scalable to meet current business needs
We are living in a dynamic business environment, so software and hardware pursue the evolution to adapt or predict the needs. There is a limited capacity for change in an existing system. There will be a dilemma at some point: keep updating by sacrificing some new opportunities or proceed with the replacement.
Security concerns
Old software will likely contain exploits that can be potentially used for malicious purposes. The protocols, libraries, and frameworks used in such systems may be outdated and no longer supported by their creators. So security becomes a concern for the Legacy system.
Difficulty in hiring people
The popularity of some technologies can fade away. People who know it may not be willing to continue working with it and are ready to switch to a newer tech stack. A new generation is not eager to learn the “old stuff.” The older generation might be already retired. Replacing the Legacy with a more recent tech stack is also an attempt to match the current and possibly future hiring trends.
License change
A maintainer of technology used for a Legacy system may change the terms and conditions of usage. That may increase usage costs and trigger replacing the Legacy with different “cheaper” technology.
Recent examples are Oracle’s changes in licensing for Java and Akka’s change to BSL.
There is a budget to spend and a manager’s career to promote
That may sound ridiculous, but it is true. Having ambitions and some resources may trigger replacing an existing system with its newer version. And it is good if such a replacement is justified from the business perspective. Otherwise, that might cause only additional troubles.
What are common traits of Legacy projects?
If you join a project that aims to replace an operational Legacy system, you are likely to observe one or many items in various combinations:
Outdated or absent documentation
Documentation is the most overlooked piece in software development. The “let’s-document-it-later” (never) approach in the long term becomes a significant concern. You need to understand the AS-IS of a system to proceed with a desired TO-BE.
Absent documentation is much better than outdated and incorrect docs. In the first case, you know what you don’t know, which gives you an understanding of where to look. In the latter, you need to figure out where you are wrong. And that is more dangerous.
An operating system is the source of truth
You can’t rely on the docs. But relying on people is not an option either. It is an advantage to reach some people who have been working with the system for many years. But it would be best if you were cautious, as they might have their perspective on how things work. And that does not always coincide with reality.
So the operating system can be the source of truth. A BA can study how it operates under different conditions even though it is a black box. You need a lot of time, patience, and probably Postman.
Another hint is to read a source code. It is uncommon for a BA to understand what is written there. But if you can understand how particular classes and methods work, that will make your life much easier.
The source code is missing
It is the worst-case scenario. The possibility that an organization can lose a source code of their service sounds ridiculous. But such cases happen in reality.
You are not the first BA on a project
And likely not the last one. There might be generations of Business Analysts who worked on maintaining a Legacy system or replacing it. If those persons are still reachable within your organization, it is an excellent opportunity to learn from their experience. Or start regretting that you are assigned to this project.
No trust in previous requirements
I learned the hard way that if some requirements were written but not implemented some time ago, they are the subject of comprehensive revision.
If you have inherited the backlog from a previous BA and it is already more than 1–3 months old, then you’d better revisit them. Requirements are not like wine. They usually turn to shit pretty quickly.
Unmotivated team
Developers do not like to work with legacy technologies. That can give some level of stability. But that may end up with losing a cost on the hiring market. But there are some exceptions, like COBOL developers.
Older developers are dreaming more about retirement. Younger ones are dreaming about trending tech stacks. And they can have the motivation to replace the Legacy. But do they possess enough patience and competence to do that — that is the question.
Building something from scratch is always easier than dealing with a tricky spaghetti code, sometimes not covered with any tests. And if there is poor team management, the atmosphere on such a project might not be very healthy for an ambitious BA.
One more important thing
“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
A legacy is a blueprint to reflect many years of an organization’s communication structure’s development (or degradation). It is a corporate archeology when trying to reach an ever-missed context.
Do we need to replicate those layers and bring them to the future? That we discuss the next time.
