Back to the future — part 2: providing a technology add-on.
Legacy software stories
Welcome to the long-awaited, second part of our “Back to the future” series. In the previous chapter, we defined what we consider a legacy system. We listed a few key problems and finally, we gave you some general advice on how to proceed with a full rewrite of your system.
Yet, very often a full rewrite is impossible for many reasons. There may be no business case for it, the system may be too complex to comprehend or the estimated effort can be too big.
So, what to do if a full rewrite is mission impossible? Roll up your sleeves and solve some of the real problems that you face with your legacy solutions!
There are many specific problems you may choose to address. Some may be general, like: low run-time performance, slow development or lack of advanced security. Some others may be more detailed, like: getting rid of a specific, outdated framework/library or lowering the maintenance costs of a proprietary application server. The criteria in your case may be very different. Yet, as we learned in many, many projects & organisations — a common pattern is omnipresent.
The biggest problem with your system is lack of people. If you are able to attract the right people to your project, you will be able to solve specific technical or business problems. Unfortunately, here we stumble upon a typical egg-and-chicken problem. Your system is currently old, crappy, slow, and ugly (more or less); and this makes it very hard to attract new people to the team. Many talented and motivated engineers are not willing to work with outdated stuff. And even if they do, the time needed to get them productive and aligned with technologies is long.
Therefore, the first and most crucial part of the journey toward “fixing your legacy” is to prioritise changes that would allow you to open up the architecture and introduce some new, more appealing elements. This would in turn allow you to be more trustworthy on the job market, attract more talents and go forward with further improvements!
To put you in our perspective by giving more specific examples, we need to first make some assumption on the underlying software architecture. Most of the “enterprise softwares” consist of at least three layers: view / presentation, business and persistence / storage layer. Depending on the age of the application, the layers can be implemented in many different technologies, like in the picture below.
Now, the idea is to concentrate your early efforts on improving one of the layers. If it is possible you may consider a full write of a given layer (for ex. new frontend in modern JS framework), but still this may be complex and costly.
More frequently, it may be possible to extend the construction of a given layer, by providing an alternative way of solving typical problems — using modern technology. Referring back to the frontend example, you may create a bridge that would allow you to write new views / windows in modern framework, while the old ones would remain intact.
The approach briefly outlined above can be very helpful. Yet, it is critical to find a balance in its implementation. If you provide too many new elements to too many layers at once, you are very likely to introduce chaos at the level of magnitude which is hard to imagine. Summing up, start small! One window, one button, one component, one service, one small module or business functionality… go ahead, pick it, work with a few proof-of-concepts that would validate your choice and then proceed.
Moreover, these so-called technology add-ons need to ensure beneficial gain/effort balance. For example, if you have a system with Apache Struts frontend and C++ in the backend, you’d probably focus on doing something to the C++ rather than to Struts. Most probably, you’ll gain more!
Recap from the past… A decade ago, we were in a situation like this with an old e-banking system used in afew European countries. Business logic was based on old Solaris systems running Tuxedo with custom logic written in Pro*C++ (mixture of C++ and PL/SQL, ugh!). By designing an alternative business layer implementation, based on (hot back then) EJB3 and JPA technologies from the Java EE tech stack, we were able to introduce dozens of younger developers to the team. This eventually allowed to solve (at leasr partially) thecrucial problem of the platform: low velocity of the development of new functionalities. BTW: the platform created back then is still being used and further extended by the team.
Summary
If you can’t afford a full rewrite and if you are facing with one of the problems with legacy software, you should consider providing a technology add-on to your architecture. Pick a selected layer or module of your system, and provide an alternative and modern way to implement it (or parts of it). Why? Because if you do it smart and brave enough, you’ll be able to attract more people to your team, that would in turn solve other of your problems in the future! People are key here — and people need to be convinced that, indeed, you are going to invest in fixing your legacy problems.
Good luck… and stay tuned for next parts of our “Back to the future” series.
This article has been co-authored by: Łukasz Drzewiecki.
