Category: Uncategorized

For companies that depend on legacy applications for critical business processing, modernizing those apps to make them compatible with today’s technologically sophisticated cloud ecosystem is crucial. But because most legacy apps are monolithic, updating them can be a difficult, time-consuming, and risky process. 

A monolithic codebase is organized as a single unit that has function implementations and dependencies interwoven throughout. Because a change to one part of the code can generate unexpected side-effects in other parts of the codebase, any update has the potential to cause the app to fail in unpredictable ways.

Yet, if these legacy apps are to continue fulfilling their business-critical missions, they must have the flexibility and adaptability necessary for keeping pace with the ever-evolving requirements of a fast-changing marketplace and technological environment. What’s needed is a means of encapsulating any changes to the legacy code so that only the targeted function is affected.

The Strangler Fig Architecture pattern meets that need. It allows legacy apps to be safely updated by replacing each function with an independent microservice. This enables developers to incrementally modernize specific functions without impacting the operation of other portions of the app.

What is the Strangler Fig Pattern?

Martin Fowler, Chief Scientist at Thoughtworks, coined the term in 2004. He noticed that strangler fig seeds, which germinate in the upper branches of other trees, send down roots that surround and eventually strangle their host tree. In effect, the strangler fig kills the original tree and takes its place.

Fowler saw this as a metaphor for how a large, monolithic software application could be modernized by surrounding it with a new superstructure of microservices that, over time, strangles and replaces the original app. A microservice is a small, self-contained codebase that performs only one task and replaces a single function or service in the legacy app. It can be updated without affecting other parts of the app. 

As new microservices are added over time, they take over the functions of the original codebase one by one until the functionality of the legacy app is entirely replaced by microservices. At that point, the original app has been fully “strangled” and can be decommissioned.

Related: Migrating Monolithic Applications to Microservices Architecture

Why the Strangler Fig Pattern is Ideal for Application Modernization

Faced with the daunting prospect of replacing or rewriting their portfolio of legacy apps, some companies settle for simply migrating them, pretty much as-is, to the cloud. But though that approach may yield some benefits, it falls far short of true modernization. That’s because a monolithic codebase in the cloud is still monolithic, and retains all the detrimental characteristics of that architecture.

The Strangler Fig Pattern enables true legacy app modernization by allowing you to replace the functions of the original app one at a time without having to rewrite the entire app all at once. As key functions are re-implemented one by one as microservices, the app continues to function and can be fully transformed without ever going offline.

A key element of the strangler paradigm is the use of an interface layer, called a façade, between the original app and its microservices superstructure. All communications to and from the legacy app go through the façade, which includes feature flags that you can set to dynamically control whether the original code for a function or its microservice replacement is live.

This approach provides some major advantages:

1. Allows incremental updating

If you elect to entirely rewrite a legacy app, you can’t use the new system until the rewrite (and all testing) is complete. The strangler approach allows you to incrementally add features and capabilities without disrupting the operation of the app or taking it offline.

2. Enables quicker modernization

As each new microservice is added, the benefits it provides, such as increased adaptability, flexibility, scalability, and performance, take effect immediately. As IBM notes,

The great thing about applying this pattern is that it creates incremental value in a much faster timeframe than if you tried a “big bang” migration in which you update all the code of your application before you release any of the new functionality.

3. Minimizes risk

Any attempt to replace or upgrade a large monolithic app all at once will almost certainly introduce new bugs that can cause significant downtime once you bring the new codebase online. But, as Bob Reselman of Red Hat explains,

“Small failures are easier to remedy than large ones, hence the essential benefit of the Strangler pattern.”

Because the strangler approach incorporates changes in small steps, with each new microservice being thoroughly tested before going live with the app, downtime due to new bugs can be almost totally eliminated.

4. Allows you to choose the pace of modernization

Since the app is never taken offline, you can implement the modernization project at a pace that’s comfortable for your team (and budget).

5. Allows easy and seamless rollbacks

Rolling back a change that isn’t working correctly is easy. Each new microservice deployment can be quickly and cleanly reversed simply by setting feature flags appropriately.

6. Eliminates the need to maintain two separate codebases

New functions are implemented as microservices that surround the legacy codebase; the original app is never changed. Since any needed changes (including those that correct bugs in the legacy code) are made only to the microservices superstructure, the original codebase need not be separately maintained.

7. Enhances QA

Because microservices can be run in parallel with the original code for QA purposes, each change can be comprehensively tested in the app’s production environment before it goes live with the app.

How Refactoring With Strangler Fig Helps You Avoid Destructive Coding Anti-Patterns

As we’ve seen, the Strangler Fig Pattern provides an ideal template for modernizing legacy apps. However, some other widely used software design patterns yield far more negative results. These are called, appropriately, anti-patterns. Martin Fowler notes that the term was coined in 1995 by programmer Andrew Koenig, who described it this way:

“An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn’t one.”

According to Fowler, anti-patterns are extraordinarily dangerous because they initially fool developers into thinking they are appropriate solutions to common software coding problems, only to reveal their detrimental consequences later when the damage has been done. As software engineer Kealan Parr declares:

“In software, anti-pattern is a term that describes how NOT to solve recurring problems in your code. Anti-patterns are considered bad software design… They generally also add “technical debt” – which is code you have to come back and fix properly later.”

Parr lists some of the more common anti-patterns. They include:

Spaghetti Code

