Category: Uncategorized

In today’s fast-evolving technological and marketplace environments, the software applications that companies depend on must be able to quickly adapt to the demands of an ever-changing competitive landscape. But as existing features are modified and new ones added, an app’s codebase inevitably becomes more complex, making it increasingly difficult to understand, maintain, and upgrade. How can developers ensure that their apps remain flexible and adaptable even as changes are incorporated over time? They can do so by applying the principle of continuous refactoring.

As Techopedia notes, the purpose of refactoring is to improve properties such as readability, complexity, maintainability, and extensibility. When these factors are regularly enhanced through continuous refactoring, apps can maintain their utility well into the future.

But, as management guru Peter Drucker famously said, “You can’t improve what you don’t measure.” That’s what architectural observability is all about: ensuring that developers have the ability to see and quantitatively measure the conditions they need to address through the critical process of  continuous refactoring.

Why Modernization Requires Continuous Refactoring

Application modernization can be described as the process of restructuring old apps to eliminate technical debt and seamlessly integrate them into today’s cloud-centric technological ecosystem. Technical debt is typically a major stumbling block in such integrations because it, by definition, involves “sub-optimal design or implementation solutions that yield a benefit in the short term but make changes more costly or even impossible in the medium to long term.” In other words, apps afflicted with significant amounts of technical debt can be extremely difficult to upgrade to meet new technical or competitive requirements.

The modernization process typically begins by refactoring legacy apps from a monolithic architecture (in which the codebase is organized as a single unit that has functional implementations and dependencies interwoven throughout) to a cloud-native distributed microservices architecture. But application modernization doesn’t stop there.

Because the cloud environment is constantly evolving, with technological innovations being introduced practically every day, new technical debt, and the decrease in adaptability that comes with it, begins to accumulate in an app from the moment it’s migrated to the cloud. That’s why modernization can’t be a one-and-done deal—rather, it’s a never-ending, iterative process. Martin Lavigne, R&D Lead at Trend Micro, puts it this way:

“Continuous modernization is a critical best practice to proactively manage technical debt and track architectural drift.”

Since refactoring is fundamental to the modernization process, continuous modernization necessarily involves continuous refactoring to remove technical debt and ensure that apps maintain their adaptability and utility over time.

The Impact of Architectural Drift

As Lavigne’s statement indicates, tracking and addressing architectural drift is a critical element of a successful application modernization program. That’s because architectural drift is one of the main sources of the new technical debt that migrated apps constantly accumulate as they operate and are updated in the cloud. So, what is architectural drift and why is it so important for ongoing application modernization?

Related: Benefits of Adopting a Continuous Modernization Approach

Apps are typically designed or modernized according to a coherent architectural plan. But as new requirements arise in the operating environment, quick changes are often made in an unregulated or ad hoc manner to meet immediate needs. 

As a result, the codebase and architecture begins to evolve in directions that are not consistent with the original architectural design, and technical debt, in the form of anti-patterns such as dead code, spaghetti code, class entanglements, and hidden dependencies, may grow. To make matters worse, such changes are frequently documented sparsely—if at all.

This inevitable accumulation of architectural technical debt over time is what architectural drift is all about. And it can be deadly. In an article that describes architectural technical debt as “a silent killer for business” Jason Bloomberg, Managing Partner at Intellyx, makes this comprehensive declaration:

“One of the most critical risks facing organizations today is architectural technical debt. The best way to keep such debt from building up over time is to adopt Continuous Modernization as an essential best practice. By measuring and managing architectural technical debt, software engineering teams can catch architectural drift early and target modernization efforts more precisely and efficiently.”

But that’s not an easy task. Architectural drift is difficult to identify and even harder to fix. The problem is that application architects have traditionally lacked the observability required for understanding, tracking, measuring, and managing architectural technical debt as it develops and grows over time. And, to paraphrase Peter Drucker’s maxim, you can’t improve what you can’t observe.

The Basics  of Observability 

Observability is an engineering term of art that refers to the ability to understand the internal states of a system by examining its outputs. A system or application is considered observable if its current state can be inferred based on the information provided by what are known as the three pillars of observability: event logs, metrics, and traces.

• Event logs are records that track specific events chronologically. They are critical for characterizing the app’s behavior over time.
• Metrics are quantitative measurements, such as CPU utilization, request response times, and error rates, that provide numerical data about the performance and health of the app.
• Traces record the end-to-end flow of transactions through the app. They allow developers and architects to understand the interactions and dependencies between various components of the app.

Observability is crucial for the initial refactoring of monolithic legacy apps into microservices. A fundamental goal in the refactoring process is to maintain functional parity between the original application and its post-refactoring implementation in the cloud. That is, the refactored app should initially (before any updates or corrections are incorporated) function identically with the original monolith in all feasible operational scenarios.

Achieving functional parity depends on architects having deep insight into the performance and functioning of the original monolithic codebase. A high degree of observability is required to ensure that all functionalities and use cases of the original app are identified and appropriately addressed in the refactored implementation.

Related: How Continuous Modernization Can Address Architectural Drift

Once an app has been initially refactored and integrated into the cloud environment, observability becomes even more important. An app that’s been restructured to a cloud-native, microservice-based, distributed architecture is typically composed of many different components and services that, by design, function and scale independently of one another. 

Although such apps are almost uniformly easier to understand conceptually than were their monolithic precursors, they also are more topologically and operationally complex and require an even greater depth of observability for developers to fully understand how the system is functioning.

Applying Observability in Continuous Refactoring

Architectural observability is a key element of the continuous refactoring process. It allows architects to identify, monitor, and fix application architecture anomalies on an iterative basis before they grow into bigger problems. The fundamental principle governing observability in app modernization is that comprehensive monitoring must be performed throughout the refactoring process so that developers have an in-depth view of the behavior and performance of their apps at every step.

Achieving comprehensive architectural observability involves a combination of static analyses and real-time operational monitoring that enables development teams to gain deep insights into their application’s structure, behavior, and performance at every stage of refactoring. Key performance indicators (KPIs) are defined and tracked, and monitored load and stress testing is conducted to identify potential bottlenecks and scaling challenges.

Architectural drift is detected by first establishing an initial architectural baseline that describes how the app functions in normal operation. Monitoring then continues as changes are detected in the architecture, allowing developers to proactively detect and correct issues that can lead to architectural drift. The baseline is reset and the monitoring procedure repeated at each step in the continuous refactoring process.

Tools for Observability in Continuous Refactoring

Attaining a high degree of observability requires the use of appropriate monitoring tools. Such tools must provide deep domain-driven observability through sophisticated static analyses, as well as dynamic tracking of process flows and dependency interactions during actual user activity or test scenarios.

A good observability tool will be capable of baselining, monitoring, and alerting on architectural drift issues such as:

1. Dead Code: code that is accessible but no longer used by any current user flows in production.
2. Service Creep: services are added, deleted, or modified in ways that no longer align with the established architectural design.
3. Common Classes: commonly used functions are not all collected into a shared class library to reduce duplicate code and dependencies.
4. Service Exclusivity: failure to ensure that each microservice has its own defined scope and is not unnecessarily interdependent with other services.
5. High-Debt Classes: classes that have a high degree of technical debt due to elevated levels of complexity, functional issues or bugs, and difficulties in maintainability or adaptability.

