Modernization: Making a business case

In the previous articles we discussed how to assess, from a high level, whether a modernization effort made sense in your enterprise. We also covered the attributes a successful modernization team should have, and some team characteristics that might cause problems. At this point you might be thinking that starting a modernization project is a no-brainer. However, there is still one more bridge you need to cross.

Modernization requires funding

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 too. 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 the modernization will be worth the effort. Let’s look at some common reasons for modernization that can add value.

Modernization drivers

How do you know if an application is worth the cost of modernization? Assuming the application is going to remain in service, below are some reasons to fund 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.

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.

Rewrite or refactor?

If the code and configuration is complex, undocumented or difficult to read, or if those who did the work have left the organization, you may have no choice but to rewrite. This is a decision that needs to be made by those who understand the current state of the application, the motivation to move to a future state and the IT culture of the enterprise the application is running in.

This is why having a team with the correct mix of enterprise knowledge and innovation skills — who are also able to come to an alignment and make decisions — is so important (this was covered in the previous article). Having such a team may prevent the project from going down the wrong path at the very beginning.

Defining value to the business

All of these reasons to modernize need to be connected with the value that modernization will bring in order to make a compelling case for funding. The cost-reduction driver is obvious (e.g., moving off expensive middleware), but there are other ways the value of a modernization driver can be quantified.

Reducing toil

This is a popular phrase with teams building an SRE culture. At the application level, the toil associated with changing a legacy application can sometimes result in the application becoming “stuck.”

For example, I worked with a team who were unable to upgrade due to a requirement for a deprecated version of Microsoft Internet Explorer (IE). They were being blocked by the cost of regression testing the application. The code had become what some might call a “ball of mud” — a monolithic mess of back-end and front-end logic. Any change required a full regression test. A third party firm did regression testing prior to releases at a steep cost.

This modernization effort resulted in a rewrite of some key applications in the portfolio with the following aims:

1. To provide robust test coverage, resulting in a reduced cost in manual testing, and

2. To move specific functionality into a standalone service that could be shared across the application portfolio, again reducing testing costs by reducing duplication.

The reduction in toil when it came to testing resulted in a cheaper IT bill for the business paying for the application.

Corporate strategic alignment

Corporate strategies presented at the investor level are usually aimed at generating more revenue, but the path to this revenue can also be tied to opening up a new market space (e.g., robo-advisor) or adding important features to existing software that make it more reusable and scalable across the enterprises technology portfolio (e.g., exposing key functionality as APIs).

A modernization project that aligns with the initiatives communicated to the shareholders has a good chance of being funded. The closer the alignment, the better the chance it has of being funded. That said, however, the alignment could also be a dotted line.

For example, in the case that involved migrating away from the requirement of a depreciated version of IE, the application was used by internal staff to service customers. The future modernization state not only reduced toil, it allowed the team to improve functionality and operate more reliably at scale. In turn, this allowed their staff to better serve clients coming into their branches, which was a corporate strategic goal of the organization at that time.

Thinking in terms of portfolios of applications

Perhaps modernizing an application provides value, but the value is small when compared with the effort required. If multiple applications exist that can be improved in the same way, a case could be made for making changes across a portfolio of existing applications. I will discuss approaches to evaluating a portfolio of applications later in this series of articles.

Should I ignore low-priority internal applications? 

Not necessarily. Building on the statement above, if an application is internal and cannot be directly aligned with value, it may still be worthy of modernization. Depending on the patterns in the application’s code, this application could be a valuable proving ground for a team to test a future state without affecting a public-facing revenue generating application. I’ll spend another article later in this series discussing how to map migration value across a portfolio of applications.

Achieving alignment

Let’s assume that — following your review of their current and future states — you’ve successfully outlined a series of changes to a portfolio of existing applications that unlock value aligned to the enterprise's own strategic goals for the year. You have made a convincing pitch to your management and received a green light to scope out the project and start putting a team in place.

Now, you need to ensure you deliver. This comes down to aligning the future state of the modernization work to the culture and compliance practices of the enterprise. For alignment, it’s critical that you have enough knowledge about how the enterprise works to get input from the right people at the right time.

In the next article in this series, we’ll talk about building the right team to work on your modernization efforts.