This anti-pattern is often encountered in monolithic legacy apps. The term describes a codebase that has little or no structure. There’s no modularization, and function implementations and dependencies are intermingled throughout the code, just like strands of spaghetti on a plate. As a result, the logical flow of the application is extremely difficult to understand. Parr calls it a maintenance nightmare:

“You will constantly break things, not understand the scope of your changes, or give any accurate estimates for your work as it’s impossible to foresee the countless issues that crop up when doing such archaeology/guesswork.”

Because of these characteristics, updating or adding features to spaghetti code is an extraordinarily difficult and risky process.

Golden Hammer

This anti-pattern derives its name from a quote attributed to Abraham Maslow:

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

That’s a human tendency to which software developers are as prone as anyone else. When they have a high level of competence with, love for, or comfort with particular coding tools, languages, or architectures, they naturally seek to apply them across the board, even in situations where they are not the best options. The result can be highly detrimental—as Parr says, “Your whole program could end up taking a serious performance hit because you are trying to ram a square into a circle shape.”

Boat Anchor

Boat anchors do nothing but retard the progress of the vessel to which they are attached. And that’s exactly what the boat anchor anti-pattern does with software. The term describes code modules that developers insert into the codebase to implement functions not currently needed or used. They do so because they think those functions might be needed later.

This too, says Parr, is a maintenance nightmare. Developers who are new to the codebase, or who have not worked with it for some time, will have a hard time identifying boat anchor modules and figuring out whether they impact the logical flow of the program or are entirely superfluous. There’s a real possibility of your developers spending significant amounts of time and effort on understanding and debugging modules that literally do nothing.

Dead Code

This term describes code that, unlike boat anchors, implements functions that are not only used in the application but which may be called frequently from many different places in the codebase.

The problem is that it’s not clear what this code is doing or why it’s needed. Perhaps it had an important function at some point, but now the issues it was created to solve no longer exist. On the other hand, it could be crucial for handling infrequent edge or boundary conditions that current developers haven’t yet run into but eventually will. Because you can’t be sure why it’s there, you don’t dare to remove it. So, it remains in the codebase as a time-waster and generator of confusion for the developers who have to deal with it.

Proliferation of Code

This anti-pattern occurs when there are objects in the code that seem to exist only to invoke other more strategic objects. These are essentially useless “middleman” objects that provide no additional value, but only add an unnecessary level of abstraction, and therefore confusion, to the code. Such objects should be bypassed and removed to make the code more easily understandable.

God Object

This is sometimes called the “Swiss Army Knife” anti-pattern. It describes objects that are accessed by many other objects in the codebase for a multitude of different and often unrelated purposes. Such objects are problematic because they violate the Single Responsibility principle of coding, which says that every class, module, or function should do only one thing. According to software architect Thanh Le, they are “hard to unit test, debug and document” and can be a “maintenance nightmare.”

Strangler Fig to the Rescue!

Refactoring a legacy app according to the Strangler Fig Pattern will remove anti-patterns such as these from the codebase almost automatically. For example, Strangler Fig refactoring eliminates spaghetti code by re-implementing legacy app functions as a set of independent, single-task microservices that can be easily understood, maintained, and upgraded. 

Similarly, code that does too much is replaced by individual microservices with precisely specified, single-purpose functionality, while unneeded modules are not re-implemented at all. And Golden Hammer technology choices can be eliminated by implementing new microservices using a carefully chosen modern technology stack.

Best Practices to Implement the Strangler Fig Pattern

How can you maximize the benefits of the strangler fig paradigm in modernizing your legacy apps? Here are some best practices:

1. Automate the process using an AI-based modernization platform

As industry insider Oliver White has said,

“Large monolithic applications need an automated, data-driven way to identify potential service boundaries.”

Manual analysis of a monolithic codebase with millions of lines of code is a time-consuming, error-prone process. An automated, AI-based analysis platform can perform that task quickly, comprehensively, and at scale. Using static and dynamic analyses, it can assess the monolithic codebase for technical debt, complexity, and risk; reveal functional flows and dependencies; identify service domain boundaries; and quantify the amount of effort that will be needed to refactor the app.

That information will allow you to determine:

• the negative impact of your legacy apps’ technical debt on your ability to innovate
• the ROI that can be realized from modernizing some or all of your legacy apps
• which applications should be modernized and in what order
• which legacy app services should be re-implemented as microservices and which should not
• the functional scope of each microservice
• which functions are so similar or overlapping that they can be consolidated into a single microservice

Once the analysis phase is complete, a state-of-the-art modernization platform will be able to substantially automate the process of refactoring the monolithic code into microservices.

2. Pick the right starting point

For most companies, it’s not feasible—nor desirable—to modernize all their legacy apps at once. Instead, it’s best to start with those apps that have the greatest business value and which also have a high degree of technical debt. Then, for each app choose functions that have the highest impact on your business operations as the first to be re-implemented as microservices.

3. Pick the right ending point

It’s natural to want to replace all your legacy apps with microservices. But the costs of refactoring an entire legacy suite may exceed the benefits. In such cases, it might be best to continue using the original app for specific functions that are isolated, stable, and don’t require upgrading, while re-implementing as microservices any functions that must be easily upgradeable, or that interact directly with other systems or resources.

4. Follow an incremental, step-by-step process

The Strangler Fig Pattern provides its greatest benefits when it is applied incrementally, one microservice at a time. Avoid trying to modernize entire apps all at once. As one research paper succinctly advises:

“Start small and gradually evolve the system (baby steps).”

5. Implement new functionality only in microservices

