44% percent of CIOs say that legacy technology is holding them back from a full digital transformation. We get it—a complex code base that’s been in use for years will have a lot of dependencies, and it’s tough to even get a handle on what needs to change. But failing to modernize simply isn’t tenable.
Modern technology evolves at an exponential rate. This means that identifying the code repositories that are most in need of an update is mission critical, but this is often easier said than done. Sure, the best way to avoid the challenges that come with outdated code and legacy systems is to avoid letting them get that way in the first place, but every day you ignore your antiquated systems brings you a day closer to becoming like the IRS: an operation that’s has been dependent on the same pieces of code for more than 60 years.
What Defines Legacy Code?
First things first, let’s take a second to define what we mean by legacy code or legacy systems, i.e. those parts of your IT infrastructure that require modernization. According to Gartner, a legacy system, “may be based on outdated technologies, but is critical to day-to-day operations. Replacing legacy applications and systems with systems based on new and different technologies is one of the information systems (IS) professional’s most significant challenges. As enterprises upgrade or change their technologies, they must ensure compatibility with old systems and data formats that are still in use.” This is a good start, but we’d add a couple of elements to the definition:
- Legacy code is often characterized by significant technical debt, meaning that it hasn’t been receiving proper care for some meaningful period of time.
- It’s often written or architected in a way that no longer adheres to best practices—this presents ongoing risks both in the sense that it precludes any of the benefits that might define those new best practices and insofar as the pool of engineers with the technical know-how to work on the system is constantly shrinking.
Like we said, any systems that resemble this description are, by definition, in need of modernization. Why? Because as we’ll discuss below, they have the potential to hold your company back from further growth. Of course, these issues will vary significantly from business to business: Company A might find that its sales system is becoming overloaded and slowing down as business increases, but their larger IT environment is running smoothly, while Company B could be in a situation where their largest applications are built on old, inflexible code bases that will require extensive refactoring or re-platforming. Both companies have some need for modernization—the trick is to modernize proactively enough that you don’t become Company B.
Why Is Legacy Code Such an Obstacle to Digital Transformation?
Like we said above, the biggest issue with legacy code is that it prevents you from attaining your other business goals, whether that’s a full digital transformation or simply the ability to maintain day-to-day operations without outages or other headaches. But why exactly do older systems and older code present such serious issues for businesses? For starters, they eat up resources in a way that newer and better integrated systems simply don’t. Businesses around the globe spend more than $3 trillion per year on IT, a shocking proportion of which is just aimed at keeping everything up and running. If every small, necessary update or refactor to a particular system requires an engineer to wade into a complex tangle of inscrutable function calls and obscure syntax, you’re going to spend much more time and money on the system than you want to—meaning you may not have the resources left over for the rest of your IT agenda.
These systems also won’t necessarily play nicely with others. That means that if your shiny new cloud-based sales software needs to gather data from your legacy inventory system, you may be out of luck. Or, you may have to patch together a janky stopgap that slows down the entire order fulfillment process. In the moment, you might feel like you don't have the budget to do any more than that—but in point of fact the existence of these legacy systems will keep eating up budget space until you modernize them.
All this is before we’ve even talked about scalability. Again, let’s picture a company that’s struggling to keep pace with an increasing volume of orders: as their servers get overloaded, they might start experiencing delayed order fulfillment—with some orders falling through the cracks and going unfulfilled entirely—all because the system responds to the increased volume by slowing down and frequently crashing. To be blunt, this is a disaster from a business growth perspective.
First Steps for Modernizing Your Code Base
Long story short: keeping legacy code around is risky, and when you identify it in your operation you really need to work to modernize it. How do you actually go about doing that? There are two main areas that you might focus on:
Modernizing Data Structures: Today, most applications adhere to the same or similar enterprise data models across the board. This means that lighter, more modern systems are more easily integrated with other applications and functions when it comes to data sharing and analysis. With older systems (say, pre-2000) this isn’t true: instead, your data structures are specific to the application itself, and potentially lacking in the normalization that you might expect from a modern enterprise database.
Modernizing Architecture: Modern architecture tends to feature modular, distributed systems that can run on server clusters or in the cloud with relative ease. Older architectures, by contrast, might be built to run on large, individual servers—acting as functional monoliths that don’t allow for modern refactoring and integration cycles. Systems that are architected in this way tend to be less stable, since there’s no redundancies built in for computing power.
Each of these projects will present their own unique challenges and hurdles, but the basic steps for modernization will essentially be the same.
- Identify your top priorities for modernization: this might include legacy code that’s slowing down important day-to-day work, or it might be strategically chosen applications that pertain to a larger operational goal (e.g. digital transformation).
- Map out the code’s functions: What do you use the legacy system or application to do? Who relies on it for what actions, and under what circumstances? What other functions depend on it in some way?
- Map out everything else: Network configurations, server configurations, storage, integrations, etc. Try to deconstruct the code on as granular a level as possible and document that deconstruction in a way that makes it easy for engineers to come in and immediately understand. This will be a huge help in future iterations as you try to make the modernized version of the application more modular.
- Develop a clear roadmap for the future: Frankly, you could do this as step 1, but from our perspective there’s some value to figuring out exactly what you’re working with before you decide what you want future iterations to look like. Either way, this is the moment to ask yourself what operational problems you’re hoping to solve with the modernization. These problems can be current or future, narrowly related to the code’s functions or attached to your digital transformation more broadly, backend of UI-related—whatever’s going to be most impactful for you.
- Divide up the labor: Once you know what you’re looking at, and what it should look like when it’s fully modernized, you can break up the cache of code into modular sections that can be worked on in parallel. This gives you the chance to leverage resources in a more efficient way, speed things up, and merge new code more effectively.
Once you’ve taken care of steps 1 through 5, you’re ready to set your engineers to work. If this all sounds like a daunting proposition—don’t worry, there are a ton of resources out there that you can rely on for help and guidance as you undertake the modernization.
Potential Hurdles in Modernization
There’s a good chance that looking at the first few steps above you can already imagine the things that can go wrong: For one thing, if you choose to redo an entire application at once, you’ll have to face the question of how you’ll conduct business in the interim (for this reason, we tend to advise against that kind of approach). If you’re refactoring in smaller increments (a much safer strategy overall), you can still run into issues with tool fatigue for your engineers, unforeseen compatibility issues, and even some potential service outages. If the rest of your IT infrastructure has a fair amount of built in resilience, these might only be small hiccups. If you’ve waited a while to modernize, these hiccups could turn into something larger.
And, of course, modernizing your code isn’t a “one-and-done” process. On the contrary: this is the type of thing that businesses need to devote resources to on an ongoing basis, or they risk running into new versions of the same old problems within a year or two. For gigantic enterprise corporations with built in redundancies and robust planning systems, this might not be too difficult of an obstacle—but for slightly smaller and leaner businesses, it never hurts to reach out for help.
Learn More About About Intertec's Infrastructure Management:
Intertec offers a wide spectrum of options in infrastructure management. We perform end-to-end outsourcing of specific infrastructure functions and develop strategies to construct and integrate technology architecture. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