A good example of an advanced observability tool that performs these functions at a high level is the vFunction Architectural Observability Platform. This solution allows architects to manage, monitor, and fix architectural drift issues on an iterative, continuous basis. Not only does it identify and track architectural anomalies, but it notifies developers and architects of them in real-time through common alert systems such as email, Slack, or the vFunction Notifications Center.If you’d like to know more about how a state-of-the-art tool can provide the architectural observability needed to incorporate continuous refactoring into your application modernization process, we can help. Contact vFunction today to see how.

In a recent survey of corporate IT leaders, 87% of respondents said that modernizing their critical legacy apps is a top priority. When it comes to developing an effective approach to the complex and difficult task of application modernization, a great place to start is by taking an in-depth look at a Strangler Fig Pattern example and how it can help with modernization efforts. 

Companies must focus on increasing their agility in order to meet the constantly changing demands of today’s marketplace. For most, doing so will involve upgrading their business-critical legacy software applications to function effectively in today’s cloud-based technological ecosystem. 

The problem with most legacy apps is that they are extremely difficult to update, extend, and maintain because of their monolithic architecture. A monolithic codebase is organized as a single unit with functions and dependencies interwoven throughout. Because of those often-hidden dependencies, a change to any part of the codebase may have unintended and unforeseen effects elsewhere in the code, potentially causing the app to fail.

But when legacy apps are modernized and deployed using the Strangler Fig Pattern, technical debt  can be remediated more quickly, efficiently, and safely than can be achieved using more traditional approaches.

What a Strangler Fig Pattern Example Can Teach Us

The Strangler Fig Pattern is a key concept for understanding how to address technical debt and safely modernize large monolithic Java and .NET apps. But what, exactly, is the Strangler Fig Pattern?

The term was coined in 2004 by Martin Fowler. He noticed that the seeds of the strangler fig tree germinate in the upper branches of another tree. As the strangler fig tree’s roots work their way to the ground, they surround the host tree and, over time, expand so much that they strangle and eventually kill it. At that point, the strangler fig tree has, in effect, replaced the original tree.

Fowler saw this pattern as a good model for the way large monolithic apps can be safely modernized by creating a set of microservices that surround the app, replacing its functions one-by-one until the original app is entirely superseded by the framework of microservices built around it. That’s the Strangler Fig Pattern in application modernization.

Related: The Strangler Architecture Pattern for Modernization

To get a feel for how this pattern works in practice, we want to dig into a real-world Strangler Fig Pattern example that will illustrate the process and help us understand the results that can be expected. We’ll start by looking more closely at why the Strangler Fig Pattern is so crucial for the app modernization process. Then we’ll examine a case study that shows how one corporation applied the strangler fig concept in modernizing its large portfolio of business-critical legacy apps.

Why App Modernization Is So Difficult

The goal in reducing technical debt and modernizing legacy applications is to restructure them from their original stand-alone, monolithic design—a design that can integrate only partially and with great difficulty into the modern cloud ecosystem—into a more modular cloud-native microservices architecture that functions naturally in that environment.

Microservices are designed to be small, loosely coupled, self-contained, and autonomous. Each one implements a single business function and can be developed, deployed, executed, and scaled independently of the others. Because of that loose coupling between functions, a microservices-based app can be updated relatively quickly, easily, and safely.

In contrast, the very structure of the typical legacy Java app injects a high degree of complexity into the modernization process. The functions and services of a monolithic codebase are usually so tightly coupled and interdependent (and, in many cases, so inadequately documented) that unraveling execution paths and dependencies to gain a clear understanding of the code’s functionality and run-time behavior can be a complex and error-prone process. This inherent observability issue makes identifying and implementing appropriate technical remediation fixes extremely difficult, time-consuming, and risky.

The key issue in modernization is to restructure a legacy app’s architecture to give it cloud-native capabilities while ensuring that the functionality of the original app is faithfully maintained.

How the Strangler Fig Pattern Facilitates Application Modernization

Because of the difficulties an architect will typically encounter in developing a comprehensive understanding of a monolithic codebase’s behavior in all possible runtime scenarios, any attempt to completely replace or restructure a large legacy app all at once will almost certainly introduce bugs that can cause significant and often hard-to-trace operational disruptions.

The Strangler Fig Pattern allows the restructuring to be done step by step, one function at a time. At each step a single domain or microservice is implemented and fully tested before it is incorporated into the app. The testing is accomplished by running the new domain or microservice in parallel with the original app in the production environment to ensure that both always respond identically to the same inputs.

The testing process is facilitated by the use of an interface layer called a façade. All external requests to the application go through the façade. Initially, before any microservices are incorporated, the façade simply passes requests directly to the original app. But once a new microservice is implemented and verified through testing, the façade directs all requests concerning that function to the microservice rather than to the old app.

Because each domain or microservice is exhaustively tested in normal operations before it replaces the equivalent original function, there’s typically no need to ever bring the app offline to do a cutover to the new version, and the chances of unexpected disruptions due to the restructuring process are all but eliminated. Nor is there any need to maintain two different versions of the app since the original code is never changed but is simply replaced, function by function, one at a time, by microservices.

Eventually, all the legacy app’s functions are replaced by the equivalent fully tested microservices. At that point the Strangler Fig Pattern has done its job—the old app has been entirely displaced and can be retired.

Now, let’s look at a practical Strangler Fig Pattern example.

A Strangler Fig Pattern Case Study

Many large and well-known companies, such as Netflix, Google, IBM, and Microsoft, use the Strangler Fig Pattern in their application modernization efforts. A global leader in Software Security with more than a half million customers around the world and $2 billion in revenues, is also on that list.

One of their most business-critical software systems was in desperate need of upgrading. This system, which had a combined 2 million lines of code and 10,000 highly interdependent Java classes, was originally implemented on-premises. 

Parts of it were successfully migrated to the Amazon Web Services (AWS) cloud using a lift-and-shift process. This provided some improvements in compute resource usage. But because the codebase was still monolithic in its architecture, with deep interdependencies across multiple modules, the system experienced significant challenges in terms of performance, scaling, development velocity, and deployment speed.

Because their key security suite was still overwhelmingly monolithic even after it was rehosted to AWS, it was increasingly causing integration and upgrade problems, leading them to mount a major modernization effort.

The company’s modernization team elected to work with an external partner to implement a Strangler Fig approach using an advanced, state-of-the-art, AI-based modernization platform. They started by using the modernization platform to conduct static and dynamic analyses to identify complex circular or unnecessary dependencies in the monolithic code and determine appropriate service domain boundaries. They then employed iterative refactoring, using the Strangler Fig Pattern, to eliminate those dependencies and create relevant microservices.

Related: Simplify Refactoring Monoliths to Microservices with AWS and vFunction

The process of refactoring the monolith to create microservices, which would have taken more than a year if done manually, was completed in less than three months. And the time to deploy an update to AWS was reduced from nearly an entire day to one hour.

Unleashing the Potential of the Strangler Fig Pattern

The benefits that can be gained in our Strangler Fig pattern example are available to any company that’s faced with the imperative of fixing technical debt and updating their legacy apps to keep pace with the requirements of today’s ever-changing marketplace and technological environments. Although modernizing a suite of monolithic apps is a highly complex and challenging undertaking, companies can make the process far less daunting by doing three things:

