In enterprise-grade financial systems, technical debt isn't just a code smell; it's a systemic risk. Decades-old mainframes, monolithic codebases, and undocumented integrations pose constant threats to stability and velocity. However, stopping feature development for a year to "rewrite everything from scratch" is a luxury no business can afford.
The Strangler Fig Pattern
The most pragmatic approach to modernizing a massive legacy application is the Strangler Fig pattern. Instead of a big bang rewrite, you start by placing an API gateway in front of the legacy monolith. New features are built as modern microservices, and the gateway routes traffic accordingly. Over time, you chip away at the monolith, migrating specific domains (like User Authentication, then Transaction Ledgering) to the new architecture until the old system can be safely decommissioned.
Quantifying Tech Debt for Business Stakeholders
To secure resources for refactoring, engineering leaders must learn to speak the language of the business. You can't just talk about "clean code." You must quantify tech debt in terms of lost opportunity cost. If deploy times drop from 2 hours to 10 minutes, calculate the engineering hours saved. If legacy database deadlocks cause 10 minutes of downtime a week, calculate the lost GMV (Gross Merchandise Value). When debt is framed as a tax on feature delivery, the business is far more willing to invest in paying down the principal.
Creating a Tech Debt Budget
High-performing teams don't ignore tech debt, nor do they let it consume all their time. At Experian and similar organizations, we enforce a strict 20% budget for engineering maintenance and tech-debt repayment within every sprint. Consistency is key. By treating system health as a continuous, iterative process, you avoid the massive rewrites that derail organizations for years.
Back to Portfolio