Complexity → risk remediation → growth

Most organisations can't see how much complexity they're carrying.

Every financial organisation runs on a sprawl of systems, integrations and aging code, with a web of vendor dependencies layered on top. It works in three steps: it turns a handful of inputs into a single complexity index and benchmarks you against peers; lets you evaluate risk-remediation strategies and their cost over time; then translates the freed capacity into a growth strategy grounded in the leading thinkers on incumbent innovation.

58
COMPLEXITY INDEX · 0–100
Elevated

Signature view

Integration topology

A representative sample of the estate. Each node is a system, coloured by architecture style; dashed amber rings mark ageing, end-of-life endpoints. The crucial pattern in these institutions is where the integration concentrates: bespoke point-to-point links (amber) preferentially terminate at the ageing core and other legacy systems — everything is hard-wired to the old core, so that is where coupling, change-risk and the cost of replacement pile up. A governed ESB or API/event backbone (teal) instead routes connections cleanly and keeps the modern estate loosely coupled. Bespoke interface counts grow on the order of N(N−1)/2; a backbone collapses that toward a hub.

Peer benchmark

Complexity vs comparable institutions

Pick the peer set to benchmark against — these define the comparison shown in both views below.

Mid — 1,000–10,000 staff

Complexity profile vs peers

Your six dimensions (solid) against the typical institution of this type (dashed).

Your estate Peer median

Where you sit among peers

Modelled complexity distribution for your segment & size.

Peer spread Your position

Auto-prioritised

Recommended remediation actions

Each action is scored against your worst dimensions — priority rises with the complexity it removes and falls with the effort it takes (priority = ΔTCI / √effort). Actions whose lever is already pulled are scaled down by an applicability gate, and trade-offs (e.g. cloud raising vendor dependency) are netted into the projected reduction.

ActionEst. ΔTCIEffortPriority
Your estate scores on complexity.Now choose how to remediate the risk it creates, and see the impact over time.

Risk remediation

Choose a remediation strategy

Beyond “do nothing”, organisations modernise along several well-established paths. Select one or more to overlay against the do-nothing baseline and see the impact on risk and cost over time. The recommended option is auto-fitted to your estate; you can change it.

Impact over time

Complexity trajectory

Complexity doesn't drift linearly — it compounds. Software products obsolesce and unpaid entanglement accrues interest, so do nothing accelerates toward a tipping point where the estate becomes too coupled to fix incrementally. Each strategy you select reshapes that curve differently.

Risk exposure — grows to extreme

Cumulative expected cost of risk shocks — outages, forced end-of-life replacements, breaches and regulatory remediation. As complexity festers, shocks become both more likely and more severe, so the curve bends sharply upward; some strategies carry a transient execution-risk hump during cutover. The shaded band is the plausible range from shock-cost uncertainty.

Cost — committed spend, trailing behind

Cumulative run-the-bank plus programme investment — the money you actually commit. It grows closer to linearly, so the risk profile above runs away ahead of it. Together the two charts sum to the total cost of ownership in the cards below.

Remediation frees of budget from keep-the-lights-on.That capacity is what funds growth. Here's how to deploy it.

From remediation to growth

Innovation capacity — what complexity costs your growth

Run-the-bank consumes budget in proportion to complexity. What's left after keep-the-lights-on and expected risk is your capacity to fund the future — Christensen's insight that an incumbent's cost structure and values, not its competence, decide which innovation it can pursue. Every strategy you selected in Step 2 is compared below against doing nothing.

Your growth posture

Where you sit on complexity versus free capacity shapes which growth playbook fits — and how exposed you are to disruption from below. Each strategy you selected in Step 2 is plotted where it leaves you at the horizon; doing nothing drifts you down-left toward survival, while a real reset moves you up-right. Capacity here is structural — it excludes the temporary programme spend, which the cost charts and capacity bars already show.

Author-grounded playbook

Recommended growth strategy

Tailored to your posture, drawing on the leading thinkers on incumbent innovation and disruption.

Methodology, assumptions & sources

This model expresses estate complexity as a single Technology Complexity Index (TCI, 0–100) built from six measurable dimensions, each grounded in established software-engineering metrics and current industry data. It is a decision-support model, not a precise audit — outputs are relative and indicative.

