Indiana Jones had it easy. Most of the artifacts he encountered were tangible. An exploration of ancient applications is like software archaeology, complete with phantoms, dark spells, and riddles. Ah, the joy of legacy modernization.
What is Legacy Anyway?
One of the fun facts of digital transformation is that organizations depend on existing applications for their would-be shiny digital assets. It’s not like starting a new digital business from scratch. Sometimes, these existing applications are considered legacy.
Everyone seems to define the term legacy system differently. Some mean anything that runs on a mainframe or is written in COBOL. Others consider whether programming skills are widely available. Still others point to anything that smells old. I once worked on a project to determine the legacy status of thousands of applications, and we adopted a working definition that was based on the support status of the technical underpinnings.
I’d like to propose a simpler definition:
Legacy systems are applications that have become a roadblock for realizing the business’ digital goals.
Legacy systems are legacy because they cannot readily be adapted to the digital needs. Regardless of the age, technology or the amount that has been invested in it. If an application is adaptable, then it isn’t legacy. Of course, this implies not just a technical angle, but an economic one. If it is too costly to adapt the app, then it isn’t really adaptable.
Archaeology Expedition
Most legacy systems are systems of record that the business runs on. Often, the organization invested a sizeable amount of resources in it. So it’s hard to let go. Therefore, a frequent question is: “can we modernize the application in some way?” The answer requires an archaeology expedition into the software. Put on that Indiana Jones hat, it’s going to be a wild ride.
Just like technology in the old world, the architecture of legacy software can be brilliant. When originally conceived, the designs may have been elegant, well documented and clean. One of my favorite examples of historic tech is the oldest working planetarium, built by Eise Eisinga in the late 1700s. Handcrafted wooden gears, powered by the gravity of weights. It still runs and is accurate.
Your organization’s legacy system may have started out just as beautifully. But then, new requirements resulted in change. New business rules required tweaks. New regulation meant new compliance code. Shortcuts were made. Documentation bit the dust. Layers were built on layers. Someone entered a code comment “I don’t know what this does, but without it, the program breaks”. Then someone else found a workaround for the workaround with creative plumbing. Pretty soon, you have undecipherable layers of hieroglyphs. It can be very difficult and high-risk to make any further changes.
When Eise built his planetarium, Pluto had not yet been discovered. Let’s imagine that he added Pluto, and for kicks, the asteroids of the Kuiper belt too. Now, scale from the solar system to the Miky Way and toss in some black holes for good measure. Just add more gears and weights? That’s what many legacy systems look like.
When to nuke it from orbit
Some legacy modernization firms and tool vendors promote a silver bullet: refactor the legacy code into a more modern programming language. A common path is COBOL to Java or C#, through a combination of automated conversion and manual effort.
I’m not a fan of this approach. Usually, the problem isn’t the programing language, it’s the accumulation of layers of business logic that nobody understands anymore. If something is magic in one programming language, then it is magic in another one too. Conversion doesn’t answer the question why the code does what it does, or why it fails if you change it. Often, a legacy modernization by code conversion requires a major rewrite later.
In many cases, it’s a better option to re-imagine the application from a fresh perspective. Preferably, replace it with a SaaS solution, unless it reflects a highly differentiating capability and requires a unique custom solution.
API-centricity
Modern solutions must integrate with internal and partner applications that contribute to the digital business. The mechanism uses application programming interfaces (APIs). These are like a drive-through ordering window: you drive up to it, mumble your order from the menu and receive a bag of food quickly. Sometimes it is even what you ordered: a JSON burger and the REST.
In some cases, it may be possible to build a set of modern APIs around a legacy system so it can interoperate in an API-centric world. But that means the application is adaptable, and not legacy, assuming it does whatever else it needs to do in a sustainable way.
Takeaway
In the software domain, legacy is not a warm fuzzies term. Applications are legacy when they have become an obstacle to realize the business’ digital goals. It takes a software archaeological expedition to determine if an application is adaptable, and it’s not for the faint of heart. Often, the organic growth of code and cobwebs make the application very difficult to understand and very risky to change.
Automated conversion approaches don’t necessarily address the core adaptability issues. They can be a stop-gap that still requires major rework later. In many cases, it’s more fruitful to re-imagine the application in the new digital landscape.
If you really want to hang on to that legacy code, you can always display it as an ancient artifact.
Ernst Rampen ©2018