When you begin the modernization process, you should freeze the legacy codebase and implement any new functionalities only through microservices. If you continue to make updates to the original app, you create two simultaneously evolving codebases, both of which must be supported, tested, and synchronized.

Related: Simplify Refactoring Monoliths to Microservices with AWS and vFunction

How AWS Migration Hub Refactor Spaces and vFunction Work Together

As an AWS Partner, vFunction provides an automated, AI-driven modernization platform that closely integrates with AWS Migration Hub Refactor Spaces to enable developers to quickly and safely transform complex monolithic Java applications into microservices and deploy them into AWS environments.

Refactor Spaces establishes, maintains, and manages the modernization environment, and orchestrates AWS services across accounts to facilitate the refactoring of legacy apps from monoliths to microservices. Refactor Spaces implements the Strangler Fig Pattern for the target application and allows developers to easily manage communication between services throughout the environment.

Developers begin the refactoring process by using vFunction to generate an automated, AI-based analysis that quantifies the complexity of monolithic legacy apps. Using both static and dynamic analyses, vFunction provides the detailed information regarding technical debt, complexity, and risk that’s required for developing a comprehensive refactoring plan that prioritizes which apps and services will be converted and in what order.

vFunction then automatically decomposes the monolithic apps into microservices. Using sophisticated, AI-driven static analysis, the vFunction platform analyzes architectural flows, classes, usage, memory, and resources to detect and expose critical business domain functions buried in the code and untangle complex dependency relationships.

See vFunction For Yourself

The vFunction platform is unique in its ability to make refactoring monolithic legacy apps into microservices as quick, easy, painless, and safe as possible. It easily handles codebases with tens of millions of lines of code, and can accelerate the modernization process by at least a factor of 15. If you’d like to see for yourself what it can do, please schedule a demo today.

For many companies today, modernizing their legacy apps is a top priority. They recognize that although those apps are critical to their business operations, they’re also major hindrances to the organization’s ability to keep pace in its marketplace. 

That’s because legacy apps, which are typically structured as monolithic architectures, are very difficult to update to meet the rapidly changing market and technological demands that characterize today’s commercial landscape.

In response to that challenge, companies are mounting projects to modernize their legacy software. But modernizing a suite of legacy apps is not a quick and easy process, and finding workers with the requisite skills and expertise to staff such projects can be difficult. 

In fact, two recent surveys found that a shortfall of skills and expertise was one of the top reasons why application modernization had failed at their organization. What are the skills required for building an effective app modernization team? To answer that question, let’s start by looking at the application modernization process.

What Application Modernization is Really All About

The goal of application modernization is to restructure a monolithic legacy app from an isolated, stand-alone codebase that doesn’t interact easily, if at all, with the modern cloud-centric ecosystem, into a microservices architecture that is cloud-native in its capabilities. How is that restructuring accomplished? A report from Capgemini describes the process this way:

Modernizing means transforming existing software, taking an agile approach to development across people, processes, and technology, and embracing cloud-native development, including microservices and containerization, hybrid cloud- integration, and agile and DevOps methodologies.

The key phrase in this description is “taking an agile approach to development across people, processes, and technology.” A legacy app modernization team should be organized according to the Agile/DevOps methodology that characterizes the modern approach to software development.

Deciding Your App Modernization Objective

Application modernization involves refactoring or rearchitecting the monolith into a set of small, autonomous microservices.

Companies have sometimes attempted to gain the benefits of modernization by simply migrating their legacy apps, with minimal changes, to the cloud. That approach is simply migration not modernization and has proven to be ineffective: as a report from Google explains,

“Although CIOs have successfully migrated some applications to the cloud, according to a McKinsey study, around 80 percent of them report that they have not achieved the agility or business outcomes they sought from application modernization.”

Migrating an app to the cloud can, by itself, provide some benefits, such as DevOps improvements in deployability and security along with shutting down data center resources. The problem is that the migrated monolithic application remains monolithic and continues to suffer from all the deficiencies of that architecture. Migration alone achieves little in terms of achieving cloud benefits such as increased scalability, development velocity, and reduced technical debt.

That’s why full modernization is accomplished by refactoring the app into microservices. The app is thereby transformed into a cloud-native architecture that’s easy to update and that can integrate with and take full advantage of the technologically advanced resources available in the cloud.

Related: Cloud Modernization Approaches: Rehost, Replatform, or Refactor?

App Modernization Team Requirements

The fact that microservices are designed to operate independently of one another has a major impact on how application modernization teams are structured. That’s because of Conway’s Law, which was first articulated by software expert Melvin Conway in 1967:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

The implication of Conway’s Law for app modernization is that an organization that aims at producing small, autonomous, independent microservices ought to be structured as small, autonomous, independent teams. 

If the organization adopts a different structure (like, for example, the large integrated teams normally used with monolithic apps), the product they produce will reflect the way the team is organized, whatever the intent for that product may have been. As software engineer Alex Kondov emphatically warns,

“You can’t fight Conway’s Law… Time and time again, when a company decides that it doesn’t apply to them they learn a hard lesson… If the company’s structure doesn’t change the software will slowly evolve into something that mirrors it.”

Domain-Driven Design (DDD) in App Modernization

Application modernization teams formed in compliance with Conway’s Law will each take full ownership of one or more microservices. But what should be the scope of each of those microservices, and therefore of the team that supports it? Tomas Fernandez of Semaphore provides a useful answer to that question:

“Domain-Driven Development allows us to plan a microservice architecture by decomposing the larger system into self-contained units, understanding the responsibilities of each, and identifying their relationships.”

