Read the full article here.
From the Southwest Airlines meltdown that occurred over the 2022 to 2023 holiday season to the latest FAA outages, unchecked and unattended technical debt has reached a tipping point for enterprise applications that form the backbone of every major business category from financial services, travel and energy to technology, automotive and beyond. This is a global issue that extends to any organization that has aging, legacy applications that are business-critical but have suffered over the years from neglect and a lack of investment in modernization.
It's a lurking problem—hidden from everyday view—, but it festers internally and grows over time. Development teams and engineering leaders know it’s there, and although small code issues can be fixed in release cycles, it’s the architectural technical debt that's the hardest problem to tackle and fix. Worse yet, it's the biggest threat to business resilience, as it has the most direct effect on product quality, availability, scalability and stability.
The heavy shift and focus on digital expansion and access driven by Covid-19 only exacerbated the problem. Most organizations simply patched over their modernization responsibilities, gaining temporary kudos for moving to the cloud, cutting data center costs and gaining access to new managed services. But a monolith in the cloud is still a monolith. This lift-and-shift approach proved short-sighted, as that monolith was just as hard to change, brittle to update and maintain and was burdened with long test cycles, longer release cycles and slow recovery times.
Worse yet, monoliths have become ticking time bombs with the potential to explode at any time. Added to that are the unexpectedly high cloud instance costs that undermine early cost benefits. They're expensive to run and just as risky to continue to depend on.
Technical debt can take many forms, but, in the end, debt is debt—it's a business and technical expense that organizations must manage (or, for too many, just ignore). But not all technical debt is bad, as it’s a rational part of both application and infrastructure management. Taking on debt is a valid business calculation that should balance investment in new features, and customer needs with the hidden debt that gets swept under the rug year after year.
Like any debt, if it gets too large or too debilitating, that large lump under the rug may trip up your business at just the wrong time. The typical early signs of this technical debt malaise are noticeable but not yet severe, from slower rates of innovation to the loss of agility in responding to new opportunities or challenges. These symptoms slowly chip away at your competitiveness and profitability. So, although eliminating all your technical debt isn't a reasonable goal, a great starting point is identifying which applications pose the biggest risks, baselining their architecture and watching for architectural drift over time.
Monolithic applications naturally suffer from a significant amount of architectural technical debt that snowballs year over year, getting harder and harder to untangle. Because application architects often lack the tools to shift left into the ongoing software life cycles of these monoliths, this type of technical debt usually remains hidden and unmeasurable.
Architectural technical debt includes deep shared dependencies, long dependency chains, duplicated code and dead code (no one knows why it’s there, and they’re afraid to touch it for fear of the unknown). Most of the architects responsible for these monolithic apps inherited that role and had no part in the original design or subsequent permutations. This lack of architectural visibility, observability, history and insight makes application modernization one of the most challenging projects to predict and build a business case for, let alone successfully execute.
The first key to this puzzle is measurement—not just code quality measurement, which is critical and widely available, but an architectural set of measurements for early identification of architectural drift based on measurable baselines so architects can track architectural technical debt and build a plan to address it based on scientific data that's monitored, tracked and shared. We can’t fix what we can’t measure, and this goes double for modernization. In particular, it explains why modernization has been more of an art than a science, with just a handful of experts armed with manual processes and limited best practices that have barely moved the needle on the backlog of applications requiring modernization.
The second key is choosing which services require or deserve investment in modernization. More specifically, architectural technical debt, although critical to understand and track, shouldn't be the only criteria for modernization. These metrics need to be overlaid with the business value streams of the application and the business services it supplies and supports.
An 80/20 rule is typical for monoliths, with 20% of the services providing 80% of the current value. These are the key services to target for transformation into microservices. Cloud costs can also follow the 80/20 rule, as typically, 20% of a lift-and-shift monolith eats up 80% of your cloud instance investment. Pulling those services out to take advantage of the elasticity, wide choice of compute instances and inherent scalability of the cloud can truly optimize your current cloud spend.
The third and final key is prevention—building a proactive, continuous modernization culture that commits to measuring, baselining and tracking all your critical apps to manage architectural technical debt before it hits a critical state at which recovery is difficult and impactful to the business. A great example is the many early microservices that have begun to take on the shape of mini-monoliths.
Start with the applications that have already been lifted and shifted to the cloud or the apps with the most impactful services that can be extracted for big business wins or cost savings. By measuring your architectural technical debt, using this data to accelerate your modernization strategy and adopting continuous modernization best practices going forward, your organization can access new levels of innovation and resilience.
If you like this article consider subscribing to our bi-monthly newsletter to get information about our portfolio, solutions, and insights delivered to your inbox.