1. Use architectural observability and the Strangler Fig Pattern to iteratively refactor your monolithic code into microservices.
2. Work with a modernization partner organization that has deep experience and expertise in transforming monolithic Java apps into a microservices implementation.
3. Rather than performing modernization tasks manually, make use of the advanced, AI-based tools that are now available.

If you’d like to explore how implementing the Strangler Fig Pattern can boost your company’s app modernization efforts, a good place to start is where our case study customer started. After making little progress on their own for over a year, they teamed with vFunction for expert guidance and assistance in the modernization process. 

They used vFunction’s state-of-the-art, AI-based continuous modernization platform to deploy architectural observability, substantially automating essential tasks, such as performing static and dynamic analyses to identify domains and dependencies in monolithic code, determining appropriate service domain boundaries, and refactoring monolithic code functions to microservices.

To get started with unleashing the power of the Strangler Fig Pattern in your company’s technical debt and modernization efforts, contact us today to request a Strangler Fig Pattern demo.

For a growing number of companies today, app modernization is a high priority. They’re attempting to update their IT infrastructure and reduce costs by moving software applications out of their on-premises data centers and into the cloud. According to CloudZero, more than two-thirds already have some or all of their IT estate in the cloud, with 39% running at least half of their workloads there.

But for many, this effort hasn’t worked out as they hoped. According to a report from Fortinet entitled, “The Bi-Directional Cloud Highway,” 74% of companies have migrated apps to the cloud but then moved them back again. Some of those return trips were planned, but many constituted an implicit admission that the initial transfer to the cloud failed to produce the expected results.

So, what went wrong?

In many cases, companies were disappointed because they didn’t obtain the financial savings they anticipated. CloudZero notes that six out of ten survey respondents report that their cloud costs are higher than expected, while 53% say they have yet to see any substantial ROI from their cloud investment. Respondents in another survey estimate that their organizations have wasted 32% of the funds they’ve spent on the cloud.

But it doesn’t have to be that way. Companies that develop and execute a well-targeted strategic plan for their cloud efforts can reap significant savings by modernizing their legacy apps to give them cloud-native capabilities.

In this article, we want to identify some of the most significant features of such a strategy.

How App Modernization Helps Reduce Costs

In the typical company today, engineers spend about 33% of their time dealing with technical debt. That term refers to the amount of unplanned work an IT organization must devote to supporting apps that, due to their outdated design or implementation, have become extremely difficult to maintain or adapt to meet new requirements. Continually investing scarce resources into keeping such apps running is a common but costly practice.

Related: How Much Does it Cost to Maintain Legacy Software Systems?

On the other hand, modernizing legacy applications to give them cloud-native capabilities can produce significant savings in and of itself. Intel quotes a recent study as declaring that when companies reduce their technical debt load by modernizing their legacy app portfolio, they realize immediate savings that amount, on average, to 32% of their IT budget. And according to IBM, companies that implement an effective app modernization program can expect benefits such as:

• 15% – 35% year-over-year infrastructure savings
• 30% – 50% lower app maintenance and operational costs
• 74% lower costs for hardware, software, and staff
• 14% increase in annual revenue

Getting App Modernization Right

Many companies fail to reap the expected benefits from their app modernization efforts because they confuse modernization with simple migration. They assume that by simply migrating their legacy apps from a data center environment to the cloud, without making any substantial changes to the app design or implementation, they achieve a significant degree of modernization. That’s not the case.

Legacy apps typically are monolithic in structure, meaning that the codebase is a single unit that has functional implementations and dependencies interwoven throughout. The very design of such apps creates a high level of technical debt because a change to any function can have unexpected effects elsewhere in the codebase, potentially causing the app to fail. Because of that inherent technical debt, monolithic apps are by nature very difficult to maintain and update.

When a monolithic app is transferred as-is to the cloud (a process called “lift and shift”) it carries its technical debt with it: all the factors that made the app difficult to maintain and adapt in the data center continue to do so in the cloud. And although it still needs the same CPU, memory, and storage resources it did in the data center, a monolithic app cannot efficiently access those resources in the cloud. All this can have a huge negative impact on cloud costs. In an article on the lift and shift methodology, IBM puts it this way:

“An application that’s only partially optimized for the cloud environment may never realize the potential savings of cloud and may actually cost more to run on the cloud in the long run.”

In reality, a monolith is the most expensive type of app to run in the cloud. It’s only when monolithic apps are truly modernized, by refactoring them to a cloud-native microservices architecture, that the full benefits of the cloud are obtained.

Reducing Cloud Costs

Once legacy apps have been refactored to have cloud-native capabilities, further steps can be taken to reduce cloud costs even more. Cloud cost efficiency is built on the fact that cloud-native services are inherently elastic, scalable, and adaptive. You can minimize your costs by fine-tuning your cloud operation to take full advantage of these characteristics. Here are some ways to do that:

Reduce Operational Costs

Because of the cloud’s superior elasticity, cloud-native resources, including newly modernized legacy apps, can scale instantly and automatically based on demand. That allows you to rightsize your compute resources to fit your utilization requirements. Here are some ways to do that:

1. Attribute your costs. To make sound decisions regarding forecasts, budgets, and cost optimization, you must understand how your IT costs are allocated across your organization. Identifying which functional areas contribute most to your overall cost structure allows you to sharply focus your cost reduction efforts.
2. Inventory your compute resource needs. This enables you to determine the instance size and type you need for each workload based on historic usage patterns, and select the lowest-cost options that meet your requirements.
3. Monitor your cloud resource utilization. Avoid over-provisioning by continuously monitoring your cloud resource usage patterns to identify utilization trends (your cloud provider probably offers tools for this). This will help you to rightsize your resource commitments based on your actual cloud workloads.

Related: Application Modernization – 3 Common Pitfalls to Avoid

4. Implement autoscaling. Incorporate mechanisms into your workloads to automatically adjust the number of instances or resources you use based on current demand.
5. Consider serverless computing. Serverless computing platforms, such as AWS Lambda, Google Cloud Functions, or Azure Functions, relieve you of the necessity of provisioning and managing virtual servers and allow you to pay only for the execution time you consume.
6. Use cloud-native services. The cloud offers many managed services that often can outperform services implemented in your data center, and do so at a lower cost. For example, using a cloud-native database service such as AWS DynamoDB or Azure Cosmos DB is often far more cost-effective than migrating your on-prem DB solution to run in the cloud.

Reduce Licensing Costs

Licensing costs are an often overlooked but potentially huge element of your overall cloud expenses. AWS makes the point very clearly:

“Without optimizing your licensing in cloud migration, the cost of overprovisioning third-party licensing can exceed the cost of compute.”

And in its lift and shift article IBM adds that your existing data center software licenses may not be valid for the cloud:

“Licensing costs and restrictions may make lift and shift migration prohibitively expensive or even legally impossible.”

Here are some steps you can take to reduce your licensing costs:

1. Inventory your current licenses to determine if any are underutilized, no longer needed, or redundant. Check with vendors and cloud providers to see if it’s possible to transfer your existing licenses to your cloud environment.
2. Proactively negotiate cloud licensing agreements with vendors based on current usage patterns and your assessment of future needs in the cloud.
3. Consider alternatives such as open-source software or subscription-based services that offer a pay-as-you-go model for cost-effective scaling. Explore whether you can use managed cloud-native services that have licensing costs already built in.

Reduce Project Costs

App modernization allows you to:

1. Increase staff efficiency required for maintaining and upgrading your legacy apps and reducing their technical debt. Once apps have been restructured into a microservice architecture they’re far easier to understand and adapt. That means that fewer people are required for managing them than were needed before modernization.
2. Shorten release cycles by adopting a continuous integration, continuous deployment (CI/CD) modernization methodology. By breaking monolithic apps into independent microservices, you allow much of your development and maintenance work to be done in parallel since each microservice is assigned to its own team.
3. Drive increased agility and innovation by leveraging existing cloud-native resources (rather than building from scratch) to minimize the work your developers must perform to create the new apps and features that can propel your company forward in its marketplace.

Setting the Stage for App Modernization

Application modernization can provide substantial cost reductions for your organization’s IT operation. But it’s important to note that significant savings can only be achieved by making extensive use of automation in the modernization process.

The process of analyzing a company’s portfolio of monolithic legacy apps (which may have tens of millions of lines of code and thousands of classes) to untangle hidden dependencies and reveal service boundaries, and then refactoring those apps into microservices, is a highly complex and labor-intensive endeavor. Any attempt to accomplish it using manual methods would be prohibitively expensive in terms of time, personnel, and financial resources.

What’s needed instead is an AI-based automated analysis tool that can produce comprehensive static and dynamic analyses of your legacy apps far more quickly than human engineers could. That kind of accurate, detailed information about the current state of your legacy app estate can then serve as the basis for building an effective modernization plan.

The vFunction application modernization platform can quickly and automatically analyze your apps to assess dependencies, technical debt, service boundaries, and other important modernization parameters. It can substantially automate the process of refactoring a monolithic codebase into microservices, providing your team with significant savings in time, personnel, and money.

To experience first-hand how vFunction can streamline your application modernization efforts and help you to substantially reduce your IT costs, request a demo today.

Application modernization continues to gain traction. According to Foundry’s State of The CIO Study 2023, modernizing applications and infrastructures remains the third-highest initiative for Chief Information Officers (CIOs). It is also among the top five factors driving IT investment dollars in 2023. In fact, 91% of CIOs expect their budgets to increase or remain the same. The funds are needed to address application modernization trends.

Although organizations have made progress in modernizing legacy systems, they still have work to do if they want to achieve the following top five business initiatives:

• Improve operational efficiency
• Increase cybersecurity defenses
• Transform business processes
• Enhance the customer experience
• Increase profitability

The ongoing focus on modernization indicates that Kubernetes (K8s) and cloud platforms alone have not solved the problems of large legacy monoliths that cannot be easily lifted and shifted. In these cases, application modernization will require refactoring or rearchitecting.

Modernization is at the core of 2023’s number two priority—cybersecurity. Legacy systems present a significant risk. Not only are they unable to defend against modern attack vectors, but they contain old vulnerabilities that were never fixed. Cybercriminals actively scan potential targets for legacy systems that have unpatched vulnerabilities.

At the same time, outdated systems and monolithic architecture hinder business operations and user experience. Older technologies do not play well with advanced solutions. Transforming operations for improved efficiencies is the top priority for 45% of CIOs in 2023. In the current economic environment, more efficient processes are important for lowering expenses and protecting profitability.

Cloud migration plays a significant role in application modernization. While the cloud is not a prerequisite to modernization, many companies have made it part of their cloud strategy. Exactly how they combine to create a strategy depends on the organization.

Application Modernization Trends and the Legacy Dilemma

For most businesses, existing applications are still vital to business processes. They often support core functionalities and host essential data. Most organizations still use legacy systems because they are crucial to business operations. Dismantling such systems and building new ones would destabilize or disrupt business processes. 

Related: What is Application Modernization? The Ultimate Guide

Monolithic applications technologies, infrastructure, and architecture are more rigid than newer microservices architectures. The older technologies limit the IT teams’ ability to develop new features quickly and efficiently. Some legacy systems are already obsolete, making replacing them challenging or impossible. In such cases, the only alternative is modernizing applications.

How Companies View the Legacy Dilemma

In many ways, companies view legacy systems “as the devil they know.” They are usually an integral part of business operations, and the magnitude of changing out a core system is unfathomable. As long as the system functions, they are reluctant to risk disruption.

For many organizations, the solution resides in the cloud. If lifting and shifting monolithic applications to the cloud adds to the life of a legacy system, many companies are willing to integrate old code into cloud-based platforms. However, the strategy is not without challenges.

Addressing Lift and Shift Challenges

Old and new technologies do not merge seamlessly. It often requires APIs or middleware to allow the systems to coexist. Once operational, the systems may lack performance capabilities. These are just a few of the challenges of rehosting a legacy application in the cloud.

Incompatibility

It may be possible to lift and shift applications to the cloud, but some apps are not compatible. Identifying these specific apps helps determine how to handle them before the move. Rehosting applications in the cloud can also lead to performance and latency issues. Applications that depend on third-party software are also often unsuitable for the lift and shift method.

Inefficiencies

While rehosting may move a legacy application to the cloud faster, it may take longer to optimize the older technology. Some apps may also be unable to leverage cloud computing resources. Since legacy applications are not cloud-native, it may be challenging to run them efficiently. Other application modernization methods, such as refactoring or rearchitecting, can deliver a more cloud-native application.

Cost

Moving a legacy application to the cloud with minimal changes may appear to be the least expensive and lowest-risk option. However, the long-term costs could be immeasurable. Without a cloud-native environment, organizations may struggle to deliver competitive products, resulting in lower market share and few customers.

Even though the legacy application is operating in the cloud, it cannot take advantage of all cloud capabilities. Critical visibility may not be available, making it more difficult for IT to troubleshoot the application or defend against cyberattacks. When deciding how to best modernize applications, businesses need to evaluate both long- and short-term factors.

Security Issues

Cloud security depends on the individuals implementing it. On-premise security best practices are not the same as in the cloud. Organizations looking at their first cloud application often lack the expertise to secure a cloud environment. Finding the talent to fill that gap is a challenge.

Staffing shortages in the tech field continue. The US Bureau of Labor Statistics predicts that the need for cybersecurity personnel will increase by 35% between 2021 and 2031. Job openings for software developers will increase by 25% during the same ten years. Overcoming the challenges of finding and retaining the necessary talent is a formidable task to ensure a secure cloud environment.

Shifting Priorities 

A recent survey on the future of the cloud found that organizations that view moving to the cloud as a strategic part of their digital transformation achieved higher levels of innovation than their less strategic counterparts. The survey highlighted the value of maximizing cloud services. For example, those companies with cloud services that support advanced technologies such as artificial intelligence are 1.7 times more likely to receive increased value than businesses with a less mature infrastructure.

However, cloud-based transformation requires modernization. According to IBM, modernization amplifies the value of the cloud as much as 13 times if it is part of an end-to-end transformation. Even though 83% of executives agree that modernizing applications and data is critical to their business strategies, only 27% have modernized their workflows. 

As priorities shift, organizations are re-evaluating their modernization strategies. Aligning business, modernization, and cloud strategies enables companies to optimize their cloud services to utilize application modernization trends.

Creating a Cloud Strategy for Application Modernization 

Every business strategy should include a cloud strategy. Companies adopting a “cloud-first” policy need a plan for onboarding new and modernizing old workloads. As they look to develop strategies, businesses should consider implementing policies such as the following:

Modernizing Data

Gartner analysts predict that by 2025, at least 85% of companies will adopt the cloud-first principle. However, it won’t be easy to implement their digital strategies without cloud-native technologies. This rings true since the majority of enterprise workloads are not cloud-ready. 

Related: Q&A Series: The 3 Layers of an Application: Which Layer Should I Modernize First?

So how do workloads become cloud-ready? Modernizing data is about replacing legacy databases to be able to handle distributed and streaming data sources and sinks. In order to modernize the data layer, modernization experts recommend starting first with the business logic layer.

Migrating to a New Architecture

Another application modernization trend is embracing new architectures. Instead of shifting a legacy application to the cloud in its entirety, you can move some of its features to more efficient architectures. This enables faster development.

When modernizing any application architecture, leveraging architectural observability tooling is essential. This will pinpoint architectural hotspots and drift issues. Addressing these problems incrementally while moving to new architectures will solve such issues. It also addresses security, scalability, and reliability concerns and helps resolve issues with tolerance, capacity, and redundancy.

Turning Monolith into Microservices

Monolithic applications have a single large codebase. In contrast, microservices applications operate independently. Every feature or application handles one service. This transformation to microservices improves the development and deployment of updates and new features. Technology stacks become more flexible. Also, there’s minimal risk of downstream effects that comes with changes in the underlying code.

Moving to the Cloud

The cloud revolutionized digital experiences with innovations such as mobile payment. Clearly, most legacy applications need cloud modernization. Cloud-native platforms allow developers to leverage the principles and tools of the cloud environment. It becomes possible to deploy new digital workloads to cloud-native platforms.

Going Hybrid

In some cases, fully modernizing for the cloud is unnecessary. Depending on business goals and budgets, organizations can incorporate public, private, and hybrid clouds. For instance, if an application experiences usage spikes, a public cloud can minimize the spikes. It can scale appropriately to accommodate the spikes at lower costs. However, if there’s little or no financial gain from a complete migration, a hybrid cloud is another option. 

Incorporating Trends

Unless modernization is part of a cloud strategy, organizations will fail to realize its full value. Shifting legacy code to the cloud doesn’t provide the agility or resilience required in today’s competitive environment. Without application modernization, companies cannot address the 2023 trends impacting digital transformation.

How 2023 Trends Impact Application Modernization

Not all trends are positive. Ongoing labor shortages and cost-based decisions will hamper modernization efforts. Disruptive technologies will add pressure for cloud-native capabilities, and a lack of cultural change will allow technical debt to accumulate. These are just a few of the trends companies must address as they look to the future.

Finding Tech Talent

IBM’s study found that 45% of companies consider a lack of expertise as an obstacle to modernization. With less than 10% of employees having cloud or modernization experience, organizations need to look beyond new hires to acquire the expertise. Executives say financial constraints are the primary reason they lack experienced employees. 

1. Recruiting talent is expensive. Despite recent staff reductions in the tech sector, finding people to fill open positions can still take four to six months. That assumes CIOs can find them. Gartner found that 86% of companies have encountered more competition for candidates in 2023. Stiff competition means higher wages at a time when money is tight, and inflation paints an uncertain economic outlook. 
2. Retaining staff is critical. Garnter’s survey found 73% of CIOs worry about staff attrition. As demand continues to outpace supply, headhunters are looking to entice employees to change employers. Companies need to invest in their technical staff if they want to retain them.

Providing growth opportunities not only improves a business’s technology capabilities but also increases employee retention. Unfortunately, 43% of organizations cite budget constraints as the reason they fail to offer skills development. Another 38% say they are too busy to lose time to training, and 32% would rather hire new talent. 

Related: Why Organizations Are Adding App Modernization to CCOE

Deciding whether to recruit or retain depends on an organization’s skills gap. Rather than default to a set strategy, CIOs need to determine what in-house capabilities exist with a little upskilling and what expertise needs to be hired. CIOs should also consider modernization tools that can reduce the time individuals spend on low-value tasks.

Understanding Disruptive Technologies 

Knowing how disruptive technologies will impact business growth begins with modernization. New technologies such as artificial intelligence (AI), the Internet of Things (IoT), and virtualization all require modern applications operating in a cloud-native environment. Legacy systems will be too far removed to fit comfortably with emerging technology.

Artificial Intelligence

Generative AI uses AI to produce content. It acquires and synthesizes data to compose responses. For example, ChatGPT offers AI-powered chatbots that understand natural language, retain context, and deliver the most probable outcome. While generative AI is in its infancy, imagine how personalized customer experiences could be. Online shoppers could finally receive answers to questions such as 

• Will this chair go with the rest of the room?
• Which appliance is the best choice for my needs?
• What goes with this shirt?

Answers to these questions can quickly dispel barriers to online purchases. However, organizations will need a modern infrastructure to take advantage of generative AI.

Internet of Things (IoT)

From drones to sensors, more devices are being deployed every day. Each device collects data that, when totaled, results in millions, even billions, of data points. Processing massive amounts of information requires cloud-based resources. It demands modernized applications that can turn data into valuable insights. 

When an agricultural enterprise invests thousands in IoT devices, it needs applications that can take advantage of cloud computing capabilities. Deploying atmospheric sensors across acres of farmland helps farmers know when conditions are right for planting and harvesting. Having the right foundation ensures the results will be comprehensive and timely.

Controlling Technical Debt

Organizations continue to collect technical debt. According to McKinsey, they are stuck in a vicious cycle where IT struggles to keep up with requirements—expediency rules how solutions are implemented. The landscape grows more complex with each less-than-optimum deployment.

Most companies are aware that technical debt is killing modernization efforts. What they may not realize is that 40% of IT is technical debt. For every project, companies pay an additional 10% to 20% to address technical debt. Among CIOs, 30% believe at least 20% of their new product budget is consumed by technical debt.

McKinsey’s research found that reducing technical debt has far-reaching impacts. Engineers could spend as much as 50% more time working on value-oriented products. They would spend less time addressing system complexities. Uptime would improve, and resiliency would become a reality. To move forward, businesses need to control their technical debt.

Reducing technical debt isn’t just an IT problem. It’s a cultural problem where expectations focus on fast and low-cost solutions. No matter the intentions, if the culture is more concerned with immediate results than long-term viability, technical debt will continue to accumulate. Without an application modernization plan, accumulated debt will weaken an organization, making it impossible to remain competitive.

Future Proofing the Enterprise

McKinsey recommends that organizations make budget allocations to control technical debt a strategic decision. It’s not just flagging funds for modernization. It’s managing those funds separately, creating an environment of accountability and transparency. Executives must incorporate modernization into their strategic plan and develop monitoring processes to hold everyone accountable.

For example, the accounting department desperately needs a fix and hounds IT for delivery. IT can cludge something together, but the solution only adds to its technical debt. IT could deliver a quick fix and then provide a solution that eliminates the associated debt. However, delivering the follow-up solution means the sales department will need to wait another two weeks for their update.

Traditional approaches would have IT deliver the quick fix and complete the sales update on time. The accumulating debt would be IT’s problem to fix while juggling the myriad of high-priority projects. In many cases, the correction never happens.

Under McKinsey’s system, the decision would be strategic. It would mean balancing the short-term gain against future modernization. It would require executives to back the appropriate strategic decision regardless of the immediate impact. 

