Category: Uncategorized

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?

Can technical debt cause business disasters? Just ask Southwest Airlines: their technical debt caused a shutdown during the 2022 Christmas season that cost the company more than $1 billion, not to mention the goodwill of irate customers who were stranded by the collapse of the carrier’s flight and crew scheduling system.

Or you could ask Elon Musk, whose new Twitter acquisition suffered its own chaos-inducing disruption in March of 2023 due to what one employee described as “so much tech debt from Twitter 1.0 that if you make a change right now, everything breaks.”

As these examples indicate, unaddressed technical debt can indeed pitchfork a company into a sudden and disastrous disruption of its entire operation. That’s why for many companies, addressing the technical debt carried by the mission-critical software applications they depend on is at the top of their IT priorities list.

But identifying and reducing technical debt can be difficult. And that’s especially true of architectural technical debt, which is often even harder to isolate and fix.

In this article, we’ll examine the challenges of architectural technical debt, and see how continuous modernization, along with the “shift left” approach to quality assurance (which helps minimize that debt by beginning QA evaluations early in the development process) can substantially reduce a company’s vulnerability to technical debt disasters.

What is Architectural Technical Debt?

The Journal of Systems and Software describes technical debt as “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.” Although the term has generally been applied to code, it also applies to architectural issues. The Carnegie Mellon Software Engineering Institute defines architectural technical debt similarly, in this way:

“Architectural technical debt is a design or construction approach that’s expedient in the short term, but that creates a technical context in which the same work requires architectural rework and costs more to do later than it would cost to do now.”

Architectural technical debt may be baked into an application’s design before coding even starts. A good example is the fact that most legacy Java apps are structured as monoliths, meaning that the codebase is organized as a single, non-modularized unit that has functional implementations and dependencies interwoven throughout.

Because the app’s components are all together in one place and communicate directly through function calls, this architecture may at first appear less complex than, for example, an architecture built around independent microservices that communicate more indirectly through APIs or protocols such as HTTPS.

Related: The Cost of Technical Debt and What It Can Mean for Your Business

But the tight coupling between functions in monolithic code imposes severe limitations on the flexibility, adaptability, and scalability of the app. Because functions are so interconnected, even a small change to a single function could have unintended consequences elsewhere in the code. That makes updating monolithic apps difficult, time-consuming, and risky since any change has the potential to cause the entire app to fail in unanticipated ways.

Challenges of Managing Architectural Technical Debt

Not only may initial design decisions insert architectural technical debt into apps up front, but changes that occur over time, through a process known as architectural technical drift, can be an even more insidious driver of technical debt.

Architectural technical drift occurs when, to meet immediate needs or perhaps because requirements have changed, developers modify the code in ways that deviate from the planned architecture. The result is that over time the codebase diverges more and more from the architectural design specification.

What makes such drift so dangerous is that while designed-in architectural debt can be identified by comparing the design specification against modern best practices, the ad hoc changes inserted along the way by developers are typically documented poorly—if at all. 

The result is that architects often have little visibility into the actual state of a legacy codebase since it no longer matches the architecture design specification. And that makes architectural technical debt very hard to identify and even harder to fix.

The problem is that while architects have a variety of tools for assessing code quality through, for example, static and dynamic analysis or measuring cyclomatic complexity (a metric that reveals how likely the code is to contain errors, and how hard it will be to test, troubleshoot, and maintain), they haven’t had comparable tools for assessing how an app’s architecture is evolving or drifting over time.

Why Measuring and Addressing Architectural Technical Debt is Critical

While code quality and complexity are key application health issues, architectural technical debt is an even higher level concern because unaddressed architectural deficiencies can make it very difficult, or even impossible, to upgrade apps to keep pace with the rapidly evolving requirements that define today’s cloud-centric technological environment.

For example, the monolithic architecture that characterizes most legacy Java codebases is notorious for having ingrained and intractable technical debt that imposes severe limitations on the maintainability, adaptability, and scalability of such apps.

But given the difficulty of detecting and measuring architectural technical debt, how can architects effectively address it to prevent it from eventually causing serious issues? As management guru Peter Drucker famously said, “You can’t improve what you don’t measure.”

The answer is by following a “shift left” QA strategy based on use of the advanced AI-based tools now available for detecting, measuring, monitoring, and remediating architectural debt and drift issues before they cause technical debt meltdowns.

Shifting Left to Address Architectural Technical Debt

In the traditional waterfall approach to software development, operational testing of apps comes near the end of the development cycle, usually as the last step before deployment. But architectural issues that come to light at that late stage are extremely difficult and costly to fix, and may significantly delay deployment of the app. The shift left approach originally aimed to alleviate that problem.

In essence, shift left moved QA toward the start of the development cycle—the technique gets its name from the fact that diagrams of the software development sequence typically place the initial phase on the left with succeeding phases added on the right. Ideally, the process begins, before any code is written, by assessing the architectural design to ensure it aligns with functional specifications and customer requirements.

Shift left is a fundamental element of Agile methodology, which emphasizes developing, testing, and delivering working software in small increments. Because the code delivered with each Agile iteration must function correctly, shift left testing allows verification of the design and performance of components such as APIs, containers, and microservices under realistic runtime conditions at each step of the development process.

