Taming the legacy beast — part 1
In this article series, I intend to address the challenges of working with legacy monolithic systems. This first part will outline some generic strategies to employ going about the challenges:
- Breaking up the monolith
- Introducing modern technologies
- Keep the system working as intended, and even expanding the features, while doing it
Unless you are a huge profitably company or a government organisation, you have no choice continue to work with the existing system.
On the other hand, if you are are, then you could just set up another team or train or set of trains to just build a completely new system in parallell. Even if you could do this, I would advise against it. It will be a huge cost, will take very long time, especially since the requirements on your system will keep changing in the mean time. It could also cause a bad atmosphere and hostility between the teams — I mean, would you be happy in the legacy team, spending your valuable time on developing a system about to die? Also consider the cost progression— to develop a new system during 3 years while requirements are changing, it would be near to impossible knowing the final cost of the system, and a lot of the new features would have to be developed twice.
No, the way to go is to break the huge challenge into manageable , smaller challenges. In this way you will get the following advantages:
- Lower cost
- Happier team members
- Early results
- Consistent behaviour
The only one not happy with this will probably be the new enterprise architect that dreamt of new shiny toys and unlimited budget for years to come :-)
So, how to do it? Lets discuss some strategies.
Component decomposition
Identify functional areas within the monolith with high functional cohesion and high static coupling. If large enough and it could be broken out of the monolith without causing a huge amount of traffic between the remaining monolith and the new component, you found a candidate.
Modular monolith
When the monolith is not already divided into well-defined sub-components/functional areas not entangled with each other (a.k.a spaghetti), start addressing this first. You need the sub-components of the monolith to have clear boundaries to other sub-components before you can even start to think of breaking them out of the monolith by forking.
Forking
Once components have been identified for decomposition, fork the monolith, and start removing all the code not part of the functional area of the new component(s). Now you can start working on the new component in a much more efficient way due to its smaller footprint and focused functionality.
API first
The API first method means that you before restructures the component(s), define new APIs for components to communicate with each other.
Depending how entangled your new thought out components are with each other, it could be wise to do some internal restructuring within the monolith before breaking them apart by forking and starting the API design (see Modular monolith).
When the entanglement is resolved and the forking is done, start defining the API’s and make a mock implementation so that teams can work in parallell with the new components from the start.
Inter-component communication
The new components need to communicate with each other with a method efficient and easy to implement. You need to decide if the communication should be synchronous or asynchronous. For synchronous you have options like REST, GraphQL or gRPC, for asynchronous you can use options like JMS, AMQP, STOMP, SignalR, Kafka. Which ones to prefer in your application is not possible to say without knowing the application, but syncronous methods are probably preferred when a human user is waiting for the response of the action, and asynchronous methods when it is software components communicating with each other.
Strangler pattern for UI replacement
When reworking the UI, you will most likely select a new framework for the new UI, what would otherwise be the point, right? In todays landscape, you will likely select one of Angular, React or Vue, depending on requirements and team experience, for replacing an older ASP, JSP or PHP UI ( or similar ).
You will no be able to replace the entire UI in one go, you need to do it iteratively, letting the old and new technology coexist until the transition is completed. This is called the Strangler Pattern, introduced by Martin Fowler. Of course it can be used for all kinds of technology transitions, not only UI.
I hoped you enjoyed reading this introduction article to the article series about taming the legacy (monolithic) beast and want to continue reading by following me
The next article in the series will introduce a hypothetical software system in bad need of refactoring, and we will continue to follow this system as it progresses into a modern, modular system throughout the series.
Thank you for reading!