1 · Topology & integration (graph-theoretic)

From systems N and interfaces I we derive average connectivity (degree) λ = 2I/N and density d = I ÷ [N(N−1)/2]. The full-mesh ceiling N(N−1)/2 is why point-to-point integration scales quadratically. Inspired by McCabe's cyclomatic complexity (M = E − N + 2P), more independent interaction paths mean more to test and break. A governance factor g reflects integration style (point-to-point 1.30 → API/event 0.78).

C_topo = 100 · ( 1 − e^( −λ·g / 8 ) )

2 · Architectural entropy (Shannon)

Heterogeneity across the five architecture styles via normalised Shannon entropy e = H/ln(5). Because almost every estate runs several styles, raw entropy clusters near the top and barely discriminates, so it is passed through a logistic that spreads the realistic range: a near-monoculture or two-style estate reads low, a typical three-to-five-style bank reads mid, and an even “a bit of everything” spread reads high.

H = −Σ pᵢ·ln(pᵢ)  ;  e = H/ln(5)  ;  C_ent = 100 · σ( (e − 0.84) / 0.10 )

3 · Coupling (architecture × integration style)

Coupling coefficient κ = Σ pᵢ·wᵢ with style weights (mainframe/monolith 1.0, client-server 0.8, SOA 0.55, SaaS 0.5, microservices 0.4), amplified by connectivity and by integration style: point-to-point integration is itself a form of tight runtime coupling, so a coupling factor i scales from 0.78 (API/event backbone) to 1.18 (point-to-point). Effective connectivity uses λg = λ·g.

i = 0.78 + 0.40·(g−0.78)/(1.30−0.78)  ;  C_cpl = 100 · κ · i · ( 0.6 + 0.6·(1 − e^(−λg/8)) )

4 · Legacy & aging (logistic)

Average age passes through a logistic centred near 14 years (debt and risk climb steeply beyond), blended with legacy share and key-person scarcity.

C_leg = 100 · ( 0.45·σ((age−14)/4) + 0.35·legacy% + 0.20·scarcity )

5 · Vendor leverage (concentration × lock-in)

Combines spend concentration, a lock-in ratio switch-time ÷ licence-term (short terms against multi-year migrations hand vendors pricing and forced-upgrade power), and cloud concentration.

C_ven = 100 · ( 0.40·conc + 0.35·min(1, (switch/term)/4) + 0.25·cloud·strat )

6 · Change fragility (emergent blast-radius)

How risky change is — a function of connectivity, coupling and legacy that estimates incident-propagation surface.

C_chg = 100 · ( 0.5·(1−e^(−λg/8)) + 0.3·κ·i + 0.2·(0.45·σ_age + 0.55·legacy%) )

Composite & bands

TCI = 0.20·topo + 0.10·ent + 0.16·cpl + 0.20·leg + 0.16·ven + 0.18·chg

Bands echo McCabe's risk tiers: <25 Lean · 25–45 Managed · 45–65 Elevated · 65–80 High · 80+ Critical.

Benchmarking

Each segment+size carries a modelled peer profile (mean & spread, σ≈11) built from the dimension medians typical of that institution type. Your percentile is the normal CDF of your TCI against that distribution. The run-the-bank share is anchored to surveyed reality: maintenance ≈ 30% + 45%·(TCI/100), which lands a typical estate near the ~56% maintenance figure reported by Deloitte's CIO survey, with “digital vanguard” peers nearer 47%.

Trajectory dynamics (compounding, obsolescence, tipping point)

