New and old technologies coexist in legacy system

Question

New technologies can accomplish existing tasks in more efficient and powerful way. But sometimes old technologies cannot be discarded unfortunately, so more numbers of technologies in one system make maintain difficult. Is it worth to introduce new technologies?

For instance, a legacy system uses SOAP internally and JSON is new technology to replace the SOAP. The problem is JSON can only replace some of SOAP, because the rest of SOAP is too complex to replace. As a result, the system will use both SOAP and JSON at same time. The maintain is even more difficult than before.

Is it reasonable to introduce new technologies to replace part of old ones?

Answer 1

1. the problem is there already:

   Personally, I don't consider increased maintenance difficulty to be that relevant in the light of modern projects, which already contain dozens of technology-buzzwords (polyglot programming, databases, what-have-you). At the same time, I would not expect anyone new to the project to be able to perform maintenance easily. They will not get around learning about these technologies anyways.

2. not everyone needs to know it all:

   Now of course, the learning part could be reduced by not introducing yet another technology. However, it's not as bad as it sounds, because large legacy systems (and they are typically large, as they would simply be rewritten otherwise) are usually changed only in this part or that to fix a bug, or add a new feature. And you don't have to understand everything else for doing that either.

3. getting better is a must:

   The point most strongly in favor of adding new technologies is that you simply cannot afford to stay with outdated technologies. If this legacy system is worth anything to your company, then it will most likely not go away in the next 5-10 years. What really makes maintenance extremely hard is to use only old technologies. It's not just that new ones make your life easier, but just imagine you had to maintain this whole system in Assembler. Now also consider that the lead engineer who knows it all may no longer be there (hit by bus, got better offer, whatever the reason) - can you still find people on the market who know this old thing X? Even just looking at today's market, you will find that especially new graduates (who are the easiest and cheapest to hire) will typically have at least some JSON experience, but only very few will have seen SOAP.

   Additionally, the time that new technologies save is just as relevant, because time-to-market is key in most of today's markets. If you stick to old technologies and it simply takes that much more effort, you will need that much longer - which at some point reads as too late. At that point, you will have a legacy system, that you cannot do without, but that you also cannot improve and adapt fast enough - in other words: everything that depends on this system will slowly go down the drain.

4. define a roadmap:

   Finally, it is important to have a sort of roadmap considering your system's technologies and that all team members are fully aware of it. If you decided that JSON replaces your SOAP, but you cannot do it yet, then at least make sure that everyone knows, that new stuff should be done with JSON and not SOAP. That way, depending on the size of features you're adding, you can incrementally replace more and more subsystems that used SOAP up to a point, where you can eventually define an ETA for how long it would take to remove SOAP completely from the system. Depending on the business-criticality of the system, you may also want to assign time solely for progressing on your technological roadmap. You will call it cleaning up the system's dark and dusty tech corners - to managers it will be known as ensuring the system's competitive basis and making it future-proof.

Answer 2

There are many variables that should be considered when deciding to add new technologies to a legacy application.

First, what is the long term plan for this application? Is there a plan with money and a date to retire it? If so, does the new technology being introduced relate to whatever is replacing the old app? If so, great, go ahead. If not, then why are you introducing this technology? Old apps aren't playgrounds -- they're usually serving a critical purpose in an organization (they're often the first apps that were built at a company and consequently are critical to the company's financial health).

Second, what is the learning curve of the new technology? Are your people ready for it? For example, let's say you've got an old application written in COBOL/IMS/CICS. It's rather unlikely that you'll be able to quickly transition the people who are working on that to say HTML5/CSS3/Javascript/JSON/REST/NoSQL in a short period of time. So, what's your workforce strategy? Do you have one? It can't be "they'll learn it as they go". That's irresponsible and likely to result in staff churn.

Third, do you know where this new technology is in its Diffusion of Innovation stage? Probably the WORST thing you can do to a legacy application is burden it by grafting it with a "new" technology that's already at the late majority or laggard stage of adoption. Why? Because two years from now it'll have TWO old dying technologies under its umbrella, so you actually made it worse. Try to restrict your technology introductions to things at the early adopter or early majority stage.

Fourth, how many people are HONESTLY contributing to the health and welfare of the new technology? If you go to GitHub for example, how frequent are commits being made, and how substantial are those commits? Again, don't burden a legacy app with a dying technology just because it's "new to you".

There are probably many other things to consider, but those are some that come to mind based on my years as an architect making those kinds of decisions.

Answer 3

Not only is it reasonable, it is often unavoidable and indeed can be a useful 'foot in the door' to moving off legacy technologies completely. This is of course assuming that there is a cost benefit to moving off old technologies in the first place, which there may not be.