Looking Beyond Cost

Although the majority of executives understand the toll technical debt inflicts on their businesses, they still consider cost as the primary factor when looking at application modernization. To future-proof their organizations, executives need to evaluate the opportunity costs as part of the cost analysis. What future capabilities will be lost if modernization doesn’t happen?

Moving technical debt considerations to the boardroom changes how application modernization happens. If a strategic objective is to use generative AI to improve customer experience, modernizing becomes part of the critical path. Updating older technology is woven into the business strategy to ensure that the use of generative AI happens. 

Identifying IT’s skill gaps allows companies to assess where to place their human resource dollars. It also enables businesses to find automated solutions that can free staff from time-consuming, repetitive work. The more comprehensive the talent pool, the better an enterprise can navigate the future.

Navigating the Future

vFunction’s solution helps organizations future-proof their applications. Its platform helps turn Java or .NET monolithic structures into microservices. Using AI-powered technology, the product provides IT departments with the ability to control architectural drift in a continuous modernization environment. Request a demo or watch the video to learn more about future-proofing your enterprise.

As more organizations implement a shift-left approach to software development, architects are looking for ways to become part of a collaborative team. They can no longer deliver a design to development and walk away. With a continuous modernization approach, friction between what was planned and what was implemented disappears as teams work together to address architectural changes as early in the process as possible. 

Originally, the shift-left movement focused on security. Its goal was to create systems where security was part of the design rather than added later in the development process. The shift required software architects to consider security measures in their initial design. It meant testing earlier and addressing design limitations while development was just beginning.

The changing mindset added pressure on engineers to maintain visibility into an application’s architecture. Evolving security requirements often demanded changes in design. That created a problem. How do you change a design if you don’t know what the design is doing in production? Even more critical is how you control design changes in a continuous integration/continuous development (CI/CD) environment. Can continuous modernization help?

What is Continuous Modernization?

Continuous modernization not only extends the CI/CD process, but more importantly, it enables organizations to incrementally modernize software to minimize technical debt and architectural drift. It gives companies a path for improving security as architectural vulnerabilities appear. Unlike waterfall approaches, architecture updates are provided throughout the SDLC process, not deferred to future releases or never.

However, all software suffers from growing technical debt. Changes are based on expediency rather than design integrity. If not controlled, an application can deviate from its original infrastructure, making it difficult to locate and fix flaws. Understanding architectural drift is imperative to help teams leverage continuous modernization to minimize architectural erosion.

What is Architectural Drift?

Software evolves—sometimes by design, but often in response to business demands. Users want a new feature. The application needs better performance. Of course, delivery schedules are tight, requiring trade-offs. These decisions often result in technical debt and architectural drift.

Architectural drift results from the unchecked evolution of runtime software that leads to a lack of coherence and clarity in the software’s design. Dead code, class entanglements, and deep dependencies contribute to Brian Marick’s “big ball of mud” that prevents architects from observing how systems work in live environments. 

Related: Getting Leadership Buy-in on a Continuous Application Modernization Strategy

Unless engineers can see the architecture in operation, they cannot determine how far the software has drifted from its original design. They’ve lost control of the ship, and it’s drifting in open waters.

How Does Architectural Drift Become a Problem?

When ships drift, they go where the ocean takes them. Left unchecked, they go aground or succumb to the elements. The same can be said of architectural drift. Without correction, a system flounders. Its agility falters, and its viability fails. Like a ship, it succumbs to its environment.

Start with the Design

Architectural drift can begin before a developer writes a line of code. Designs that use tightly coupled structures with layered dependencies allow developers to rely on the infrastructure to maintain control. Function calls disappear into a maze that mysteriously delivers a result — almost like magic. If an error occurs, architects have few resources to help identify where the problem resides.

Even with distributed architectures, engineers can struggle. Microservices deployed across an application throw an error. How do architects determine if the error is isolated to a single instance? How do they determine what triggers the error? Without observability, resolution becomes time-consuming.

Add Changes Over Time

Not every software change adds to an application’s architectural technical debt. However, those that do pose a problem for engineers. During development, design changes may try to follow best practices for identifying deviations from the original architecture specification. But shift happens.Whether requirements change or expediency calls, architectural erosion is the result. Modifications are made that alter the original design. If left unchecked, these changes accumulate and increase the architectural drift of an application.

Mix in a Lack of Visibility

While visibility tools abound for applications, these same tools are not available at the architecture level. Without tools to analyze, track and correct architectural erosion, architects can’t adequately define how far the design has drifted. Even with better tools, engineers need observability capabilities.

Unlike monitoring, observability takes a proactive look at the internal state of the software during runtime. Its goal is to identify critical anomalies in a system’s architecture. To be effective, observability must be consistent, holistic, and automated. But what exactly is observability?

What is Observability? 

Observability tries to describe the internal state of software through external outputs. Observability typically uses three data sources known as the three pillars of observability. 

• Logs. Record what happens within an application, including its infrastructure.
• Metrics. Defined data points used to flag unusual behavior.
• Traces. Provide visibility of step-by-step code execution.

Events are often considered a fourth pillar. These customized records highlight potential problems through pattern identification,

While the data sources provide useful information, they have their limitations. Using observability tools that combine the information into comprehensive views delivers a realistic picture of system operations. Unfortunately, not every system component has the same level of visibility tools.

Why is Architectural Observability the Answer?

System architects have worked with “big balls of mud” for decades. They have struggled to untangle threads and assess problems through indirect means. The difficulty with architectural observability is poor tool creation.

Systems Are Complex

Monolithic structures have given way to distributed architectures that include microservices and containers. Sustained visibility across a distributed system often requires multiple tools that deliver data in varying formats. What’s missing is data consolidation that delivers a holistic view.

Data is Complex

Sorting through volumes of data recorded in real-time presents a challenge. Even with automated tools, data management can become time-consuming. If the data is not persisted, timely extraction may be needed for an accurate view over time. These factors complicate tool creation. Data consistency is crucial to identifying drift.

Related: Shift Left to Avoid Technical Debt Disasters: The Need for Continuous Modernization

A further complication to consistency is data separation. In collaborative environments, having access to all pertinent data may not be an issue; however, in situations where data silos exist, incomplete information makes a comprehensive evaluation impossible.

Business is Complex

Tying architectural events to business outcomes isn’t easy. Without an understanding of business complexities, architects may focus on the wrong metrics and fail to collect crucial data for analysis. For example, engineers may place a high priority on determining why CPU usage increases when a set of microservices runs. Executives may consider increasing page load times as more significant because slower load times can translate into lost revenue for an eCommerce site.

Observability allows engineers to see how released software deviates from its original design. It requires the right tools and a plan to address architectural drift.

How to Address Architectural Drift

Observability needs tools to establish a baseline and set thresholds. Best practices should proactively detect and correct abnormal behaviors that lead to architectural drift. The planned outcome should deliver a process that is consistent, holistic, and automated.

#1: Establish a Baseline

Baselines establish a starting point. They should include service topologies that itemize common and core business services. They should identify critical components that are routinely audited to detect deviations from the baseline. Automating the process allows architects to track those ad-hoc changes that impact an application’s infrastructure.

#2: Identify Service Exclusivity

As part of baselining, measure service exclusivity. Knowing how many independent classes and service resources are in use highlights dependencies that increase architectural debt. This baselining can help identify possible debt early before it becomes a paralyzing problem.