DDD helps you to identify the functional domains and subdomains in a monolithic codebase and draw boundaries around each function that will be implemented as a microservice. It also allows you to employ key modernization best practices such as the Strangler Fig Pattern to carefully shut off old functions and domains in the monolith as new microservices replace them.

Related: Organizing and Managing Remote Dev Teams for Application Modernization

Key Roles in Modernization

Jason Smith, Chief User Experience Officer at dotCMS observes that,

“Agile Development, which some refer to as ‘DevOps’, means having a number of small teams working on individual, smaller projects so that those projects are able to get a team’s undivided attention. This enables the individual projects to be completed quicker. Microservice architecture fits into this development model perfectly, as each small team can own and focus on one service.”

Because the process of restructuring a monolithic codebase into microservices fits “perfectly” into the Agile model, we’ll look to that model to identify the roles you’ll need to fill for your app modernization dream team.

1. Corporate leadership – May include an Executive Sponsor who will provide both the budget and overall guidance for the project, as well as other leaders such as the CIO.
2. Product Owner – Sets requirements for the project from the viewpoint of the customer. This role, which typically is filled in-house, assigns team roles and tasks and takes full responsibility for the success of the project.
3. Project Manager – Responsible for the day-to-day operation of teams. Provides leadership for team members, defines goals, oversees progress, and ensures that budget and schedule milestones are met.
4. Modernization Architect – Translates business requirements into technical deliverables. Responsible for defining the microservice architecture the team will implement and for ensuring effective integration of the modernized app into the cloud environment.
5. Legacy App Expert – Has the skills needed to analyze the app to understand its functionality and the internal and external dependencies that must be accounted for when it is restructured into microservices.
6. Senior Developers – Individuals who have the normal range of software development skills that allow them to function as, for example, front-end or back-end developers or UI/UX designers.
7. QA Engineer – Responsible for defining comprehensive test coverage to ensure that each microservice and the restructured app as a whole function as intended.

Each microservice team won’t necessarily have all of these roles—some, such as corporate leaders or developers who analyze legacy apps, may work with several or all of the teams. Also, on small microservice teams, several roles may be filled by one person.

How Do You Find the Talent You Need?

The first question is, to what degree can you tap into your existing staff to fill the roles required for your modernization project? To answer that question, you’ll need to assess what skillsets are available in-house and whether any that are lacking can be supplied through training.

If you do have to go outside to find the skills or expertise you need, be prepared to face some challenges. The U.S. is currently experiencing a shortage of more than a million software developers, and even if you can find them, they’re hard to keep. One recruiter, DaedTech founder Erik Dietrich, declares that,

“The only way to find software developers is to go prying them loose from other firms.”

And there’s an additional challenge when you’re staffing an app modernization project: many developers just don’t want to work on legacy code. According to one survey, 78% of developers say that “Spending too much time on legacy systems” has a “negative impact” on their personal morale.

Automation Can Minimize Your Need to Hire

Legacy monoliths may contain tens of millions of lines of code and thousands of classes. Having developers manually conduct the comprehensive static and dynamic analyses necessary to uncover all of the app’s functions and dependencies can be extremely time-consuming, error-prone, costly, and from the developer’s point of view, boring. And the process of decomposing the codebase into services and reimplementing them as microservices is similarly fraught.

But an AI-enabled, automated modernization platform can perform those chores accurately and comprehensively in a fraction of the time a human would require. With that kind of assistance, not only will you need fewer new hires for your modernization efforts, but you’ll also boost the morale of your existing workers by releasing them to spend more of their time on exciting innovations rather than on decidedly unexciting legacy code.

The vFunction platform employs sophisticated AI capabilities to quickly and comprehensively analyze complex monolithic applications to uncover hidden functionalities and dependencies. Plus, it can automate about 90% of the process of restructuring a monolithic codebase into microservices.

To see first-hand how vFunction can help you build an effective modernization team while minimizing the need to hire new development talent, request a demo.

Companies today must be highly agile to meet ever-evolving marketplace demands. But the legacy applications many still depend on for much of their business-critical processing are ill-equipped to support that kind of agility. That’s why identifying and overcoming app modernization challenges is critically important.

The Consortium For Information & Software Quality (CISQ) highlights the necessity for app modernization in this way:

After decades of operation, they [legacy apps] may have become less efficient, less secure, unstable, incompatible with newer technologies and systems, and more difficult to support due to loss of knowledge and/or increased complexity or loss of vendor support. In many cases, they represent a single point of failure risk to the business.

CISQ notes that companies now spend 75% of their IT budgets on their legacy systems. That’s money that’s not being spent to provide the innovations that are critical for success in today’s market environment.

For that reason, modernizing legacy systems and applications so that they can fully participate in today’s cloud-centric ecosystem is critically important. Yet according to a 2022 survey of senior IT professionals, 79% of app modernization efforts fail, and those failures represent an enormous waste of time and resources. In this article, we want to examine the particular app modernization challenges that may give CIOs sleepless nights as they contemplate upgrading their legacy applications.

Why Overcoming App Modernization Challenges is Critical

More than half (56%) of the respondents to a survey of corporate CIOs say that their legacy applications are significant obstacles to their efforts toward digital transformation. But because those applications still perform functions that are critical for day-to-day business operations, they can’t simply be eliminated.

Rather, to gain the technological agility that’s necessary for meeting ever-changing marketplace demands, companies must find ways to integrate their legacy apps into today’s cloud-centric ecosystem.

