Modernization: Defining the scope of your modernization project

If you have been following the series, we have covered a fair amount up till now. From determining the desired future state of the application(s) and reviewing challenges surrounding legacy code to making a case for funding the future state and creating an effective team to work on a modernization project in an enterprise environment.

The next logical question would be: “When will the project start, and how soon will it get done?”

Before we can proceed, we need to map out the full scope of the modernization project.

Mapping out the current state

As we established previously, the current state is where the applications are presently at in terms of code, configuration and runtime. The goal is to move this state into a new one that, hopefully, provides the value you are trying to achieve.

You are most likely dealing with a portfolio, so there will most likely be multiple characteristics in the current state that you’ll need to understand.

Current state knowledge includes:

• the functionality provided by the application

• the level of test coverage

• general quality of the code

• service level agreements for production

• how it’s deployed and configured

• audit, compliance, and security standards it must adhere to

• how it is currently supported and monitored

Subject matter experts for these aspects of the existing state need to be identified. This might also include individuals familiar with the third-party systems the application integrates with.

Plotting a course to the future state

Plotting a course refers to the changes that you believe should be made to obtain the desired outcome. These might be changes to the code, a total rewrite of the application, or updates to the build/deploy process or runtime.

The details around this future state might be very new to the enterprise in general. As a result, some external resources might be required. This option will heavily depend on the budget of the project. However, it's best to get organized before bringing in extensive external resources. Let’s discuss some strategies for getting an idea about how this work should be addressed.

Reviewing the landscape

A good place to start is to review the portfolio of applications targeted for modernization to start figuring out how to best tackle the work.

Focus on patterns over applications

Silos form in enterprises around technology. These silos can often greatly affect how technology is adopted. There is a concept called Conway’s Law which states that “organizations design systems that mirror their own communication structure.”

For example, when dealing with a difficult or slow silo that owns a required technology, teams might implement a less-than-ideal solution out of desperation when they are unable to get what they need (e.g., teams are unable to get databases without excessive time and frustration, so in-memory caches are used for data persistence instead).

Based on this understanding, there will be some patterns found in applications across the enterprise that are unique to that enterprise as they were potentially created to deal with challenging teams or processes unique to the culture. These patterns might be driving a modernization effort, but teams must be careful to understand how these patterns came to be or risk repeating them.

Building on the previous example, a modernization effort might be to stop using in-memory caches for data persistence across a portfolio of applications. However, after spending time and resources, a team might miss the goal due to the limitations or process the enterprise has put on database usage resulting in the modernization team leaving the in-memory caches in place.

The goal is to pick patterns that can be modernized and that are shared across the portfolio in order to realize more value for your effort.

Getting a lay of the land: Determining priorities

The Wise Sage and Project Lead need to get together and assess the applications that might be candidates for modernization. If they have issues getting access to what they need, The Sponsor can be called on for help.

You will want to look for patterns and what types of applications they occur in to determine where the best bang for your buck will be.

For example, consider a custom security library made by teams within the enterprise that requires a heavyweight application server to perform its logic. In this situation, the modernization value could be to move away from this application server to save on licensing costs. Focusing on lower priority applications that contain this custom library (e.g., applications that can sustain downtime or disruption), to build out the future state solution might be a better place to start than a higher profile application which could result in the team running into escalations when something breaks.

Here is a sample data collection form with some data points that can be obtained for each application in the portfolio. The goal is to obtain a matrix of data to help the team to determine what/where to start the modernization work. Given the Wise Sage and Project Lead might not know everything about these applications, they might need to interview team members involved in the application portfolio. These could be some useful data points to collect.

This list isn’t exhaustive, but it is a good starting point. This data can be obtained by talking to teams and using various code scanning tools. Red Hat provides some open source tools (such as Tackle) that can help with this type of data collection effort.

Analyzing the data to come up with a plan

The next stage is to review all of this data. This review should be driven by the Project Lead with help from the Wise Sage. These two members need to come up with a plan of attack that provides optimum value, including determining:

1. The patterns applicable to the most high-value applications that should be migrated

2. The applications with these target patterns are safest to start with because they:

   1. are not business critical.

   2. have access to the code.

   3. have the best observability.

3. A learning curve associated with this target platform (e.g., starting to put together training related to all the labels associated with the applications)

4. Any external assistance that might be required (e.g., potential knowledge gaps across the enterprise on an application stack or runtime platform associated with the future state)

All of this combined should help get that sign-off for funding the project. In a future post, we will share some technical strategies that might be helpful.