CONCEPT Cited by 1 source
Legacy system risk¶
Legacy system risk is the elevated-failure-probability surface that accumulates when production systems cannot adopt modern delivery practices — automated testing, continuous delivery, blue-green rollouts, feature flags, fast rollback — because of age, architecture, regulatory overhead, or outsourcing arrangements. The delivery-mechanics gap forces the organization back onto CAB-style change management, whose empirical ineffectiveness is documented elsewhere (concepts/external-approval-ineffectiveness).
The financial-services version¶
The 2023-08-16 post names the tension directly:
"Before we had modern practices of test automation, continuous delivery, DevSecOps, rolling deployments with fast rollback, this was the only way. The trouble is, the financial services industry is packed full of legacy systems and outsourcing where implementing these practices is technically challenging and uneconomic."
"Maybe it is time we acknowledge legacy software, risk management, and outsourcing are a major systemic risk in the financial sector?"
This is the uncomfortable corollary of the DORA finding that CABs don't work: if the alternative (continuous delivery + runtime monitoring) is unavailable for economic reasons, a bank has no good options. Swedbank's SEK 850M fine is the cost of that no-win.
Why legacy systems resist modern delivery¶
- Monolithic deployment surface. A single binary / VM image means a single failure domain; "small frequent releases" isn't available when a deploy is an all-or-nothing event.
- Long release tails. Mainframe / COBOL / custom-hardware stacks often ship quarterly or annually; test and certification cycles are measured in weeks, not minutes.
- Missing / unmaintained test suites. Test automation may not exist; where it does, coverage is low and flakiness is high.
- Outsourcing arrangements. The team pushing changes is not the team running the platform. Change-coordination overhead dominates; the authoritative change log lives outside the bank's own tools.
- Regulatory ossification. Process changes must themselves be approved by regulators before the underlying delivery process can evolve, so improvements are slow.
- Vendor lock-in / EOL risk. Dependence on end-of-support systems means even security patches require special change treatment.
The new-systems inverse problem¶
The same post flags the opposite failure mode in next-generation financial-services infrastructure:
"Many next generation systems in financial services are so dynamic and distributed that it is really hard to get a handle on the volume of changes occurring."
High-volume microservices deploys in a regulated org create the reverse problem: too many changes for CAB review to be tractable, even as a ritual. Neither end of the legacy / next-gen spectrum is well-served by traditional change management.
Why it matters systemically¶
Multiple banks running on similar legacy stacks share failure modes. A single vendor, a single core-banking package, or a single outsourcing contractor with ineffective change controls becomes a shared dependency for a meaningful fraction of the financial system. Regulators have historically focused on per-bank controls; the post's argument is that the aggregate risk from legacy + outsourcing + ineffective change management is higher than any single-institution framing captures.
Cross-reference: latent misconfiguration¶
The concepts/latent-misconfiguration concept (from GitHub's "When protections outlive their purpose") describes the same dynamic from a different angle: protections built in response to past incidents can themselves become incident-causing drift as the system evolves around them. Legacy change-management protections are a specific instance: the CAB protects against 1990s-era big-bang releases but is blind to 2020s-era high-frequency, high-cardinality change traffic.
Mitigation paths (partial)¶
None fully solve it, but the industry mitigations in use:
- Strangler-fig rewrites — incrementally replace legacy surfaces with modern stacks without big-bang migration.
- Runtime monitoring (patterns/runtime-change-detection) layered on top of legacy — detect what you can't prevent.
- Forced-investment programs from regulators (e.g. UK's operational-resilience regime) that require banks to fund the modernization.
- Vendor consolidation and benchmarking — pressure the small number of core-banking vendors to modernize their delivery stacks.