That’s what application modernization is all about. Industry analyst David Weldon puts it this way:

“Application modernization is the process of taking old applications and the platforms they run on and making them “new” again by replacing or updating each with modern features and capabilities that better align with current business needs.”

When done well, application modernization not only provides the flexibility and agility that enables companies to react quickly to changing marketplace conditions, but it also yields better application performance, increased efficiency for developers, and reduced overall costs.

Challenges of Application Modernization

The app modernization challenges most likely to keep CIOs awake at night fall into three major categories: costs, time, and risk. Let’s take a closer look at each.

1. Costs

There’s no question that any significant legacy app modernization effort will require a substantial investment of both money and time. According to one survey, the average application modernization project costs $1.5 million and takes 16 months–and still, 79% of these initiatives fail.

Obtaining the necessary budget commitment is often the biggest obstacle CIOs face in initiating a legacy app modernization project. That’s especially the case when a company’s legacy apps seem to still be functioning as intended and providing value to the organization. That perception may cause senior management to take an attitude of “if it ain’t broke, we can’t afford to fix it.”

Yet, the risks and costs of doing nothing are substantial. Using a standardized metric it calls the Cost of Poor Software Quality, CISQ calculated that in 2020 it cost businesses $520 billion to maintain legacy software.

In addition, as the technological context for which they were designed recedes further and further into the past, legacy apps become more brittle (easily breakable) and may constitute, as CISQ notes, a “single point of failure risk” that could trigger huge unexpected costs if a breakdown should occur.

How can a CIO deal with the inevitable budget limitations that could seriously curtail any effort at legacy app modernization? First, costs must be contained; second, senior management must be shown the positive ROI that legacy app modernization can yield.

Containing Legacy App Modernization Costs

Legacy application modernization, which normally involves refactoring monolithic legacy codebases to convert them to a cloud-native microservices architecture, requires a high level of expertise within the development team. Not only must developers understand the legacy app itself (and its technological framework), but they must also be skilled in navigating the open-source environment of the cloud.

That presents a two-fold problem. First, the developers who were most familiar with the legacy app are usually no longer available, and finding equally knowledgeable replacements is nearly impossible. Second, while developers who are at home with cloud technologies are available, they come at a cost that is often beyond what companies can pay to staff a modernization project.

The answer is to not try to do everything yourself. Instead, you’ll want to work with partners that already have the skills and experience required for efficiently modernizing monolithic codebases.

Related: The CIO Guide to Modernizing Monolithic Applications

Making the ROI Case for Legacy App Modernization

Getting the budget commitments needed for an app modernization effort requires getting buy-in from the executive team. You’ll need to present quantitative information that establishes the ROI that can be expected from such a project. That data can be acquired by use of an AI-enabled automated tool that can help you assess the technical effort required, the associated costs, and the savings that will ultimately be gained.

2. Time

Refactoring legacy apps to give them an essentially cloud-native architecture is a highly complex task. A monolithic codebase is basically a single unit that has function implementations and dependencies woven throughout the code in non-obvious ways.

Manually unraveling millions of lines of code to expose those functions and dependencies requires both a high degree of technical expertise and the investment of many months or even years of developers’ time. A report by McKinsey quotes one IT leader as saying,

“We were surprised by the hidden complexity, dependencies and hard-coding of legacy applications, and slow migration speed.”

But the key word in this scenario is “manually.” The degree of complexity, and the time required to manage it, can be substantially reduced by employing the kind of AI-enabled, automated analysis tool we mentioned before. The use of such a tool can allow developers to accomplish in just weeks what would take many months if done manually.

3. Risk

Perhaps the scariest of the app modernization challenges that may keep a CIO up at night is the potential that after a significant investment of time and money, the project might fail to deliver the expected benefits. Even worse is the risk that faults might be inserted into a business-critical legacy app, causing significant disruptions to company operations.

Those risks are real. As we’ve seen, almost 80% of legacy app modernization efforts end in failure. And there are risk factors inherent in the process of refactoring monolithic codebases into microservices that can rarely be avoided.

For example, there’s often a knowledge gap caused by the fact that the original developers of a legacy app are no longer available, and written documentation is often incomplete or outdated. In its many years of service, legacy code will usually have been modified, adapted, and patched to meet specific needs of the moment, but such changes are rarely adequately documented. As a result, developers engaged in a modernization effort might overlook important functions that are hidden in the code.

Minimizing the Risk Factor

How can such risks be mitigated? The key is good planning and taking a step-by-step approach that allows you to fully test changes before they are incorporated into the application.

Start by assessing your legacy app portfolio to identify and prioritize those apps that need immediate modernization to meet current or future business goals versus those that can be left alone for now or simply migrated to the cloud (via rehosting or replatforming) with minimal changes. This is another area in which having an automated, AI-based analysis tool is critical.

In a microservices architecture, each service embodies a single function that can be implemented and thoroughly tested without impacting the application as a whole. Your modernization plan should be based on adding or replacing functionality one at a time with their microservice implementations. The plan should also include a process for quickly and seamlessly backing a microservice out if problems arise when it’s incorporated into the application.

Related: Succeed with an Application Modernization Roadmap

How vFunction Helps CIOs Overcome App Modernization Challenges

We’ve seen how having an AI-based, automated tool can make a huge difference in minimizing the cost, time, and risk factors of legacy app modernization. And that’s exactly what the vFunction Platform provides.

