Making Architecture Debt Visible in a Legacy Insurance Monolith
A 12-year-old policy administration monolith supports four insurance product lines. Fifteen Scrum teams maintain it. In the last quarter, 32% of sprint capacity went to unplanned work: batch failures, manual reconciliation, and hotfixes. A regulatory audit is five months away. The architecture debt backlog has 240 items, but no owner, no cost estimates, and no link to product backlogs. The CIO wants a debt sprint to fix everything; product owners refuse to stop feature delivery. Two architects are available. The platform has 6 million lines of code, 3,000 database tables, and 40 integrations. The enterprise architecture team is seen as a documentation shop. The audit committee has requested a remediation plan. You are asked to propose a pragmatic way to get debt under control and demonstrate architectural value before the audit.
1. How would you triage the 240 debt items into an actionable architecture backlog? What criteria and first steps?
Read the worked answer
First, reject the debt sprint as a big-bang. Build a debt registry that classifies each item by type, owner, affected value stream, and interest: the recurring cost in unplanned work or risk. Score each on regulatory and security risk, frequency of change, coupling, and cost of delay. Use a Pareto view: likely 10 to 15 items drive most of the 32% unplanned work, especially batch failures and reconciliation. Run a two-week discovery to attach evidence such as incident tickets and cycle-time data to the top 20. Then create a rolling architecture backlog of 10 to 15 items with acceptance criteria, not 240. Close or merge items that are stale, duplicate, or low-risk. Link each item to a product backlog and a fitness function so teams see the payoff. This makes debt actionable and defensible before the audit.
2. How should debt work be funded and prioritized alongside feature delivery? Propose a governance and funding model.
Read the worked answer
Fund debt as architecture enablers in the lean portfolio, not as a separate central team. Give each product team a protected capacity slice, starting at 15 to 20%, for debt and runway items tied to its value stream. Prioritize with WSJF or cost of delay, but add a risk override for audit-critical items. Product owners and architects jointly own the queue; the CIO sets the capacity guardrail and does not reallocate mid-quarter without recording the trade-off as new debt. Use participatory budgeting at quarterly planning to choose the top debt items. The reasoning is that product owners optimize features, so debt needs a portfolio-level constraint and transparent economics. A debt sprint fails because it stops delivery and then debt returns; embedded capacity changes the system.
3. What evidence should you present to the CIO in 30 days to show the approach is working?
Read the worked answer
Present leading indicators, not just audit outcomes. Baseline the 32% unplanned work and identify the top five debt items causing it. In 30 days, show that 100% of the top 20 debt items have an owner and evidence; a pilot value stream has two debt items in its sprint backlog with acceptance criteria; one fitness function is automated for reconciliation or batch monitoring; and decision lead time for debt fixes is under five days. Also report the interest rate, meaning hours of unplanned work per month attributable to the top items, before and after. The reasoning is credibility: the CIO needs a causal chain from debt management to reduced firefighting, not a promise of a cleaner codebase. Avoid claiming audit success early; show risk reduction with evidence.