In this context, shifting left for architecture gives senior engineers and architects visibility into architectural drift throughout the application lifecycle. It makes modernization a closed-loop process where architecture debt is always being proactively observed, tracked, baselined, and where anomalies are detected early enough to avoid disasters.

That’s especially beneficial for modernization efforts in which legacy apps are refactored from monoliths to a cloud-native microservices architecture. Since microservices are designed to function independently of one another, the shift left approach helps to ensure that all services integrate smoothly into the overall architecture and that any functional incompatibilities or communications issues are identified and addressed as soon as they appear.

The Importance of Continuous Modernization

One of the greatest benefits of legacy app modernization is that it substantially reduces technical debt. This is especially the case with monolithic apps—the process of refactoring them to a microservices architecture automatically eliminates most (though not necessarily all) of their technical debt.

But modernization isn’t a one-time process. Because of the rapid advances in technology and the quickly evolving competitive demands that characterize today’s business environment, from the moment an app is deployed it begins to fall behind the requirements curve and become out of date.

Plus, the urgency of those new requirements can put immense pressure on development and maintenance teams to get their products deployed as quickly as possible. That, in turn, often leads them to make “sub-optimal design or implementation solutions that yield a benefit in the short term.” And that, by definition, adds technical debt to even newly designed or modernized apps.

As a result, the technical debt of any app will inevitably increase over time. That’s not necessarily bad; it’s what you do about that accumulating debt that counts. Ward Cunningham, who coined the term “technical debt” in 1992, puts it this way:

“A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid.”

That’s why continuous modernization is so critical. Without it, the technical debt carried by your company’s application portfolio is never repaid and will continue to increase until a business disaster of some kind becomes inevitable. As a recent Gartner report declares:

“Applications and software engineering leaders must create a continuous modernization culture. Every product or platform team must manage their technical debt, develop a modernization strategy and continuously modernize their products and platforms… Teams must ensure that they don’t fall victim to “drift” over time.”

Related: The Top 5 Reasons Technical Debt Accumulates in Your Business Applications

The Key to Continuous Modernization

Until recently, it’s been difficult for software development and engineering leaders to establish a culture of continuous modernization because they lacked the specialized tools needed for observing, tracking, and managing technical debt in general—and architectural technical debt in particular. But the recent advent of AI-based tools specially designed for that process has been a game changer. They enable software teams to identify architectural issues, understand their complexity, predict how much time and engineering effort will be required to fix them, and actually lead the team through the refactoring process.

The vFunction Continuous Modernization Manager enables architects to apply the shift left principle throughout the software development lifecycle to continuously identify, monitor, manage, and fix architectural technical debt problems. In particular, it enables users to pinpoint architectural technical drift issues and remediate them before they contribute to some future technical debt catastrophe.

If you’d like to know more about how an advanced continuous modernization tool can help your company avoid technical debt disasters, contact us today.

In 2021, the Standish Group published a report on the effectiveness of different approaches to software modernization. The report looked at the efficacy of replacing legacy solutions with entirely new code or using existing components as a basis for modernization. The authors also identified an approach they called “Infinite Flow,” where modernization was a continuous process and not a project with a start and end date.

The Standish Group’s definition of infinite flow mimics that of continuous modernization (CM). CM is a continuous process of delivering software updates incrementally. It allows developers to replace legacy software iteratively with less user disruption. Both definitions focus on the ongoing nature of software delivery and its organizational impact.

According to their analysis, the report authors determined that continuous flow processes deliver more value than other methodologies, such as agile or waterfall. They calculated that waterfall projects are 80% overhead and only return a net value of 20%. In contrast, continuous modernization operates with 20% overhead and delivers an 80% net value. They also calculated that 60% of customers were disappointed in the software delivered at the end of a large development effort. In comparison, only 8% of customers felt the same with continuous development processes.

If continuous modernization delivers a more significant net value and increases customer satisfaction, why aren’t more organizations using the methodology as they replace legacy systems? Let’s take a closer look at this strategy to determine why more companies don’t realize the benefits of CM.

What is Continuous Modernization?

The Information Systems Audit and Control Association (ISACA) defines continuous modernization as a strategy to evolve an existing architecture continuously and incorporate emerging technologies in the core business operating model. With CM, organizations develop solutions in increments that encourage frequent releases where the software is monitored and refined, feeding back into the development cycle. 

The approach allows companies to gradually replace aging technologies that pose business risks. It enables businesses to add features and functionality to existing systems without disrupting operations. However, CM is more than a development strategy. It is a mindset.

Traditional software development is project-based. A scope of work is defined with a start and end date. It doesn’t matter if the development method is waterfall or agile. Cumulative software updates are released on a pre-defined date. After installation, bugs may be identified and fixed. Some flaws are added to the scope of work for the next release.

With CM, on the other hand, software development becomes part of a continuous improvement mindset where each iteration enhances the existing software. New software is deployed monthly, weekly, or daily. Unlike project-based development, changes are not withheld until a project scope has been completed. The steady stream of updates requires a cultural shift.