The vFunction Assessment Hub can automatically analyze legacy apps and generate quantitative measures of code complexity and interdependence. It produces hard numbers that quantify the amount of effort required to modernize each app, providing the information you need to prioritize your modernization efforts and estimate ROI for the project.

The vFunction Modernization Hub automatically transforms complex monolithic applications into microservices. It uncovers hidden process flows and dependencies in applications, thereby minimizing the chance that important functions will be overlooked or incorrectly implemented.By making use of such automated features, vFunction accelerates modernization projects by 10-15x, saving hundreds of thousands of dollars per application. To see first-hand how vFunction can help you overcome app modernization challenges and sleep well at night, schedule a demo today.

Many companies still depend on legacy applications for some of their most business-critical processing. But those apps typically don’t support the kind of technological agility that’s needed for continuing success in today’s ever-changing marketplace environment. That’s why modernizing legacy apps is an accelerating trend among leading companies.

But app modernization is not easy—it requires highly skilled developers who understand both the legacy app and the modern cloud ecosystem. Assembling such a team on-site can be difficult. It’s often easier to find the needed skills and organize the team for maximum effectiveness if team members can work remotely. According to Forbes, which declares that remote work is the new normal,

“When it comes to the tech workforce, it takes more than simply offering remote opportunities to get employees motivated. Employers must embrace flexibility and build (or reinforce) a strong, supportive remote work culture to ensure teams are engaged and high-performing.”

That’s why understanding how to assemble and manage remote legacy app modernization teams is vitally important.

The Goal of App Modernization: From Monoliths to Microservices

Legacy apps are often a severe drag on a company’s ability to innovate at the pace required in today’s fast-changing marketplace and technological environments. That’s because such apps are typically monolithic, meaning that the codebase is organized as a single unit.

Because various function implementations and dependencies are interwoven throughout the code, an attempt to change any specific behavior could impact the entire application in unexpected ways, potentially causing it to fail.

When legacy apps are used for a company’s most important operational processes, such failures cannot be tolerated. When they occur, development teams may be required to stop work on the innovations that are so necessary to a company’s continued marketplace success and take an all-hands-on-deck approach to fixing the problem as quickly as possible.

In contrast to the typical legacy app, software based on a cloud-native microservices architecture can be updated far more easily and safely from remote locations. Microservices are small units of code that perform a single task. Because they are designed to function independently of one another, changes made to one microservice can’t ripple through the rest of the application. That’s why restructuring a legacy app from a monolith to a microservices architecture gives it a much greater level of adaptability.

The goal of legacy application modernization is to substantially improve an app’s adaptability and maintainability by restructuring its codebase from a monolith to microservices.

Related: Application Modernization and Optimization: What Does It Mean?

How System Architecture Correlates With Organizational Structure

In 1967 Melvyn Conway formulated what’s come to be known as Conway’s Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Software engineer Alex Kondov highlights the practical implications of Conway’s Law:

Imagine a small company with a handful of engineers all sitting in the same room. They will probably end up with a more tightly coupled solution that relies on their constant communication. [In other words, a monolith].

A large company with teams in different time zones working on separate parts of the product will need to come up with a more distributed solution. That will allow them to work autonomously, build and deploy without interfering with each other… An organization in which teams need to operate in a fully autonomous manner would naturally come to an architecture like microservices.

The organizational structure of your legacy app modernization team will determine the kind of software it ultimately produces. Although you may aim at creating a microservices-based application, if your team is organized in the tightly-coupled manner of Kondov’s first example, it will be more predisposed towards a monolithic application architecture rather than a microservices architecture.

Optimizing Your Team’s Structure to Support Microservices

The principles of Domain-Driven Design (DDD) provide a useful framework for organizing legacy app modernization teams. As Tomas Fernandez explains,

“Domain-Driven Development allows us to plan a microservice architecture by decomposing the larger system into self-contained units, understanding the responsibilities of each, and identifying their relationships.”

According to María Gómez, Head of Technology for ThoughtWorks, examples of domains include broad business areas such as finance, health, or retail. Each domain may contain several sub-domains. The finance domain, for example, might have sub-domains of payments, statements, or credit card applications.

The DDD paradigm allows developers to identify the domains and subdomains that exist in a monolithic codebase, and draw the boundaries that delineate each service that will be implemented as a microservice. Every microservice embodies a single business goal and has a well-defined function and communications interface. This allows each microservice to run independently of any others.

Each team is fully and solely responsible for the microservices that they develop, and functions, to a considerable degree, independently of other teams. Once a team is made aware of the communications interface defined for each microservice, it can work independently and asynchronously without needing to interact with other teams about how their microservices are implemented.

This organizational pattern favors remote development teams. Each team needs a high degree of internal asynchronous communication as they work out the design of the microservice for which they are responsible. But less communication is needed between teams.

For that reason, remote, loosely-coupled development teams are perfect for converting monolithic legacy apps to microservices. But there are some potential pitfalls tech leaders should be aware of.

Related: What is a Monolithic Application? Everything you need to know

Challenges of Remote Teams

With all of the advantages remote development teams provide for the application modernization process, there are some definite challenges that IT leaders will have to overcome to make their use of such teams effective. Let’s take a brief look.

1. Work-Life Balance

Working remotely can affect work-life balance both positively and negatively: while ZDNet reports that 64% of developers say that working remotely has improved their work-life balance, 27% say that it’s difficult for them to unplug from the job.

Leaders must proactively help remote developers in this area. A big part of doing that is ensuring that goals and deadlines are realistic and that workers aren’t encouraged to spend what should be family or personal time on job-related activities.

