Case Studies in Enterprise Architecture

Case studies are how architecture lessons transfer. The specifics of every transformation are unique, but the patterns — what enables success, what causes failure — recur across sectors and decades. The architect who has internalised these patterns approaches their own transformation with a head start that cannot be gained any other way.

The cases here are anonymised composites, drawn from common transformations, chosen to illustrate patterns rather than to celebrate or criticise any organisation. Each shows the architecture decision, the context, the outcome, and the lesson — with the goal of pattern recognition, not prescription.

This page presents five composite case patterns — a bank's core transformation, a retailer's cloud-native move, a manufacturer's data mesh, a public sector interoperability programme, and a conglomerate's platform consolidation — followed by the lessons that recur across them.

A large retail bank faced a core banking system over 30 years old, increasingly unable to support digital products, regulatory change, or competitive speed. The initial plan was a five-year big-bang replacement — a new core, cut over in a single event. After 18 months of planning and rising risk, the programme was restructured around transition architectures and an evolutionary approach.

The restructured programme defined a target state (a modern, API-first core with cloud-native services), then sequenced transition architectures that delivered value incrementally: a digital origination layer in front of the legacy core (value in year 1), a new payments service decoupled from the core (year 2), progressive migration of products to the new core (years 3-5), with the legacy core eventually retired. Each transition was operable and value-delivering.

The lesson: big-bang core replacement rarely survives contact with reality. Transition architectures — each operable, value-delivering, and target-aligned — sustain momentum, manage risk, and keep the programme funded. The bank did not lower its ambition; it sequenced it. The five-year horizon was unchanged; the path through it became survivable.

A multi-brand retailer with a monolithic e-commerce platform struggling with peak-load reliability and slow feature delivery adopted a cloud-native, composable (MACH) architecture. The risk was fragmentation: each brand and each team choosing its own cloud, tools, and patterns, producing modern but incoherent systems.

The EA team's intervention was a paved-road platform: a reference architecture (Kubernetes-based, API-first, headless commerce) implemented as an internal developer platform with golden paths for new services. Teams used the platform because it was the fastest path to production; conformance happened because the road embedded the standards. Exceptions were handled, but the majority followed the road.

The lesson: cloud-native without a governed paved road fragments. The investment in the platform — reference architecture, IDP, golden paths — was what made the cloud-native move coherent at scale. The retailer did not constrain choice by policy; it shaped choice by providing a road teams preferred. Governance by enablement outperformed governance by gate.

A global manufacturer with a large, under-governed data lake — cheap to store, hard to trust, and slow to insight — adopted a data mesh pattern. The shift was as much organisational as technical: domains (supply chain, manufacturing, sales) were given ownership of their data as a product, with contracts, quality SLAs, and discoverability, on a shared lakehouse platform.

The challenge was data ownership maturity. Domains accustomed to dumping data into a central lake had to learn to own, contract, and quality-assure it. The EA team invested heavily in enablement — templates for data products, a catalogue that made products discoverable, and an enabling team that coached domains — rather than mandating mesh top-down.

The lesson: data mesh is an organisational pattern, not a technology. Adopting it top-down without building domain data ownership maturity produces a mesh in name only — domains that do not own their data, with the lake's old problems re-surfacing. The manufacturer succeeded because it treated ownership maturity as the work, with the platform as the enabler, not the solution.

A national government with fragmented agency systems — each with its own identity, data, and payment services — launched a whole-of-government digital programme. The ambition was citizen services that crossed agency boundaries: register once, interact with government as a whole. The risk was that each agency would protect its systems and the programme would produce another layer rather than integration.

The EA approach was shared platforms with open standards: a national digital identity, shared data registries, common payment and notification services, and interoperability standards that let agencies integrate. Agencies consumed the shared platforms rather than build their own; the standards made integration consistent. The programme was funded centrally and governed as government capability.

The lesson: whole-of-government interoperability requires shared platforms and standards, owned centrally and consumed by agencies. Agency-by-agency modernisation produces fragmentation by default; the architecture must make integration the path of least resistance through shared platforms, or agencies will revert to building their own. Open standards and shared platforms are the interoperability infrastructure.

A conglomerate of acquired companies found itself with five ERPs, four CRMs, and multiple identity and integration platforms — the predictable result of growth by acquisition without architectural integration. Run cost was high, cross-company insight impossible, and each acquisition added more duplication. The EA team was asked to consolidate.

The approach was capability-based. The EA mapped each company's systems to capabilities, identified where consolidation delivered value (shared finance, shared HR, shared identity, shared integration), and sequenced a consolidation roadmap with transition states that kept each company operable. The conglomerate moved to a smaller number of shared platforms consumed across companies, with exceptions where genuine differentiation existed.

The lesson: post-acquisition duplication is an architecture problem, and consolidation is a capability-based exercise. Consolidating everything to one platform ignores genuine differences; consolidating nothing leaves the cost and incoherence. The capability map let the conglomerate decide what to consolidate (commodity capabilities) and what to leave distinct (differentiators), with a roadmap that sequenced the consolidation safely.

Across the cases, lessons recur. Ambition must be sequenced into survivable steps — big-bangs fail not because the target is wrong but because the path is not. Governance by enablement (paved roads) outperforms governance by gate, because conformance by choice beats conformance by force. Organisational patterns (data ownership, team topology) are as decisive as technical patterns, and adopting the technology without the organisation produces the pattern in name only.

Shared platforms and standards — whether within an enterprise or across government — are what make scale coherent. Point solutions proliferate by default; the architecture must make the shared platform the path of least resistance. And consolidation (post-acquisition, post-proliferation) is a capability-based exercise — consolidate the commodities, leave the differentiators, sequence the transition.

The meta-lesson is that EA's value is measured by adoption, not by elegance. Each case that succeeded succeeded because people used the architecture; each that failed failed because they did not. The technically excellent, unadopted architecture is a failure. The cases teach that the architect's job is to make the architecture the one people choose — through sequencing, enablement, organisation, and shared platforms — not just the one that is technically right.