This article is part of a larger piece that was originally featured on the Red Hat Blog. To read the original in its entirety, click HERE.
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.
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 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.
