Modernization: Why is it important?

Modernizing an existing codebase—or often a portfolio of them—is a complex technical endeavor. In the enterprise environment, there are challenges beyond the technical that can hinder or halt modernization.

Over decades of running technology at scale, enterprises have formed unique footprints of culture, politics and protective security practices that influence all technical outcomes. In order to effect lasting change, it’s essential to simultaneously address technical problems while being mindful of these unique footprints.

This is the first of a planned series of articles that outlines the unique challenges of modernizing existing software in enterprises and details a strategy that is inclusive of key aspects of the enterprise culture, while providing approaches to changing existing applications that open the door to future innovations.

Modernization: why is it important?

Software must change to evolve

Even before 2011, when Marc Andreessen famously said “Software is eating the world,” businesses were under pressure to modernize outdated systems and code. Although reasons for modernization varied (e.g., migrating certain workloads to run on cheaper platforms), Andreessen’s article crystallized a different and more pressing concern for enterprises running software—the threat that some upstart software bogeyman could eat their lunch was very real. 

Since that article, there has been a concerted push in many enterprises to get better at providing software solutions for clients. For the most part, there has been a lot of success in this regard. But with this success has come an immutable truth: Software must be changeable in order to thrive and survive. 

The challenge, especially when modifying existing software, is making that change without affecting the outcomes the software is providing.

In this series of articles, we look at the modernization of an application with the goal of moving the code or configuration into a state that is easier to change.

What is modernization?

All applications have a current state. This includes the code, but also its configuration, runtime and any services it integrates with.

Here modernization means taking an existing code base and changing its current state to a future state that provides value to the enterprise. The motivation for modernization will come from some problem with the current state, and the true value of the modernization is realized throughout the journey to the future state. 

A critical question that is sometimes overlooked is, benefits aside, can the enterprise operate this future state over time? I will spend a lot of time discussing how this can be assessed and proposing some potential strategies should there be doubt about operating the application in its future state.

Current state knowledge

Before you can decide to modernize, it is essential to have the fullest possible knowledge about the current state so that the benefits and scope of any modernization project can be properly defined.

In a large enterprise, current state knowledge might not be readily available. Sometimes this is because the people who made the application are no longer in communication with the enterprise. It is also possible that there is a lack of communication across silos. Maybe the team tasked with modernization is new to the enterprise and just doesn’t know the right people to talk to.

Nevertheless, the critical pieces of this current state need to be determined in order for any modernization project to be successful. This includes the critical step of how the current state can be tested (which might be manually).

This does not mean the team tasked with modernization should master some outdated technology that the enterprise is looking to move away from. Rather, it means that the team should fully understand how the enterprise uses this outdated technology so it can appropriately plan to migrate away from it.

Future state knowledge

When deciding whether or not modernization is appropriate, it’s important to come to understand the desired future state and its advantages.

Examples of a potential future state might be:

• new coding frameworks or dependencies in the code base,

• changes to how the code or runtime is configured,

• a new runtime that is very different from the old one, or

• addition of dramatically new end-user capabilities through code change.

Depending on the organization’s needs, modernization might include elements of all of these. Many enterprises are currently taking a modernization approach that combines two of these (configuration and runtime) as they move applications into a container runtime. This approach, and the addition of a container management platform (e.g. Kubernetes platforms or services like Azure Kubernetes Service, Red Hat OpenShift, Google Cloud Run/Anthos, Amazon Elastic Container Service) can add many benefits worthy of the modernization effort.

If aspects of the future state are new to the enterprise, outside assistance can be brought in provided these resources are willing to educate team members about this space and have experience getting this technology into production in other enterprises (huge bonus points if it's the same enterprise the project is executing in).

Making the decision to modernize

So, you’ve reviewed the current state and weighed up the benefits of modernizing to the future state. Modernization seems like a good idea. So you just go ahead and do it, right? 

As anyone working in an enterprise environment knows, that’s just not how things work. In the next part of this series, I will discuss the challenges that surround existing/legacy software that might make a modernization effort challenging. Some of these challenges might actually be the reason for the current state you wish to move away from. It is important to understand these factors before getting too far down the modernization road.