2. Assessing Productivity and Progress

Because personal contact with workers is more constrained, leaders have less visibility into the productivity or progress of remote teams. Gaining that visibility may require more formal reporting arrangements, such as daily check-ins where workers report progress on their KPIs. Project management tools such as Trello or Asana can also help.

3. Communications

In the office, developers naturally consult and collaborate informally. That’s more difficult when they are working remotely. In fact, in Buffer’s 2022 State Of Remote Work survey, 56% of respondents identify “how I collaborate and communicate” as a top remote work issue, while 52% say they feel less connected to coworkers. Scheduling regular virtual team meetings using tools like Zoom or Google Chat can help.

4. Work Schedules Across Time Zones

It’s 9 am in San Francisco, and your West Coast team members are starting their workday, but team members in Europe are finishing theirs. How can a team collaborate across time zones? One approach is to focus on asynchronous communication methods, such as group chats and emails, that don’t require individuals to be online at the same time.

5. Company Culture

Company culture is absorbed most easily through face-to-face interactions with leaders and peers. The isolation inherent in remote work makes instilling that culture among team members difficult. John Carter, Founder of TCGen, offers this suggestion:

“Make the unconscious cues in the company culture conscious. Refer to them often and reinforce them. Company culture can follow your team members home, but only if it is made explicit and constantly reinforced.”

Why Remote Teams are the Future

Not only is the distributed nature of remote teams ideal for implementing distributed, cloud-based microservices applications, but they represent a trend that may redefine the IT landscape well into the future.

The COVID-19 pandemic accelerated the use of remote software development teams. As companies learned how to onboard, train, and manage a remote workforce, they realized that disregarding geographical limitations in their hiring allowed them to lower costs and increase quality by tapping into a wider developer talent pool. Bjorn Lundberg, Senior Client Partner at 3Pillar Global describes the trend this way:

“Contract workers, freelancers, and outsourced teams have been on the rise for a while now… As remote collaboration becomes a fixture of the modern workplace, American companies increasingly view outsourcing software development as an opportunity to extend their development talent without exhausting their budgets.”

Even full-time employees want to work remotely: according to the 2022 State of Remote Engineering Report, 75% of developers would prefer to work remotely most of the time.

How vFunction Can Empower Your App Modernization Teams

As we’ve seen, the ideal application modernization team should be relatively small. vFunction helps small teams maximize their effectiveness by providing an AI-enabled, automated platform that reduces the legacy app restructuring workload by orders of magnitude.

vFunction can automatically analyze complex monolithic applications, with perhaps millions of lines of code, to reveal hidden functionalities and dependencies. It can then automatically transform those apps into microservices.To see first-hand how vFunction helps remote application modernization teams maximize their effectiveness, request a demo today.

In a report on managing technical debt, Google researchers make a startling admission:

“With a large and rapidly changing codebase, Google software engineers are constantly paying interest on various forms of technical debt.”

What’s true of Google is very likely true of your company as well, especially if you have legacy applications you still depend on for important business functions. If you do, you’re almost certainly carrying a load of technical debt that is hindering your ability to innovate as quickly and as nimbly as you need to in today’s fast-changing marketplace and technological environments.

Technical debt is an issue you cannot afford to ignore. As an article in CIO Magazine explains,

“CIOs say reducing technical debt needs increasing focus. It isn’t wasting money. It’s about replacing brittle, monolithic systems with more secure, fluid, customizable systems. CIOs stress there is ROI in less maintenance labor, fewer incursions, and easier change.”

But what, exactly, is technical debt, and why is managing it so vital for companies today?

Why Managing Technical Debt is Critical

What is technical debt? According to Ori Saporta: “Technical debt, in plain words, is an accumulation over time of lots of little compromises that hamper your coding efforts.”

In other words, technical debt is what happens when developers prioritize speed over quality. The problem is that, just as with financial debt, you must eventually pay off your technical debt, and until you do, you’ll pay interest on the principal.

• The “interest” on technical debt consists of the ongoing charges you incur in trying to keep flawed, inflexible, and outmoded applications running as the technological context for which they were designed recedes further and further into the past. Software developers spend, on average, about a third of their workweek addressing technical debt. Plus, there’s also the opportunity cost of time that’s not being spent to develop the innovations that can help propel a company ahead in its marketplace.
• The “principle” on technical debt is what it costs to clean up (or replace) the original messy code and bring the application into the modern world. Companies typically incur $361,000 of technical debt for every 100,000 lines of code.

Managing your technical debt is critical because the price you’ll pay for not doing so, in terms of time, money, focus, and lost market opportunities, will grow at an ever-accelerating pace until you do.

Managing Technical Debt: Getting Started

A report from McKinsey highlights how a company can begin dealing with its technical debt:

“[A] degree of tech debt is an unavoidable cost of doing business, and it needs to be managed appropriately to ensure an organization’s long-term viability. That could include ‘paying down’ debt through carefully targeted, high-impact interventions, such as modernizing systems to align with target architecture.”

The place to start in managing technical debt is with modernizing legacy applications to align with a target architecture, which today is usually the cloud. Legacy applications weren’t designed to work in the cloud context, and it’s very difficult to upgrade them to do so. That’s because such apps often have a monolithic system architecture.

Monolithic code is organized as a single unit with various functionalities and dependencies interwoven throughout the code. The coding shortcuts, ad hoc patches, and documentation inadequacies that are typical sources of technical debt in legacy applications are embedded in the code in ways that are extremely difficult for humans to unravel. Worse, because of hidden dependencies in the code, any changes aimed at upgrading functions or adding features may ripple throughout the codebase in unexpected ways, potentially causing the entire application to fail.

