Most city maps show what is easiest to see. They indicate roads, landmarks, neighborhoods, and destinations to help travelers understand where things are located in relation to one another. But anyone trying to modernize, or really even manage, the London Underground would need a very different kind of map. Transit maps, on the other hand, strip away much of the city’s visible geography to reveal the connections that determine the real flow of people and traffic: that is, the transfer points, shared lines, bottlenecks, and stations whose importance is not obvious from the street above.
Many organizations approach application modernization with the equivalent of a street map.
They build an inventory showing each application’s owner, age, technology, business function, and perceived importance. This is, of course, a necessary step but excessive focus on it can easily obscure the relationships that make modernization risky. An unremarkable service buried several layers below a customer-facing application may support multiple revenue-generating workflows. Changing the visible application without understanding that dependency can leave the real problem untouched or destabilize several other systems at once.
The pressure to act is considerable. Recent research shows 95% of surveyed IT leaders, software architects, and developers consider application modernization essential to their organization’s success in the short-to-medium term future. Yet once leaders agree modernization matters, they still face a more difficult question: where should the work begin?
In a recent conversation, Axian Lead Solution Architect Gabe Harris offered a direct and different kind of answer:
“Build your dependency chain first and make sure it’s accurate.”
For Harris, a credible application modernization strategy requires moving beyond a flat 2D inventory and building what he describes as a three-dimensional view of the portfolio. This map must show not only which applications exist but also how business value, operating risk, and internal and external dependencies intersect.
Before organizations decide which system to stabilize, refactor, replace, or deliberately leave alone, they need a map that shows how the business actually moves.
An Application Inventory Is Only a Street Map
Every modernization effort should begin with some form of inventory. Organizations need to know what applications they own, who supports them, what technologies they rely on, and which business functions they enable. This information provides an essential starting point for planning investment, allocating resources, and identifying systems approaching the end of their useful lives.
The challenge is that inventories primarily describe applications as individual assets.
A modernization roadmap built solely from that perspective tends to prioritize the most visible systems:
- Customer-facing applications
- Aging technologies
- Platforms already identified as strategic priorities
These are reasonable considerations, but they do not necessarily reveal where the greatest operational risks reside.
As Harris explained during our discussion, organizations need to “take it from that 2D application inventory to a 3D one.”
The third dimension is dependency.
An application may appear relatively unimportant when viewed in isolation, yet it quietly supports dozens of downstream systems or business processes. Another may seem highly critical because customers interact with it every day, while the underlying source of its instability may exist two or three layers deeper in the architecture. Looking only at the applications themselves can make both situations appear identical.
Business value and dependency value are not always the same thing. Customer-facing applications naturally receive the most attention, but some of the most consequential modernization decisions involve services few people outside the engineering organization even know exist.
Like a street map, an application inventory shows where everything is located. A dependency map reveals how the organization functions organically. Before leaders decide what to modernize first, they need to understand not only which systems are important but also which other systems depend on them.
Dependency Risk Changes What “Critical” Means
Once organizations move beyond a two-dimensional inventory, they can begin evaluating applications through a different lens. Harris argues that modernization decisions should balance three factors:
- Business value
- Operating risk
- Dependency reach
Business value is usually the easiest to understand. Leaders already know which applications generate revenue, support customers, enable critical business processes, or carry regulatory obligations. These systems naturally attract attention because their importance is visible across the organization.
Operating risk requires a deeper assessment. A stable application is not simply one that stays online. Teams also need to consider inconsistent outputs, aging runtimes, security exposure, weak ownership, and recurring operational issues. An application that responds quickly but returns incorrect data can be just as disruptive as one that fails outright.
The third dimension, dependency reach, is often the least visible but the most revealing. Some services sit quietly beneath the surface, supporting dozens of upstream and downstream systems. Others appear important because they are customer-facing but depend on lower-tier services that create most of their instability. As Harris observes, the goal is to understand “the value that you already know from the systems that are business and customer facing and apply it downstream to those systems that are farther underneath the covers.”
Despite broad agreement that modernization is strategically important, progress has been slower than many organizations expected. Recent studies have found only 27% of organizations report having modernized many of the workflows, applications, and systems needed to achieve their business goals. This gap suggests that rather than not recognizing the need for modernization, the real challenge is often determining where to begin and how to sequence the work responsibly.
The result of this approach is a fundamentally different way of thinking about modernization. Instead of ranking applications from most to least important, organizations can begin sequencing work according to where risk actually resides. Criticality is no longer determined solely by what the business can see. It also depends on the hidden relationships that keep those visible systems running.
Sometimes the Right Modernization Decision Is Better Observability
Once organizations understand where dependency risk exists, the next instinct is often to begin replacing technologies. Harris argues this is where many modernization efforts become unnecessarily expensive.
Not every risky dependency needs to be rebuilt.
In fact, organizations frequently lack enough operational evidence to justify that decision in the first place. Monitoring and alerting typically focus on customer-facing applications because those are the systems whose failures immediately affect revenue, users, or service levels. The deeper layers of the dependency chain often receive far less attention, leaving teams with limited visibility into how frequently services fail, how consistently they behave, or who ultimately absorbs the cost when something goes wrong.
This growing emphasis on visibility is reflected across the industry. A 2025 report found 70% of organizations increased their observability investments during the past year, while three-quarters expect those investments to continue growing. As software ecosystems become more interconnected, understanding system behavior is becoming just as important as changing the systems themselves.
Harris believes visibility should often precede modernization. As he explains, “Sometimes it’s way better to just have simple observability than it is to do a ton of work to update something.”
This observation shines light on a broader principle: a dependency should not be evaluated solely by its age or technology stack. Leaders also need to understand whether it behaves predictably, whether failures are isolated or systemic, and whether the operational cost of maintaining it justifies a larger engineering effort.
One example Harris shared involved recurring manual work inside a finance department. Rather than indicating a system that required wholesale modernization, the underlying issue proved to be a single downstream service producing an incorrect output. Improving visibility into that dependency made it possible to identify and correct the actual source of the problem without rebuilding an otherwise functional application.
Observability does more than expose failures. It provides the evidence organizations need to determine whether a dependency should be monitored, stabilized, refactored, or ultimately replaced. Before deciding how to modernize, leaders first need to understand what systems do in a 3D view.
Modernization Is a Menu, Not a Mandate
Understanding dependency risk does not automatically point toward a single modernization strategy. In fact, Harris argues one of the most common mistakes organizations make is treating modernization as though every aging application requires the same response.
The reality is considerably more nuanced.
Applications that combine high business value with high operational risk often justify traditional modernization efforts, whether that means upgrading the technology stack, moving into a more secure environment, or improving scalability.
However, many applications fall somewhere else on the spectrum.
Some may be stable enough to leave largely untouched while adding better monitoring, documentation, and operational ownership. Others may benefit from targeted refactoring that removes unstable dependencies or simplifies integrations without replacing the underlying platform. In other cases, the most effective intervention may not involve the application itself at all. Improving an upstream service or correcting a downstream consumer can dramatically improve reliability without making significant changes to the dependency at the center of the investigation.
As Harris put it:
“The answer could very much be: we don’t touch this thing. We just put more observability around it.”
This potentially hands-off approach can seem counterintuitive. Modernization discussions often assume older technologies should automatically be replaced. Instead, Harris argues, the objective should be to reduce operational risk, without needlessly maximizing engineering activity. If an application performs reliably, fails infrequently, and imposes minimal business cost, rebuilding it may deliver little value compared to strengthening the systems around it.
Rather than asking, “How do we modernize this application?” leaders can ask, “What is the smallest change that meaningfully reduces risk across the entire dependency chain?” This shift transforms modernization from a technology initiative into a strategy for improving the performance and resilience of the broader application portfolio.
The Dependency Map Extends Beyond Your Organization
Dependency mapping does not end at the edges of an organization’s application portfolio. Modern software increasingly relies on frameworks, open-source libraries, third-party packages, cloud services, and vendor-supported platforms that introduce their own relationships, release cycles, and risks. A three-dimensional modernization strategy needs to account for those external dependencies just as carefully as the internal ones.
Recent research illustrates the scale of the challenge, revealing that 80% of application dependencies have gone more than a year without being upgraded, despite newer versions being available for more than 99% of packages. For many organizations, dependency risk is no longer confined to internally developed software. It increasingly extends into components maintained by communities and vendors outside the business, existing on a spectrum of partial ownership.
That reality reinforces another point Harris emphasized throughout our conversation: modernization should solve a specific problem, not simply follow the latest technology trend.
He pointed to the rapid adoption of Kubernetes in recent years as an example. The platform is exceptionally powerful when organizations truly need the scalability and orchestration capabilities it provides. Yet Harris and Axian have repeatedly encountered environments where Kubernetes introduced far more architectural complexity than the applications themselves required. Rather than simplifying operations, organizations found themselves managing a new layer of dependencies they neither anticipated nor fully understood.
The lesson extends well beyond Kubernetes. Every major technology decision carries its own dependency footprint. Whether organizations adopt AI platforms, cloud-native services, new frameworks, or third-party libraries, these choices all become part of the operational landscape any future modernization efforts must account for.
A modernization roadmap should therefore evaluate more than the applications an organization owns. It should also account for the external technologies those applications depend on and ask a simple but important question: does this dependency reduce operational risk or merely relocate it?
Modernize the Network, Not Just the Stations
Attempting to manage a transit system with just a street map invites potential trouble ranging from slightly cost-ineffective to downright catastrophic. Modernizing one from that perspective would be nearly impossible. The stations people notice are not always the ones that keep the network moving, and closing the wrong one can have consequences far beyond its immediate surroundings.
Application portfolios behave much the same way. The systems drawing the most attention are not necessarily the ones introducing the greatest operational risk. Before deciding what to modernize, organizations first need to understand how business value, operating risk, and dependency reach intersect across the portfolio.
As Harris summarizes it:
“[Axian’s] approach to modernization is practical and focused on getting them exactly what they need and nothing more.”
Ultimately, effective modernization is not measured by how many applications an organization replaces or how quickly it adopts new technologies. It is measured by whether each change makes the broader system more understandable, more resilient, and easier to operate.
Before deciding what to modernize next, make sure you understand what depends on it. Axian helps organizations map application dependencies, identify where operational risk actually resides, and choose the smallest changes that deliver meaningful business value.
Contact Axian to start building a clear, practical modernization roadmap grounded in business value, operational risk, and application dependencies.