Complexity is modelled as a non-linear dynamical system over the chosen horizon (10–30 years, set by the time-horizon slider), not a straight-line drift:

  • Entanglement debt. Beyond the six independent dimensions (which each saturate), an emergent debt term captures whole-estate complexity — every deferred change adds a workaround. Left unpaid it compounds, debt₊₁ = debt + 1.15 + 0.11·debt, giving the convex “festering” curve. Effective complexity is TCI + debt, capped near 97 (estate seize-up).
  • Obsolescence cadence. Each architecture style has a typical life before replacement (mainframe ≈26 yrs … cloud-native ≈6 yrs). The blended life sets a threshold; once average age passes it, legacy accumulates at an accelerating rate 0.8 + 1.7·(age−L)/L per year. Note that a modern, microservices-heavy estate has a shorter blended life — faster obsolescence cadence — even though it feels less “legacy”.
  • Tipping point. Incremental remediation effectiveness decays through a logistic centred at TCI 78; past it, piecemeal change can no longer keep up and the estate effectively requires wholesale transformation. This is why an already-Critical estate cannot be saved incrementally in the model.
  • Remediation strategies. Step 2 offers a palette of recognised modernisation paths, each with its own dynamics, cost intensity and execution risk, overlaid on the do-nothing baseline: incremental hardening (ring-fence ~6% to pay down debt and tread water); encapsulate & API-wrap the legacy core (Gartner pace-layered “wrap & renew” — cuts coupling and topology fast but doesn't fix obsolescence, so legacy keeps ageing underneath); strangler-fig modernisation (Fowler — incrementally route capabilities off the core behind a façade; a steady, lower-risk reset that compounds and keeps paying down over a long horizon); consolidate & rationalise (application-portfolio rationalisation — decommission the long tail, cutting system count, heterogeneity and interfaces); outsource / SaaS & managed service (sheds legacy and key-person risk but raises vendor concentration and lock-in — a risk trade, not a cure); and big-bang transformation (a funded, time-boxed core replacement — the deepest reset of your own stack, scaled by appetite). Finally, business migration to a BaaS platform is the most radical path: rather than rebuilding your own estate, the business is moved wholesale onto an existing modern stack (today, a Banking-as-a-Service vendor) and the legacy estate is left behind entirely. It collapses legacy, interfaces and architectural entropy harder than any other strategy — but only by reshaping the business to fit the platform's constraints (radical simplification, minimal customisation), and it pushes vendor concentration and lock-in to their ceiling. The model therefore fits it to smaller, legacy-heavy institutions that can actually fit a platform, and rates it poorly for very large, bespoke universal banks. The model recommends a best-fit strategy from your dimensions, but you can select any combination to compare. The transformation appetite input scales the depth and cost of the big-bang, strangler and migration paths.
  • Execution risk. Modernisation is not free of risk while it runs. Each strategy carries an execution-risk multiplier on the hazard during its active programme — small for incremental and wrap paths, larger for outsourcing migrations and strangler cutovers, and a pronounced transient spike for a big-bang core replacement at cutover. This is the familiar “J-curve”: risk rises before it falls, which is why the safer, slower strangler path can outperform a big-bang once execution risk is priced in.
  • Decision delay. The start-year control defers the chosen programme. Until the decision is taken, the selected path drifts along the do-nothing curve — debt compounds, legacy accretes and the estate degrades — so the programme begins from a worse, sometimes already-Critical, starting point, with less of the horizon left to recover in. The charts branch at the decision marker; the caption quantifies how much complexity and cost the delay adds versus deciding now.

Cost & risk overlay

Annual cost = run-the-bank (budget × maintenance share) + expected risk-shock + investment. The shock term converts festering risk into expected cost: an annual hazard rising with legacy, vendor and fragility (and steeply past the tipping point) multiplied by a severity that scales with both budget and effective complexity — hazard × budget·(0.35 + 0.80·(effTCI/100)^1.6), where effTCI is the TCI including entanglement debt — representing outages, forced end-of-life replacements, breaches and regulatory remediation. The cumulative-cost crossover marks the year do nothing overtakes transform in total cost: deferred investment is not saved, it is borrowed at a rising interest rate and repaid later as shocks. Because the shock term is the most uncertain part of the model, the shaded confidence bands propagate that uncertainty: run-the-bank and investment are treated as relatively firm, while the shock component is flexed between 0.5× and 1.8× of expected (an asymmetric, right-skewed range — shocks rarely come in under expectation and occasionally come in far over). The band is therefore widest under do nothing and collapses under transform. The overlay is split into two cumulative charts — risk exposure (the expected cost of shocks) and committed cost (run-the-bank plus investment) — which sum to the total cost of ownership shown in the cards. Because hazard and severity both climb with complexity, the risk curve is markedly convex: it accumulates slowly at first then accelerates toward extreme, outrunning the more linear cost curve. These cost and risk figures are illustrative scaling relationships for relative comparison, not budget forecasts.

New Zealand calibration. All cost figures are NZD and the budget scale is set to NZ reality rather than global-bank scale. Reference points used: ANZ NZ reports technology and investment costs of about $550 million a year (≈30% of its cost base), roughly $1.6 billion over three years; ASB's total operating expenses run near $1.4 billion with $100M+ a year on financial-crime and fraud prevention alone; Kiwibank's CoreMod core-banking replacement was budgeted at $100M+ over three to four years before a $90M write-off; and BNZ took a $352M software write-down in 2026 as AI shortened the useful life of its technology assets. Even the largest NZ bank has roughly 9,000 staff, so for NZ institutions the “Mid” and “Community” size bands apply — “Large” and “Global” correspond to Australian parents or international banks.

Growth strategy (innovation capacity & posture)

Step 3 translates complexity into growth terms. Innovation capacity is the budget left after keep-the-lights-on and expected risk: capacity = budget − run-the-bank − expected shock − programme investment. This operationalises Clayton Christensen's argument in The Innovator's Dilemma that incumbents fail not from incompetence but because their resources, processes and values — here, a cost structure dominated by running a complex estate — leave no room to pursue disruptive growth. The capacity bars show how doing nothing crowds out growth over time, and how the remediation chosen in Step 2 frees it (Govindarajan & Trimble's Three-Box Solution Box 2 “forgetting” — decommissioning — funding Box 3 “creating the future”).

Your posture places you on two axes — complexity (TCI) against free capacity — yielding five archetypes: agile challenger, lean / capital-light, funded incumbent, trapped incumbent (the classic dilemma — complexity consuming the budget growth needs), and survival mode at Critical complexity. Disruption exposure reflects that rigidity is vulnerability: 0.5·legacy + 0.3·TCI + 0.2·fragility. The recommended playbook is curated per posture from the leading thinkers on incumbent innovation — Christensen (autonomous units, sustaining vs disruptive innovation, Jobs-to-be-Done), Govindarajan & Trimble (Three-Box), O'Reilly & Tushman (the ambidextrous organisation), Geoffrey Moore (Zone to Win, Crossing the Chasm), Kim & Mauborgne (Blue Ocean Strategy) and Rita McGrath (transient advantage). These are framing prompts, not prescriptions — the right move depends on market context the model doesn't see.

Selected sources

~70% of banks still run on legacy core systems and ~43% still use COBOL; mainframes handle ~83% of global banking transactions; ~63% of banks rely on code written before 2000, with three-quarters reporting only one or two people able to maintain it (Pragmatic Coders 2025; Accenture Banking Technology Report 2025). Technical debt ≈ 20–40% of the technology estate and consumes ~30–40% of IT budgets; maintenance averages ~56% of enterprise IT spend (McKinsey; Protiviti 2025; Deloitte CIO survey). Enterprises average ~900 applications with under ~30% integrated; large estates run 500–2,000+ apps (Integrate.io 2026; Umbrex). Vendor support/maintenance can reach ~20% of licence value per year and rise over time, while switching is a multi-year effort — the leverage asymmetry at the heart of lock-in (industry vendor-management analyses 2025–26). Complexity metrics: McCabe cyclomatic complexity; coupling & Shannon-entropy software metrics.

Modernisation patterns: Martin Fowler, Strangler Fig application pattern; Gartner pace-layered application strategy and “wrap & renew”; application-portfolio rationalisation (TIME model). Growth & innovation: Clayton Christensen, The Innovator's Dilemma and Competing Against Luck (Jobs to be Done); Vijay Govindarajan & Chris Trimble, The Three-Box Solution; Charles O'Reilly & Michael Tushman on ambidextrous organisations; Geoffrey Moore, Crossing the Chasm and Zone to Win; W. Chan Kim & Renée Mauborgne, Blue Ocean Strategy; Rita McGrath, The End of Competitive Advantage.

Not investment, legal or audit advice. Figures are modelled estimates for orientation and prioritisation. Calibrate weights and peer profiles to your own portfolio data before relying on absolute values.

This tool runs entirely in your browser — no inputs leave this page. Move the controls on the left and every figure, chart and recommendation recomputes live.