#3: Set Thresholds

Architects can establish thresholds for proactive observations of a system’s architecture. Automated systems enable engineers to schedule observations, configure measurements, and start analyses. Automating the collection of key metrics expedites the evaluation process for faster resolution of pending issues.

#4: Automate the Process

Automating data collection is only the first step in delivering comprehensive observability. Automation must turn that data into valuable insights that enable architects to minimize architectural erosion. The landscape is too complex and changes too rapidly for manual processing.

Continuous Modernization and Architectural Drift

Architects must be proactive in a continuous modernization environment. They must shift left to be more engaged in the initial design, whether refactoring, rearchitecting, or starting new. Their job persists through an application’s lifecycle because they have the tools needed to observe and correct architectural drift.

vFunction’s Continuous Modernization Manager provides architects with the tools needed to overcome observability challenges. Its automated modernization solution provides a holistic approach that delivers insights based on consistent data. The manager allows architects to:

• Shift left into the development cycle
• Monitor, detect and identify architecture drift
• Set baseline and thresholds
• Send alerts when critical 

vFunction enables engineers to remain proactive through an application’s lifecycle. It helps maintain the architectural integrity of the software as it is continuously modernized. To see how we can help with your application modernization needs, request a demo.

How to get buy-in and budget for successful application modernization

Bob Quillin, chief ecosystem officer at vFunction, is an industry expert when it comes to application modernization. He often finds that the biggest hurdle to application modernization is developing a compelling business case to take on such a complicated task that can be costly and frequently fraught with risk. Business leaders need justification for budget allocation, yet most architects lack data to prove it’s essential or determine the resources needed to pull it off successfully.

A business case must be backed with data — data that is easy to understand and see the bigger picture. Business leaders don’t often want to be told something has to be done, preferring to be shown why it needs to be done and what is likely to happen if it isn’t. This is precisely what Bob and his team at vFunction do with their Assessment Hub and Assessment Hub Express tools. These solutions were built specifically for architects who want a simplified way to build a data-driven application modernization plan and need to create a strong business case to do so.

In this interview with Bob, we discuss the key inhibitors to successful modernization projects and how to develop a rock-solid business case for application modernization. He will also discuss how the vFunction Assessment Hub works and the benefits it brings for gaining rapid visibility into the health of the entire application estate.

Q: Tell me why building a business case for application modernization is so difficult.

Bob: One of the key inhibitors to modernization projects being successful is that it’s hard to build a business case to get them approved and off the ground. Traditionally, architects haven’t had a clear understanding of what exactly needs to be done, how long it will take, or how complex it will be, all critical components of a business case. But now, we can provide the science and data to build the case.

Q: What happens without a business case?

Bob: Oftentimes, nothing. Modernization projects are either delayed, never start, or end in failure. If you aren’t looking inside and analyzing the application architecture, you can’t accurately predict the value of modernization. Without the business case, you can’t have a successful modernization project and vice versa. 

In our 2022 study with Wakefield Research of 250 technology professionals, we found, “Failure to Accurately Set Expectations” was the number one reason given by respondents who started modernization projects they didn’t complete. Areas of particular concern include unrealistic expectations relating to budget and schedule requirements and anticipated project results such as improvements in engineering velocity and application innovation.”

With vFunction’s suite of application modernization solutions, architects and senior engineers can understand the technical debt in each app, pull that out and fix the prob, modernize it, and continually monitor and fix new issues to prevent technical debt from accumulating again.

Q: How do architects know they have a technical debt problem?

Bob: From a qualitative level, application leaders have a strong sense that they are carrying a heavy load of technical debt by the symptoms they go through every time they add a new feature. How long does it take? If it’s taking your team more and more time each sprint, you know you have an issue. It can also become harder to add new features because it’s more difficult to figure out where to add the new feature and integrate it. It will also become much more difficult and time-consuming to test. One small change in a monolith requires you to test the entire application because you don’t know the downstream implications. 

With monoliths, there is a high degree of dependencies, so release cycles expand, engineering velocity decreases, and eventually, your ability to compete and add new features slows. You’ll often see a backlog of feature requests you have in your project management and tracking systems that you can’t keep up with. It significantly hampers the Dev team’s capacity and production. 

Q: How can all of this lead to increased costs?

Bob: If you have a spike in demand (requiring more CPU and memory resources) or it’s an important application, it becomes difficult to scale a monolithic application without buying bigger machines or cloud instances types or shapes. On the flip side, cloud-native architectures are more horizontally scalable with greater elasticity. The two factors I hear architects complain about are that they can’t scale and costs go up. 

There are costs to run the app, even after a lift and shift. If you break down that monolithic application into microservices, you can be more efficient in how you apply the wider variety of cloud instances to that particular need. Release velocity increases, testing speed cycles increase, and there is elasticity and scalability, all at a lower cost. These are all reasons to break down monolithic apps into microservices.

Q: If there is such a need and so much to gain, why is it so hard to get an application modernization project off the ground?

Bob: We surveyed 250 application teams and looked at the top reasons for failure. The number one reason was a failure to set expectations for leaders and architects accurately. At a minimum, they need to understand what application modernization will solve in terms of technical debt, how long it will take, and what it will cost. They need an ROI — what they will get in terms of reducing technical debt and increasing innovation.

Q: Why is this information so elusive?

Bob: Currently, the only information available is mostly qualitative. In other words, they just use their experience and best guesses, bring in consultants or a system integrator, or outsource the whole thing. It isn’t based on any science, automation, or best practices. When they don’t have data to measure architectural technical debt, they can’t assess the complexity of the app or the risks of changing it. They need observability to understand dependencies, dead code, and what’s common and not common code — all the things that make up the architecture. Without it, it’s nearly impossible to make a plan on how to rearchitect an architecture you don’t understand. A classic business mantra is if you can’t measure, you can’t improve it. When you can measure it, you can decide how to improve it, what to fix, how long it will take, how complex it will be, and what the cost will be. 

Q: vFunction directly addresses these challenges with the vFunction Assessment Hub. Is there anything else out there like it?

Bob: There are other tools that analyze source code to report back how it is written, any number of code “smells” or poor software engineering practices, and cyclomatic complexity that tracks the number of linearly-independent paths through the application. Source code analysis is different from architectural analysis, which looks at how an app is built and constructed versus how it is written. It’s easier to track little source code errors along the way versus fixing the architecture itself, but you never truly modernize the application if you don’t address the underlying root cause of technical debt. 

I like to think of it like a house. When you’re updating a kitchen or adding a bathroom to a massive house, you have to figure out the architectural components before you can tie new plumbing into the old. All of the plumbing is interdependent, so if you make a mistake with one piece of plumbing, it can impact the entire plumbing system. The monolithic application is the house. Think how much easier it is if you had the opportunity to break up a mansion into individual casitas, or microservices in this analogy. Adding on or fixing plumbing issues is now much more manageable, with fewer dependencies to worry about.

Security is another issue. If you add a piece of open-source code that has a known vulnerability, you can scan that library or code prior to adopting that component. People call source code tracking “checking for code smells,” which means looking for different errors or anti-patterns that developers have added along the way that can be detected and fixed. Security analysis tools will pick up security issues. Static analysis tools pick up code smells. At vFunction, we actually use these in our own software development process, but what’s missing typically for development teams are measurement and tracking tools for architectural technical debt 