From Monoliths to Microservices

Because a monolithic architecture makes upgrading an application for new features or for integration into the cloud ecosystem so difficult, the first step of legacy app modernization is usually to restructure the code from a monolith to a cloud-native, microservices architecture.

Microservices are small chunks of code that perform a single task. Each can be deployed and updated independently of any others. This allows developers to change a specific function in an application by updating the associated microservice without the risk of unintentionally impacting the codebase as a whole.

The process of restructuring a codebase from a monolith to microservices will expose the hidden dependencies and coding shortcuts that are the source of technical debt.

Related: Migrating Monolithic Applications to Microservices Architecture

Options for Modernizing Legacy Apps

Gartner lists seven options for modernizing legacy applications:

1. Encapsulate: Connect the app to cloud resources by providing API access to its existing data and functions, but without changing its internal structure and operations.
2. Rehost (“Lift and Shift”): Migrate the application to the cloud as-is, without significantly modifying its code.
3. Replatform: Migrate the application’s code to the cloud, incorporating small changes designed to enhance its functionality in the cloud environment, but without modifying its existing architecture or functionality.
4. Refactor: Restructure the app’s code to a microservices architecture without changing its external behavior.
5. Rearchitect: Create a new application architecture that enables improved performance and new capabilities.
6. Rewrite: Rewrite the application from scratch, retaining its original scope and specifications.
7. Replace: Throw out the original application, and replace it with a new one.

The first three options, encapsulation, rehosting, and replatforming, simply migrate an app to the cloud with minimal changes. They offer some improvements in terms of operating costs, performance, and integration with the cloud. However, they do little to reduce technical debt because there’s no restructuring of the legacy application’s codebase—if it was monolithic before being migrated to the cloud, it remains monolithic once there.

The last option, replacing the original application, can certainly impact technical debt, but because it’s the most extreme in terms of time, cost, and risk, it’s usually considered only as a last resort.

The most viable options, then, for removing technical debt are refactoring, rearchitecting, or rewriting the code.

Assessing Your Monolithic Application Landscape

The ideal solution for managing technical debt would be to immediately identify and convert a subset of your legacy applications to microservices. But because any restructuring project involves significant costs in terms of money, time, and risk, trying to modernize every app in your portfolio is not a practical strategy for most companies.

That’s why your first step on the road to effectively managing technical debt should be surveying your portfolio of monolithic legacy applications to assess each in terms of its complexity, degree of technical debt, and the level of risk associated with upgrading it. With that information in hand, you can then prioritize each app based on the degree to which its value to the business justifies the amount of effort required to modernize it.

• For apps with high levels of technical debt and great value to the business, consider full modernization through refactoring, rearchitecting, or rewriting.
• Apps with lower levels of technical debt (meaning that they function acceptably as they are) or that have a lesser business value should be considered for simple migration through encapsulation, rehosting, or replatforming.

Refactoring is Key

Refactoring is fundamental to managing technical debt for at least two reasons:

1. It exposes the elements of technical debt, such as hidden dependencies and undocumented functionalities, that are inherent in an app’s original monolithic code. These must be well understood before any rearchitecting or rewriting efforts can be safely initiated.
2. By converting an app to a cloud-native microservices architecture, refactoring positions it for full integration into the cloud ecosystem, making further upgrades and functional extensions relatively easy.

That’s why refactoring is normally the first stage in modernizing a monolithic legacy app. Then, if new capabilities or performance improvements are required that the original code structure does not support, rearchitecting may be in order. Or, if the development team wishes to avoid the complexities of rearchitecting existing code, they may opt to rewrite the application instead.

In any case, refactoring will normally be the initial step because it produces a codebase that developers can easily understand and work with.

Implement “Continuous Modernization”

Technical debt is unavoidable. As the pace of technological change continues to accelerate, even your most recently written or upgraded apps will slide relentlessly over time toward increased technical debt. That means you should plan to deal with your technical debt on a continuous basis–known as continuous modernization. As John Kodumal, CTO and cofounder of LaunchDarkly has said,

“Technical debt is inevitable in software development, but you can combat it by being proactive… This is much healthier than stopping other work and trying to dig out from a mountain of debt.”

You need to constantly monitor and clean up your technical debt as you go, rather than waiting until some application or system reaches a crisis point that requires an immediate all-out effort at modernization. In fact, continuous modernization leads to technical debt removal and should be a fundamental element of your CI/CD pipeline.

Related: Preventing Monoliths: Why Cloud Modernization is a Continuum

vFunction Can Help You Manage Your Technical Debt

As we’ve seen, the first step toward effectively managing your technical debt is to assess your suite of legacy apps to understand just how large the problem is. That has historically been a very complex and time-consuming task when pursued manually. But now the AI-driven vFunction platform can substantially simplify and speed up the process.

The vFunction Architectural Observability Platform will automatically evaluate your applications and generate qualitative measures of code complexity and risk due to interdependencies. It produces a number that represents the amount of technical debt associated with each app, providing you with just the information you need to prioritize your modernization efforts.

And once you’ve determined your modernization priorities, the vFunction Code Copy automates the process of actually transforming complex monolithic applications into microservices, which can result in immense savings of time and money. If you’d like a first-hand view of how vFunction can help your company effectively manage its technical debt, schedule a demo today.