Whether your organization purchases applications commercially off-the-shelf (COTS), develops custom application for both internal or external users, or wants to move to a software as a service (SaaS) model, there are several options at your disposal.
Modernization is a process that can lead you down many paths—there isn’t one correct way to execute this journey. But often the perceived cost of modernization puts pressure on an organization to make decisions that aren’t optimized.
10 Ways to Optimize Your Application Modernization Strategy
Don’t let cost impede your application modernization strategy. Here are 10 ways to reduce costs and optimize your modernization journey.
1. Know your metrics
To modernize an application effectively, you need to know your utilization metrics in order to make the most optimized decisions.
For example, ask yourself: “How many features do I use in my current email platform?” Do you use 50% of the features? 25%? 10%?
On average, most applications have just a handful of features that are used daily. And, if you have custom developed applications, you’ll want to know what parts of the applications are actually used. And, conversely, what parts of the application aren’t used. Believe it or not, the industry average for unused features of a custom-built application is 45%.
2. Prepare your internal skill sets
Identify which languages and tooling you will need for application modernization and then prepare your teams.
Your ability to execute on modernization plans could be crippled if you don’t have the right staff to support both the modernization process and the follow-on day-to-day operations (including bug fixes, deployments, upgrades, patching, and so on).
Keep your development and operations teams involved in every part of the process. Without cross-functionality (think non-siloed IT staff), you won’t get the quick feedback you need from your internal teams to adjust to internal concerns raised by these teams.
You either align with your internal teams’ skills, or you delay your modernization until your teams are trained on the projected modernization platform and tooling.
3. Be thoughtful about your modernization options
Not every application needs to be containerized. Likewise, not every application needs to be a SaaS solution. In most cases, you’re going to have a combination of cloud migration, application rewrites, containerizing monoliths, or even decomposing monoliths. Sometimes, you don’t want to decompose a monolith. Instead, it makes better financial sense to containerize the monolith to achieve the scalability objectives desired.
Each application or workload is different, and great care should be taken to not “over engineer” the modernization process. After all, we’re trying to maximize ROI and get a quicker payback.
4. Know your data
Simply containerizing an application will change the characteristics of how that application talks to your database(s). Since most containers are supposed to be stateless, you’re going to see a number of different connections to your database from a variety of different containers.
Secondly, if you are modernizing your database or re-platforming it, you’ll need to build a strategy around migrating your data and understanding the read/write characteristics of the applications. Is your data normalized? Does your application perform more reads than writes? Should I use magnetic disk or SSD? All these questions should be addressed before modernizing.
5. Consider modernizing existing application features first (before a COTS replacement)
Is the reason you’re modernizing due to a lack of features? Document the current list of features and determine the cost of adding new features to the existing application.
If after completing these steps you find it’s not reasonable to add these new features, select an appropriate COTS replacement. Keep in mind, with a COTS replacement, there is an added cost of training your staff to understand and support the replacement tooling. It’s much cheaper to add a new feature to an existing application than to replace an application, simply due to the cost of training and lost labor.
6. Don’t just decompose
If you’re looking to decompose your applications, simply decomposing is not enough. Your applications may not need the scalability of containerization, but the cost of maintaining the operational aspects of microservices on your operations teams will not change much.
How do you know if an IT organization is good? Do you advertise to your customer that you have maintenance windows? Can you independently deploy changes to your applications without noticing any downtime?
Kubernetes-based architectures allow for higher levels of stability by automatically managing the day-to-day operations of managing servers. You simply abstract away the day-to-day operations to focus on more and more automation to continually automate away your issues.
7. Abstract and automate away
Modernization is more than just modernizing applications, it’s also about automation.
Anytime we have a manual process you must understand it, prioritize it, abstract it, and then automate it.
What does abstract mean in this context? Your organization should be in the business of creating reusable IT assets. Whether that’s infrastructure as code (IaC), programmatic RESTful APIs, or even security automation.
You should continue to refine these processes over time. It’s like disruptive innovation. Disruptive innovation is a process, it’s not a singular point in time. You continually drive up the market, capturing more and more market share until you arrive at the current level of maturity in the market.
The “abstract and automate away” principle is similar. Your goal is to reduce the boring and mundane so that you can spend your time building out more capabilities until you disrupt your competitors.
8. Containerization is table stakes
If your vendors or internal teams are not progressing toward containerization, you’re falling behind in the market. And, your organization’s ability to containerize existing workloads will determine how high your modernization ROI is.
New tools are coming onto the market that apply artificial intelligence to modernization to dramatically reduce the process of containerizing your workloads by segmenting your applications into artifact groupings that, in turn, can be containerized. What takes 18 months to containerize applications can now take a matter of weeks.
9. Application retirement is mandatory
Who wants to constantly maintain an application that’s never used? It’s a waste of resources, using memory, disk space, and operations time.
As stated in rule number one: Know your metrics. Take the time to understand which applications are not used and decommission them.
Deploy tooling to analyze and select candidates for decommissioning. Remember, in most cases organizations tend to over-engineer. They’re driven by their customers and those customers are continually changing.
10. DevOps is table stakes
Most organizations deploy applications to an environment. This is changing. While the current application deployment model may be around for a while, a newer, more declarative model is taking hold.
Modernization tooling should be used to allow for applications to be assessed, modernized, and deployed using declarative constructs. Instead of deploying a workload to a cluster, you’re telling the cluster what the “goal” is, and it will maintain that state until it’s changed.
For example: you define a configuration that defines the state of the application. It’s memory, replicas, image, and several other options are set as the “goal” that the cluster will maintain.
If a container is failing or runs out of memory, the cluster will automatically restart the container without missing a beat. This frees up your operations teams and in turn saves time.
DevOps and DevSecOps are changing and the capabilities in a DevOps pipeline continue to increase. Gone are the days when you just deploy an application automatically. Now we can build, unit test, integration test, QA test (with screen captures), stress test, security test, promote and declare workloads much faster than we could just 10 years ago.
Get Max ROI from Your Legacy Applications
Optimizing your application modernization strategy can help you get max return on investment from existing apps without spending much more than you already have. Application modernization makes it possible for you to create innovative solutions faster, migrate to cloud-based technology, unlock new value from legacy investments, and lower development and maintenance costs.
Not sure where to start? Working with a technology partner can accelerate your digital readiness so you can quickly and safely meet changing customer demands.
The first step is taking inventory of your monolithic applications and programming languages. By performing a
modernization assessment, you can get a detailed view of the programming languages and platforms your IT teams use and coordinating options to modernize these applications to reduce future IT costs.
