This article is part of a large piece originally published on the Red Hat blog. To read the original in its entirety, click HERE.
Every IT operation in an enterprise requires funding. Generally, business units provide this funding. Much to the dismay of many, the funding is not unlimited — business cases need to be made and presented. Priorities and budgets are set for the year and need to be adhered to. This is why the decision to modernize applications needs to be carefully considered.
The starting point for a business case for modernization is to first determine if the value achieved by modernization will be worth the effort. Let’s look at some common reasons for modernization that can add value.
How do you know if an application is worth the cost of modernization? If an application is not going to remain in service — perhaps it is being replaced and retired — it might not be worth the effort to modernize. Assuming the application is going to remain in service, here are four reasons to fund modernization.
Cost of deprecating technology
The middleware an application runs on (or integrates with) might be too expensive. Also, more commonly, a version of middleware or of a service might hit its end of life. In this case, there might be no choice but to change the applications it is integrated with.
New technology for new functionality
Perhaps there’s a new version of a framework or runtime that can enable developers to provide better functionality. For example, this could be a newer version of a JavaScript framework like React which allows for state management (e.g., Hooks), whereas the existing React version might force developers to bring in third-party dependencies to achieve the same goal. An update like this could simplify how developers code their user interfaces, making it easier or faster for them to create complex UI components.
Flexible code increases value
If an application is going to be around for a while, it will need to evolve over time to stay relevant. If the code is not written in a way that is conducive to change (confusing logic, no test coverage, etc.), refactoring it to make it easier for teams to change the code is a worthwhile modernization goal.
Improving security
Not updating long-running versions of frameworks or libraries can be risky (for example, the recent Log4j issues). Sometimes dependencies that applications use might need to change due to a new threat. The list of companies suffering similar issues, perhaps because they did not upgrade a Java framework to a version with improved security, is long and continues to grow. These are evolving issues that might not be easy to predict — to futureproof your application the code base must be changeable.