Related: Navigating the Cultural Change of Modernization

Key performance indicators (KPIs) for software development and measurement methods no longer apply. Testing procedures are automated to keep pace with incremental software releases. End users see small changes in the user interface or functionality instead of massive changes delivered simultaneously. If organizations are to realize the following benefits of CM, they need to address the cultural changes necessary to support a continuous improvement model.

What Are the Benefits of CM?

The 2021 Standish authors indicated that the flow-like modernization methodology had the following benefits:

• Modernization using a series of microprojects had better outcomes than a single large project.
• Microprojects achieved greater customer satisfaction because of built-in feedback loops.
• Microprojects delivered a higher return of value.
• Modernization using continuous improvement reduced risk and monetary loss.
• Continuous modernization has a higher degree of sustainable innovation.
• Continuous modernization increases application life.

Outcomes were evaluated in terms of time, budget, and customer satisfaction. In general, smaller projects in a continuous improvement model delivered better outcomes than more traditional large projects, especially in the areas of customer satisfaction, net value, and financial loss.

Increased Customer Satisfaction

Continuous modernization is less disruptive to operations. When large projects are delivered, it often results in downtime. Even if the software is installed after hours, the massive changes usually require user training. Struggling to learn the software while performing their job frustrates employees. 

Since most large projects do not solicit extensive user input during development, the updated features may not operate as users expected. Customers become disgruntled when they are told the feature operates as designed, so it isn’t a bug and won’t be addressed until the next release.

With microprojects, small changes are made incrementally with minimal impact on user operations. Employees aren’t trying to learn new functionalities while performing their job. Soliciting feedback from users as changes are deployed means modifications can be incorporated into the iterative process.

Reduced Risk

Old code is risky code. Who knows what is lurking in those undocumented modules? Depending on the age of the software, everyone associated with the original project may have left the company. Suddenly organizations are faced with a knowledge deficit. How can they support the software if no one understands the code?

Twitter is an excellent example of the impact technical debt and knowledge deficit can have on a company. Long before Elon Musk took over Twitter, employees complained that parts of the application were too brittle. Some even suggested that the technical debt was too extensive, requiring a complete rewrite. Then, Musk began his widespread staff reduction. As a result, fewer employees were available to keep brittle code functional.

In March 2023, Twitter had an operational failure. Users were unable to open links. The API that allowed the data interchange was not working. After service was restored, the source of the failure was found to be an employee error. The one engineer assigned to the API made an incorrect configuration change. Removing old code reduces the risk of a disastrous outcome from a simple configuration change. 

Reduced Technical Debt

Technical debt is no different than financial debt. At some point, it must be repaid. If it goes untouched, it only accumulates until an organization is no longer viable. A recent survey found that technical debt inhibits 70% of a company’s ability to innovate. 

CM allows developers to gradually replace legacy code that contributes to technical debt. It also keeps the debt from growing. For example, companies that release software updates once a year accumulate debt while they are writing new code. Given the exponential rate of digital adoption, the technical deficit can easily double in a year.

Following a continuous modernization approach, developers are consistently replacing older code. Because the incremental updates require less test time, new code can be delivered faster. Changes in methodology or coding standards can be incorporated into the cycling development list to minimize the amount of added technical debt.

Limited Monetary Loss

Continuous modernization incorporates user feedback into the development process. With feedback, developers can adjust the software to better reflect user needs. This process minimizes monetary loss that can result from a comprehensive software update.

Large development projects that follow the traditional management path consume significant resources before the end user sees the software. If the final product does not meet expectations, companies run the risk of bringing a product to market that lacks key features. Costs for reworking the software are added to the original expenditures. Businesses can find themselves selling solutions at a loss if the market will not support a price increase.

Related: How Opportunity Costs Can Reshape Measuring Technical Debt

With large projects, the opportunity costs can be significant if resources are tied up reworking software after delivery. Instead of pursuing an innovative solution, developers are occupied with existing development. Iterative development allows for immediate feedback so course corrections can occur early in the development process. If the product fails to meet market expectations, organizations can terminate the effort before incurring significant losses.

Sustained Innovation

Adopting a continuous improvement mindset allows developers and architects to implement a continuous modernization methodology for software development. The process enables programmers, DevOps, and engineers to deliver innovative solutions as part of their workday.

The iterative approach lets developers test innovative solutions as early in the process as possible and receive user feedback to ensure acceptance. Freed from reworking existing code and compensating for technical debt, development staff can spend more time exploring opportunities.

Limiting financial loss and reducing risk from outdated code provide businesses with added resources to investigate new markets. With a cost-effective methodology for modernization, organizations can deliver innovative solutions that consistently meet customer expectations.

Realize the Benefits of Continuous Modernization

To realize the benefits of continuous modernization, businesses must establish and measure KPIs. They must look for tools that can refactor applications and assess technical debt. 

vFunction’s Assessment Hub analyzes applications, identifies technical debt, and calculates its impact. The Modernization Hub helps architects transform monoliths into microservices. The newly released Continuous Modernization Manager lets architects shift left and address issues that could impede ongoing modernization. To see how we can help with your modernization project, request a demo today.