3 Must-Have Modernization Competencies for Application Teams

As digital natives and startups continue to leverage microservices, Kubernetes and cloud platforms like AWS, Azure and Google Cloud Platform, enterprises that are still maintaining and running business-critical monolithic applications face a distinct disadvantage.

Tightly-coupled, interdependent, complex Java EE or .NET applications were never designed to deliver the advantages of cloud-based microservices architecture such as elasticity, scalability, increased engineering velocity and faster release cycles.

In working with software architects around the world across hundreds of monoliths and tens of millions of lines of code, vFunction has identified three must-have competencies for enterprises looking to select, accelerate and execute the right continuous modernization strategy for their monolithic applications.

1. Data-driven assessment: Teams that are struggling to prioritize which applications to modernize and build accurate business cases for those projects require specific data that can guide them through this process.
2. AI-enabled modernization: Application architects who are already struggling with a massive monolith modernization project need new tools that can help automate painful decomposition and iterative refactoring processes.
3. Post-migration refactoring: Migrations that simply lifted and shifted their apps to cloud platforms like AWS, Azure or Google Cloud become quickly disappointed with the lack of cost savings, elasticity and engineering velocity.

Let’s look at these three modernization competencies in more detail.

Modernization Competency #1: Data-Driven Assessment

Organizations with a broad application estate are faced with many monolithic applications across their business environments. Most likely these existing applications have complex class and resource interdependencies across business domains.

Most organizations that are modernizing a broad application estate encounter more questions than answers at this point. Where to start, which application to target first and what’s the return on investment (ROI) are the primary questions. You need to start with actual modernization-focused data collected from your applications.

Without detailed data that can measure technical debt, complexity and risk, most teams suffer from “analysis paralysis,” where precious time is wasted on collecting data irrelevant to actually modernizing the applications. This leaves teams frustrated by the inability to find a clear path forward because they are unable to determine the primary target applications and the related ROI and business cases to support kicking off modernization initiatives.

Questions to ask:

1. Which applications should be targeted first?
2. Which applications should be retired or discarded?
3. Which applications should be rewritten or refactored?

“To start the process, you should select applications for modernization that have high business value and are carrying significant technical debt. Specifically, these applications should be ones that are still very actively developed on the one hand, but that the development process for them is the least effective (new features, release cycle time, etc.) on the other. This is quite a challenge since the visibility into the former is not trivial and measuring the latter is even trickier,” says Ori Saporta, chief architect and co-founder of vFunction, Inc.

Modernization Competency #2: AI-Enabled Modernization

After selecting a monolith to modernize, the next challenge is actually refactoring and re-architecting an application that can easily have over 5 million lines of code and more than 5,000 classes. The dense dependencies and lack of architectural visibility make progress slow and tedious.

One approach is to target the easier, “low-hanging fruit” services first, but unfortunately after that, modernization velocity tends to significantly slow down due to system complexity and the risk of making impactful changes. Without an intelligent platform that can surface hidden business domains and tangled interdependencies to suggest a path forward, these projects most often slow down, stall out or are fully abandoned altogether.

Faced with slow progress and no automated tools to help, teams often experience decreasing morale as the modernization project begins to stall, and a catalyst is needed to help accelerate the velocity of their initiatives and rekindle team energy and focus.

Questions to ask:

1. Which domains currently exist in the monolith but are otherwise hidden?
2. How does making changes to a class affect other system components?
3. How can I selectively refactor one or more critical services and iterate through my monolith?

“When it comes to these huge legacy applications, it is usually very clear to the organization that refactoring is required. The issue then becomes not if, but how to get started. Existing solutions are seriously lacking in providing the necessary insights into the inner workings of the existing codebase. This applies both to how classes are dependent on each other in theory (static analysis) and also how these dependencies come into play during the actual runtime of the application. With this information, they can then proceed to pick specific workloads to extract and test with confidence that they are not “missing” anything,” Saporta says.

Modernization Competency #3: Post-Migration Refactoring

Migrating a monolith to the cloud — often called a “lift-and-shift” migration — should be the beginning of your modernization journey, not the end goal. Whether you simply re-hosted in the cloud or re-platformed your application, migration remorse kicks in when you see rising costs with no increases in development velocity or scalability.

Using the lift-and-shift migration strategy, many organizations have been able to move functionality onto a cloud platform and even containerize their monolith. Parts of the application are now running in the cloud, much to the relief of executive teams with a cloud readiness mandate to achieve.

This rarely solves their core challenges or leads to meeting business objectives — after all, they’ve now just shifted what is still a monolith into the cloud. Lifting and shifting may solve some tactical concerns, such as alignment with DevOps best practices and improved security, but it fails to deliver on the primary benefits of full application modernization for the cloud, like development agility and velocity, quicker release cycles and scalability.

As frustration among system architects, software developers and senior managers on the hook for the cloud migration continues to build, it makes sense to strategically refactor your legacy application’s business logic into decoupled, isolated microservices.

Questions to ask:

1. For which applications was the lift-and-shift strategy adequate or not?
2. Which expected benefits of the cloud are you missing?
3. Where can you begin to leverage the elasticity and native scalability of the cloud to scale out one or more specific services versus the whole monolith?

“You are already in the cloud — awesome step one. And you now have access to hundreds of new cloud services that you, unfortunately, can’t access since you are running a monolith on a simple IaaS image — basically using the cloud provider’s compute capacity versus your own. Leverage the momentum of a successful migration as quickly as possible! As an architect, start with an assessment (see Competency #1) to lay the groundwork and build a data-driven plan. Next, select one or two key services (see Competency #2) that will benefit your business or your architecture by removing from the monolith, perhaps allowing you to scale, add new APIs and share with other applications. So many container-based or serverless services are now at your fingertips and easily accessible to you from your cloud provider. The time to modernize is now!” advises Bob Quillin, chief ecosystem officer at vFunction.

The Path Forward — Migration vs. Modernization

When considering next steps, it’s useful to determine whether your team is able to move forward by migrating or modernizing. The differences here are important to understand:

• Migration strategies, such as lifting-and-shifting, present a more tactical approach that is generally more short-term in nature, similar to patching software without fundamentally changing the code or its architecture.
• Modernization strategies, such as rewriting, refactoring or rearchitecting, take a more long-term approach, requiring code modifications, deep engagement from architects and developers, and executive buy-in for the project plan.

To decide the best path forward, leverage Competency #1. Architects and decision-makers should begin with automated architectural assessment tools to assess the technical debt of their monolithic applications, accurately identify the source of that debt, and measure its negative impact on innovation. These insights will help teams early in the cloud journey to determine the best strategy moving forward.

Using AI-based modernization solutions, architects can exercise Competency #2 and automatically transform complex monolithic applications into microservices — using both deep domain-driven observability via a passive JVM agent and sophisticated static analysis‚ by analyzing flows, classes, usage, memory and resources to detect and unearth critical business domain functions buried within a monolith.

Whether your application is still on-premises or you have already lifted and shifted to the cloud (Competency #3), the world’s most innovative organizations are applying vFunction on their complex “megaliths” (large monoliths) to untangle complex, hidden and dense dependencies for business-critical applications that often total over 10 million lines of code and consist of thousands of classes.

You can try vFunction Assessment Hub for free today or request a demo of the complete vFunction platform for you and your team.