There are multiple ways to modernize an IT system, ranging from encapsulating a system in API’s to replacing it. Gartner has defined the 7 most-cited options as being the following.
- Encapsulate. To leverage and extend an application’s features and value, encapsulate data and functions in the application and make them available as services via an application programming interface (API). Implementation specifics and knowledge are hidden behind the interface.
- Rehost. Redeploy an application component to another physical, virtual or cloud infrastructure without recompiling, altering the application code, or modifying features and functions.
- Replatform. Migrate an application component to a new runtime platform. Make minimal changes to code to adapt to the new platform, but don’t change the code structure or the features and functions it provides.
- Refactor. Restructure and optimize existing code without changing its external behavior to remove technical debt and to improve the component’s features and structure.
- Rearchitect. Materially alter the application code so you can shift it to a new application architecture and fully exploit new and better capabilities of the application platform.
- Rebuild. Rebuild or rewrite the application component from scratch while preserving its scope and specifications.
- Replace. Eliminate the former application component altogether and replace it, taking new requirements and needs into account.
All these options have their respective up- and downsides and associated costs. As vendors of different solutions sometimes hail the strategy they have chosen as the “cure for all things”, it might be tempting to select just one and go all-in on that. However, we believe that no single one of these strategies is the best approach, but that every case requires a different mix of these strategies. While the options for modernizing are quite well- documented, the question of selecting the best option in any given situation remains.
We have identified several factors that often influence the choice of modernization solution.
Dependencies
- Support
If a system is wholly or partially composed of software licensed from a particular vendor, support by that vendor can play a big part in deciding which modernization strategy to follow. When licenses can no longer be renewed, or support for a solution ends, the possibility of getting new features implemented in said product no longer exists. There is also an increased possibility of critical security vulnerabilities not being resolved. When no other supporting party can be found, replacement will often be the only long-term viable option.
- Hardware
If a system requires certain hardware, there is a risk of the hardware going out of production. When this happens, and parts can no longer be sourced, rehosting and/or replatforming can be options to consider if the software is still meeting requirements. In this case, migrating to cloud infrastructure also deserves consideration. There is also the possibility of hardware limiting interoperability of the software running on it. In this case, the preferred solution really depends on the specific hardware limits.
- Skilled engineers
The skills needed to run and maintain an IT system are often a reflection of the time that system was developed. Over time, the most popular IT skills change, and the pool of engineers capable of working with any technology may decrease. If it does, finding qualified personnel to maintain a system might become difficult and costly, with fewer people carrying an increased responsibility because “no-one else can fix it”.
If a system is running well, and no changes are needed, a lack of qualified engineers is no problem. However, for a system that is often changed, or requires lots of attention, shifting to a more common technology stack can be a way to reduce maintenance cost and increase development agility. Rearchitecting or rebuilding might be suitable solutions in these cases.
- External stakeholders
Interoperability
Interoperability of IT systems is becoming more and more important, as automatic integrations and sharing data with suppliers and customers become more common. A warehousing system not suitable for internet communication for example, might disrupt company plans to automatically restock with vendors if stock gets low. In these cases, where a system by itself might function in a satisfactory way, but its communication abilities are problematic, encapsulation might be a good solution. By, for example, creating a layer of web-accessible API’s around the system, interoperability can be enhanced.
IT department capabilities
One often overlooked factor in determining the best approach to modernization, is the IT department itself. Does IT have the ability to work with a new system? Can they upgrade a legacy system themselves or is outside help needed? If IT has a thorough understanding of the current system, but no experience with a more modern replacement, does the cost of keeping a perhaps sub-optimal legacy system outweigh the cost of retraining IT and hiring new staff?
Upgradeability
Looking towards the future, if new requirements are likely to appear in the future, can the existing system be upgraded to meet them? In modernization, it is important not to look at only the present, but also to consider the future. If a system can be upgraded or expanded to meet current needs, but is then highly unlikely to meet anticipated future requirements, the cost of first upgrading the existing system and then replacing it can be higher than the cost of replacing immediately. While anticipating future requirements is often difficult, and we recommend not to consider unlikely or vague ideas to reduce feature creep, the inability of a system to meet future needs can make (partial) replacement a good option.
Time
Different modernization approaches require different time-paths. If meeting some requirements quickly is very important, modernization options that require the least amount of effort in the short term might be chosen. For instance, a combination of extending and refactoring in the short term to meet deadlines, combined with a rebuild on the long term to allow more expansion of functionality. When speed is essential, replacement will often not be the best choice for the short term, as implementation, training and testing might take too long.
Cost
As with any project, cost is an important factor in deciding what modernization strategy to follow. Sometimes keeping a system running will be prohibitively costly, while other times the added business value of an extensive rebuild can be lower than its cost
As situations between IT landscapes can differ greatly, and the above factors all interconnect, a thorough assessment is the best option to find out what fits best for a particular situation.