Q: What is an example of an architectural issue?

Bob: Dead code is a good example of an architectural issue. You can’t analyze it just by looking at the source code. We define dead as code that is reachable but no longer used. We have found over the years that there are large swaths of obsolete or “zombie” code hidden in most monoliths. Something could call it, but nothing does. Maybe the service is now obsolete. It’s just sitting out there and not being used. 

Architectures drift over time, new features get added or maybe replaced, and older features are no longer used by customers and have been replaced. You’re carrying that technical debt forward. No one wants to touch it because maybe they weren’t there when it was written and don’t know what to do with it, or they fear if they touch it, there will be negative downstream effects.

Q: How is innovation impacted by technical debt?

Bob: Modernization requires funding, people resources, and time, diverting resources from other priorities, so you will have to build a business case and get approval. The question is, do you want to keep doing what you’re doing and add more and more features and ignore technical debt, or finally reduce that debt and start investing the savings in innovating for the future? 

Over time, there is a tipping point where all that technical debt weighs down the application and the organization to the point of breaking. The calculus here is that every dollar spent on technical debt is a dollar you aren’t spending on innovation. If you want to innovate more, you have to reduce your technical debt to get the ROI from modernization. 

Q: How does vFunction help increase innovation?

Bob: vFunction will measure and help you manage architectural technical debt and, then highlight the upside if you reduce it — how much ROI you’ll have in terms of innovation. This translates directly to dollars. In fact, this is one of the first factors we look at: how much architectural debt are you carrying, and how is it impacting your ability to innovate? Instead of theories and “gut feels,” we can give you numbers — here’s your ROI and TCO. Now, you have a business case that clearly illustrates to decision-makers that “if we want to increase business velocity, customer satisfaction, and innovation, this is how we have to apply our resources to bring down technical debt.”

Q: Tell me more about vFunction Assessment Hub and how it gathers and presents the data.

Bob: Our Assessment Hub analyzes technical debt based on two factors: complexity and risk. Then, those are synthesized into a technical debt score. 

Complexity is based on the degree of class entanglements within your application. It measures the density of the dependencies and how complex the application will be to modernize. 

Risk is based on the length of the dependency chains in the application. We measure the dependency chains, and how those interrelate downstream so you know that if you make one change here, what are the consequences down the line? This is the bane of the monolith — if you make one change, you have to test the whole thing. With microservices, you have a high degree of exclusivity of the resources you use, and they are constrained within the boundaries of the microservice. The risk of making a change is much lower. 

Q: How does that technical debt score inform decisions?

Bob: We set the technical debt score per application, and you can compare it with other applications. We also show how much effort it will take to fix it in terms of time and people. Architects can use that as a way to say, “Here is our technical debt and what it’s costing us. If we reduce the tech debt, here’s the innovation that occurs.” 

The Assessment Hub scores the top 10 technical debt classes and presents a prioritized list of where to start. For example, if you fix only these 10 things, we can say what effect that will have — the ROI. This kind of insight helps people understand not only a top-level debt score, but the components of complexity and risk, and then where to start. We also analyze the architecture to identify aging platforms and frameworks you will want to update. 

Q: What comes next once you understand the scope and magnitude of the modernization project?

Bob: Ideally, you would then jump into the vFunction Modernization Hub to do it. We’ve given you the path, now go at it with an AI-enabled approach.

The vFunction Assessment Hub Express is designed to be fast. You download and run it yourself from our website. We use this as part of our own analysis to help customers get started on modernization. It gives them a snapshot of what it will take. They can then say, “This will be a complex project or wow, this isn’t that hard, and we can do 100-200 classes ourselves.” Sometimes they don’t need full-blown modernization, or they can just lift and shift because they aren’t carrying much debt anyway. You have to make sure there are clear business reasons to modernize. 

Q: So, modernization isn’t always necessary? How do you know?

Bob: For an application to warrant modernizing, it needs to be an application that is actively used and critical to the business. If there’s a large backlog of features to add or requests to fix it, you know there’s a strong demand to extend or improve the application that isn’t being met. But if there’s no business reason to extend, there’s no business IP or competitive value, or if it can be easily replaced by a modern SaaS alternative, refactoring or rearchitecting may not be the best path.

Modernization is complicated, so you have to make sure there is a viable business reason to modernize. Only the business can understand and prioritize if it’s something they want and need to do.

Q: We assume modernization is to cloud-enable a legacy application. Is this true?

Bob: Partly. We are looking at more besides improving the architecture. One of the greatest motivators besides velocity, scalability and elasticity is reducing costs and increasing efficiency. When people move to the cloud, they’re also looking to lower infrastructure spend. Cloud services can be less expensive if you architect your application to use them more efficiently. 

But it’s also about reducing licensing costs. Legacy licensing for databases and Java itself is expensive. If you move an application to the cloud, like an enterprise monolithic application you’re still carrying significant licensing costs. Most customers want to reduce licensing costs across the board. So, the cost of running an expensive monolithic application and the related licensing costs are also common motivators to modernize. 

Q: Have vFunction users reduced costs this way?

Bob: Yes. If you look at our Trend Micro study, they took a monolith they lifted and shifted, modernized to microservices, and reduced their cloud instance spend by 50%. 

Legacy applications that are lifted and shifted to the cloud require some of the most expensive services in the cloud. If you’ve just taken an older app to the cloud, it’s running with high CPU and memory requirements, plus the most expensive data layer services as well. A lift and shift application has not been optimized for the cloud. In addition, a lift and shift doesn’t reduce licensing costs, combined with high infrastructure costs. Unless it’s cloud-native, you can’t take advantage of the efficiency of the cloud. Vertical scaling is very expensive. You will get more horizontal scalability and elasticity with microservices, and it is much more cost-effective.

Q: Last question. You mentioned the importance of presenting the data the Assessment Hub gives in a way that’s easy to understand. Can you explain how the Hub does that?

Bob: The Assessment Hub is graphical. You see a visualization of complexity, risk, debt (with a score), components of tech debt, and the number of aging frameworks. Then, you can analyze TCO, the benefits of fixing the identified debt, and the resulting increase in innovation. 

We present this in different ways on a dashboard. For example, there is a pie chart view of innovation versus technical debt. It graphically represents how much you’re spending on innovation versus technical debt, with percentages for added detail. You can ask, “What are the benefits if I fix this technical debt, and how much will my TCO improve?” You can also download this information as a shareable pdf.

If you’re not ready to modernize, you can let Assessment Hub run over time to monitor trends. Our latest feature is a multiple-application dashboard. It provides compelling observability across multiple apps at the same time to visualize technical debt for a large application estate so you can compare and prioritize. 

You can scope the project to know what you’re getting into and if it’s worth it. If an architect doesn’t have the data, they can’t have a viable, believable business plan. The goal is to get people thinking about this as early as possible.

Bob Quillin not only serves as Chief Ecosystem Officer at vFunction but works closely with customers helping enterprises accelerate their journey to the cloud faster, smarter, and at scale. His insights have helped dozens of companies successfully modernize their application architecture with a proven strategy and best practices. Learn more at vFunction.com. 

Related Posts:

• Q&A Series: Technical Debt Risk: A Look into SWA, the FAA and Twitter Outages
• Q&A Series: The 3 Layers of an Application: Which Layer Should I modernize first?