Topic 4.0 — Technical Architecture, Cloud & Legacy

In health and care, technical architecture is a clinical-safety, security, and public-money decision made years in advance: the platforms you stand up and the legacy you leave in place quietly determine whether care can be safe, joined-up, and affordable long after the people who chose them have moved on.

Why this matters in health and care#

Architecture is the set of long-lived structural choices beneath your digital services: what runs where, how components connect, what you build versus buy, and what you keep alive from the past. These choices are rarely visible to patients or clinicians, and rarely exciting to boards. Yet they shape everything that sits on top. A well-architected estate lets you add a new service quickly, share data safely, and recover fast when something breaks. A poorly-architected one makes every change slow, every integration fragile, and every incident worse.

In health and care the stakes are high because the systems are consequential. When an aging patient administration system falls over, ambulances divert and clinics cancel. When an unsupported operating system is exploited, confidential records are exposed and services stop — as the NHS learned in 2017 when the WannaCry ransomware attack spread through machines running software that could no longer be patched. That disruption was not a clever, targeted assault; it was the predictable consequence of accumulated technical debt in critical systems. Architecture decisions are therefore safety decisions, whether or not anyone frames them that way.

They are also equity and trust decisions. Legacy systems that cannot share data leave the most complex patients — those touching many services — with the most fragmented records. Closed platforms that lock you into a single supplier drain money that could fund care. And the public reasonably expects the NHS to run on modern, secure, well-maintained technology; the gap between that expectation and the actual estate is itself a risk to trust.

Finally, this is where a great deal of public money is committed for a very long time. The most expensive part of a system is rarely its purchase; it is the decade of hosting, licensing, maintenance, and eventual replacement that follows. Leaders who treat architecture as "something the technical team handles" are delegating some of the largest and longest-lasting financial commitments the organization makes. This topic is written so you can hold those decisions to account without being an engineer.

Core concepts#

Enterprise architecture is the discipline of aligning an organization's business processes, information, applications, and technology so they support strategy coherently rather than growing by accident. It takes the whole-organization view: which capabilities you need, which systems provide them, and where the gaps and duplications lie. Solution architecture is the narrower, project-level discipline of designing how a specific service will be built and fit into the wider estate. Both sit within the broader idea of systems architecture — the structural model of how components, interfaces, and behaviors combine into a working whole. Leaders do not need to practice these disciplines, but they should insist they exist, because their absence is how estates become unmanageable.

Architecture is guided by architecture principles: a short, agreed set of statements — such as "reuse before buy, buy before build" or "build to open standards" — that make consistent decisions possible without every choice being escalated. Principles are enforced, lightly, by a design authority: a small group that reviews significant technical decisions. The healthy version of a design authority enables rather than blocks; it exists to prevent avoidable harm and duplication, not to slow teams down or gatekeep for its own sake.

Cloud computing is the delivery of computing — servers, storage, databases, networking — as an on-demand service over the internet, rather than from hardware you own in your own building. A public cloud is run by a third-party provider and shared among many customers; a private cloud is dedicated to one organization; a hybrid cloud combines the two, often keeping some workloads on existing infrastructure while moving others out. Many governments, including the UK's, have adopted a "cloud-first" policy, meaning teams should consider public cloud before other options and justify not using it. Because cloud is billed by consumption rather than bought once, controlling that spend has become its own discipline — FinOps, the practice of bringing engineering and finance together so teams have visibility of, and accountability for, what their cloud usage actually costs. At the application layer, software as a service (SaaS) delivers a finished application over the web that the supplier hosts and maintains, so you configure rather than run it. Infrastructure and hosting — where and how your systems physically run — sit beneath all of this, and increasingly carry a carbon cost that belongs in the decision (see Topic 8.5 — Sustainability & Net Zero).

A legacy system is an aging but still-relied-upon system that is hard to change, often running unsupported software for which security patches are no longer issued. Legacy accumulates as technical debt — the future cost of expedient choices made in the past. A little debt is normal and even sensible; unmanaged debt at scale becomes a safety and security liability, because the systems most people depend on become the systems no one dares to touch. Managing this is the job of application portfolio management: keeping a clear inventory of every application, its cost, condition, and business value, so you can rationalize the estate — retiring, replacing, or consolidating systems — and decommission safely rather than leaving the old thing quietly running.

Modern estates are held together by application programming interfaces (APIs): defined interfaces through which one system offers a capability to another. Well-designed APIs let you assemble platforms — reusable services that many teams build on — while keeping components loosely coupled and replaceable. A useful discipline here is the "thinnest viable platform": build only the shared capability that genuinely reduces others' work, and no more. Underpinning secure design is secure by design, the principle that security is built in from the start rather than bolted on afterwards. And the financial frame for all of it is total cost of ownership (TCO): the full lifetime cost of a system, not its purchase price — the lens through which the build/buy/configure choice, and the risk of vendor lock-in, should be judged.

Best practices#

1. Agree a short set of architecture principles and use them to decide. Write down a handful of clear, memorable principles — reuse before buy before build, build to open standards, cloud where it makes sense, secure by design, design for the whole care pathway — and let teams make most decisions themselves by applying them. Principles work only if they are genuinely used to say yes and no, and only if there are few enough to remember. This connects directly to Topic 1.1 — The Operating Model and Topic 1.2 — Digital Strategy & Roadmapping, which set the direction the principles serve.

2. Run a design authority that enables rather than blocks. Establish a small, senior, cross-disciplinary group to review significant technical decisions — those that are expensive, hard to reverse, affect many services, or carry safety and security risk. Give it a fast, lightweight route so routine choices are not dragged through it, and hold it to a service standard: it should help teams find a good answer, not simply refuse. A design authority that becomes a bottleneck will be routed around, and shadow architecture is worse than none.

3. Adopt cloud deliberately, workload by workload, not as a slogan. Treat "cloud-first" as a default to be reasoned about, not an instruction to move everything. Assess each workload for suitability, data residency, resilience, cost at scale, and the effort to migrate, and be honest that lift-and-shift of an unchanged legacy application often just relocates the problem at higher cost. Weigh the carbon dimension explicitly, since where and how you host affects emissions (see Topic 8.5 — Sustainability & Net Zero), and design for portability so a future move between providers remains possible.

4. Maintain a live application portfolio and manage technical debt as a named risk. Keep an accurate inventory of every application, its business owner, cost, supportability, and the risk it carries, and review it regularly. Put technical debt and unsupported software on the corporate risk register with the same seriousness as clinical or financial risk, because that is what it is. What you cannot see, you cannot fund, prioritize, or safely retire, and estates that are never inventoried are exactly the ones that fail without warning.

5. Rationalize the estate and decommission safely. Actively retire duplicated, obsolete, and end-of-life systems rather than letting them linger "just in case", because every live system is an attack surface, a license cost, and a maintenance burden. Decommissioning is a project in its own right: migrate or archive the data under clear retention rules, confirm nothing still depends on the system, communicate with users, and verify before you switch off. Done well, rationalization frees money and reduces risk; done carelessly, it destroys records or breaks a dependency no one documented.

6. Prefer open standards, APIs, and loosely coupled components. Design so capabilities are exposed through documented, versioned APIs, so that one component can be replaced without rebuilding everything around it. This is the architectural foundation for the interoperability discussed in Topic 4.3 — Interoperability & Data Standards, and it is your main defense against lock-in. It costs a little more up front than a direct, hard-wired connection, and repays that many times over the first time you need to change a supplier or add a service.

7. Build the thinnest viable platform, and no more. When you create a shared platform for others to build on, resist the urge to make it comprehensive from day one. Provide the smallest reusable capability that genuinely removes work for teams, prove it is used, and grow it in response to real demand. Over-built platforms become their own legacy — expensive, rigid, and resented — while a thin, well-run platform earns adoption and evolves with need.

8. Make security architecture and secure-by-design non-negotiable. Bring security thinking into design from the first sketch, not as a pre-launch gate: minimize the attack surface, apply least privilege, segment networks, and assume components will be probed. In health and care this is inseparable from clinical safety and information governance (Topic 1.6 — Clinical Safety & Risk Management; Topic 1.7 — Information Governance, Data Protection & Cyber Security), because a breach is both a data harm and, when it stops systems, a patient-safety event. Unsupported, unpatchable software is a security decision you are making by default — so make it deliberately, with mitigations, or not at all.

9. Decide build, buy, or configure on total cost of ownership, not sticker price. For each capability, compare building bespoke, buying a product, and configuring an existing platform on their full lifetime cost — hosting, licensing, integration, support, upgrades, and eventual exit — not the initial price. Favor buying or configuring for commodity needs and reserve building for genuine differentiation, and weigh the lock-in each option creates. Work this through with commercial colleagues (Topic 6.3 — Procurement & Commercial), because the cheapest time to secure open interfaces and exit rights is before you sign.

10. Treat cloud spend as a shared engineering-and-finance discipline (FinOps). Give teams clear visibility of what their services cost by tagging cloud resources to owners, right-size instances against real usage, and turn off idle or over-provisioned resources rather than paying for them month after month. Make the teams that run a service accountable for its running cost, so the people best placed to reduce waste are the ones who see the bill. Pay-as-you-go cloud without this discipline quietly consumes budget that should be funding care, and the drift is rarely noticed until an invoice forces the question.

11. Architect for cost as a first-class non-functional requirement, weighed against carbon and resilience. Treat cost the way you treat performance, security, and availability: a property you design for deliberately, estimate before you build, and review as usage grows. Weigh it explicitly against carbon (see Topic 8.5 — Sustainability & Net Zero) and against resilience, because the three often move together — but never chase the lowest bill at the expense of safety, recoverability, or patient outcomes. The right answer is the lowest cost that still meets your clinical-safety and resilience obligations, not the cheapest option in isolation.

Questions to discuss with your team#

1. Which of our critical systems are unsupported or unpatchable today, and what is our actual exposure if one is attacked or fails? Start from the systems clinical and operational services genuinely cannot function without, and establish concretely which run software that no longer receives security updates or vendor support. Ask what would happen — to patients, to staff, to data — if each were hit by ransomware or simply stopped, and how long recovery would take. Distinguish systems you have consciously accepted risk on, with mitigations in place, from those whose fragility no one has assessed. Consider whether this exposure is visible on the corporate risk register or buried in a spreadsheet no board has seen. Reflect on WannaCry: the harm came not from sophistication but from known, unaddressed debt in critical systems. If you cannot answer this with evidence, that gap is itself your most urgent finding, because you cannot fund a risk you have not named.

2. Where are we locked in, and what would it truly cost us to leave our biggest platform? Many organizations discover the real price of a closed system only when they try to change it. Work through what it would actually take to move off your largest clinical or corporate platform: whether you can extract your data in a usable, standard form, what proprietary interfaces would have to be unpicked, and what your contract says about ownership and exit. Consider whether "cloud" has quietly become lock-in of a different kind, with data and tooling so entangled in one provider that leaving is impractical. Weigh this against the openness of alternatives and any national platforms you could reuse instead. This is not an argument for churning suppliers; it is about understanding your leverage before you next negotiate, and not letting one vendor's roadmap silently become your only option.

3. Are we investing enough in maintaining and rationalizing what we already have, or only in the new and visible? New systems attract funding and attention; the unglamorous work of patching, upgrading, consolidating, and safely retiring rarely does, which is exactly how debt accumulates. Ask what proportion of your digital budget actually goes to keeping the existing estate safe and current versus building new things, and whether anyone owns that balance deliberately. Discuss whether decommissioning is ever properly resourced, or whether old systems simply linger because switching them off is nobody's job. Consider the duplicated applications doing the same thing across the organization, and what it would take to consolidate them. Think about who, at board level, is accountable for the health of the estate as a whole rather than for individual projects. An organization that only funds the new is borrowing against its own future safety, and the repayment always comes due at the worst possible moment.

4. Do we actually know what our cloud costs, who owns that bill, and whether the spend is under control? Pay-as-you-go cloud can quietly consume budget that should be funding care, and the drift is rarely noticed until an invoice forces the question. Ask whether cloud resources are tagged to the teams and services that own them, whether anyone right-sizes instances against real usage, and whether idle or over-provisioned resources are ever switched off. Discuss whether the people who run a service see and answer for its running cost, or whether cloud spend lands as a single unexplained line in a central budget no one can decompose. Consider whether cost is treated as a first-class non-functional requirement — estimated before you build and reviewed as usage grows — or only discovered after the fact. Be honest about the tension between engineering autonomy and financial control, and about weighing cost against carbon and resilience rather than simply chasing the lowest bill. An honest answer names who holds the FinOps discipline and shows the evidence that it is working, rather than assuming the cloud is cheaper because it is modern.

5. When we need a new capability, how do we decide between building it, buying it, and configuring something we already have — and on what basis? The instinct to build bespoke, or to buy the product with the best demo, often wins before anyone has compared the full lifetime cost. Work through how your last few significant choices were actually made: whether hosting, licensing, integration, support, upgrades, and eventual exit were weighed, or only the initial price. Ask whether you reserve building for genuine differentiation and default to buying or configuring for commodity needs, or whether custom builds quietly proliferate because a team preferred them. Consider who is in the room for these decisions — commercial and clinical colleagues as well as engineers — and whether the lock-in each option creates is assessed before signing rather than discovered later. Reflect on whether your architecture principles ("reuse before buy, buy before build") genuinely bind these choices or are quietly ignored. An honest answer can point to real decisions where total cost of ownership, not sticker price, changed the outcome.

6. Do we have the in-house architecture capability to hold our own decisions, or are we dependent on the suppliers we are meant to be holding to account? Architecture is where the largest and longest-lasting commitments are made, yet many organizations have hollowed out the very capability needed to make them well, relying on the vendors whose products are under evaluation to tell them what good looks like. Ask whether you have credible enterprise and solution architecture skill on your own side, and whether your design authority is staffed to enable teams or merely to rubber-stamp. Discuss whether significant, hard-to-reverse decisions are genuinely tested against agreed principles, or whether they are effectively delegated to whichever supplier is closest to the problem. Consider how you would even recognize a bad architectural recommendation if you had no independent expertise to challenge it. Weigh the cost of building and retaining this capability against the far larger cost of the lock-in and rework that its absence produces. An honest answer distinguishes the decisions you can genuinely own from those you are currently taking on trust.

In practice: a health & care example#

An acute hospital trust's technical estate has grown organically for two decades. At its heart sits a patient administration system running on an operating system the vendor stopped supporting eighteen months ago; around it are more than two hundred applications, many bought departmentally, several doing overlapping jobs, and no one holds a complete list. A near-miss — a ransomware attempt blocked more by luck than design — prompts the board to ask a question it has never asked before: what, exactly, are we running, and how exposed are we?

The chief digital information officer resists the instinct to launch a single, heroic "replace everything" program, and does the boring work first. The trust builds a live application portfolio: every system, its business owner, its supportability, its cost, and its risk. The picture is sobering — a fifth of applications are on unsupported software, and a dozen duplicate capabilities already available elsewhere — but for the first time it is visible, and the worst exposures go straight onto the corporate risk register where the board can see them.

From that inventory the trust makes deliberate choices guided by a handful of agreed architecture principles. The unsupported patient administration system is prioritized for replacement, procured as a configurable product with contractual open-API and data-extraction rights so the trust is not locked in again. Suitable workloads move to public cloud, assessed one at a time rather than by slogan, with carbon and portability weighed alongside cost. A small design authority reviews the significant decisions and clears the routine ones quickly. Twelve overlapping departmental applications are consolidated to three, and the retired systems are decommissioned properly — data migrated under clear retention rules, dependencies checked, users told, and only then switched off.

None of this makes a headline. But eighteen months on, the trust knows what it runs, its most dangerous debt is being paid down on a funded plan rather than hoped away, and a new shared care record integration is delivered in weeks because the replacement systems expose open APIs. The near-miss became the moment the trust started managing its architecture instead of being managed by it.

Sector lenses#

Startup#

A digital health startup has the luxury of little legacy and should protect it fiercely. Build cloud-native from the outset, expose open APIs, and treat secure-by-design as a core feature rather than a later cost, because cautious NHS buyers will scrutinize your security architecture and data-extraction terms closely. Keep your own thinnest viable platform genuinely thin, resisting the temptation to over-engineer for scale you do not yet have. Your fastest route to accumulating crippling technical debt is shipping expedient code under investor pressure and never paying it back, so make deliberate, visible choices about what debt you take on. Paradoxically, designing so a customer could extract their data and leave is what earns the trust that keeps them.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, a single-site clinic, or a small health-tech supplier past the startup stage — carries the same duties as a large trust but with a fraction of the resources and rarely any dedicated IT capability. Here architecture is mostly the discipline of buying well: favor reputable software-as-a-service so the supplier carries the hosting, patching, and security you cannot staff yourself, and read the contract for data-extraction and exit rights before you sign, because lock-in bites hardest when you have no leverage. Keep a simple inventory of the handful of systems you depend on and know which are still supported, since even a small estate can hide an unpatched machine that stops the practice. Insist that suppliers meet recognized standards such as the Data Security and Protection Toolkit rather than trying to assess security from scratch. When cash is tight the temptation is to keep an old, unsupported system running to avoid a bill, but that is a safety decision you should make deliberately, not by drift.

Enterprise#

A large trust or supplier carries decades of accumulated systems and cannot simply start again. The realistic strategy is disciplined evolution: maintain a live portfolio, put open, API-based layers in front of what must stay, and pay down the most dangerous debt on a funded, prioritized plan rather than in occasional panics. Run a design authority that is respected because it enables delivery, not feared because it blocks it, and make technical debt a standing board-level risk with a named owner. Guard against lock-in at every renewal, and treat decommissioning as real, resourced work rather than an afterthought. This is the same reuse-and-open-interface discipline that governs core operational platforms in Topic 5.4 — Enterprise Resource Planning (ERP).

Government#

National and regional bodies set the conditions the whole sector operates in, and their architecture choices ripple outward. The most valuable things government can do are mandate open standards, provide reusable national platforms so local organizations build once, and set cloud, security, and sustainability expectations that raise the floor everywhere. Crucially, government must fund the unglamorous national work — legacy remediation, terminology maintenance, decommissioning support — that no single organization will finance alone but that everyone depends on. A firmly-enforced, good-enough standard reused widely beats a theoretically superior one implemented inconsistently. This stewardship role connects to Topic 9.1 — Working with Local & National Governments and to how partners collaborate in Topic 9.0 — Collaborating with Partner Organizations.

Common failure modes#

• Invisible estate. Running hundreds of applications with no accurate inventory, so exposure is unknown, duplication is unnoticed, and the first sign of fragility is an outage or a breach.
• Debt hidden from the board. Keeping unsupported software and technical debt as a technical footnote rather than a named corporate risk, so it is never funded until it fails.
• Cloud as slogan. Lifting and shifting unchanged legacy into public cloud on principle, relocating the problem at higher cost, or entangling data and tooling so deeply in one provider that it becomes a new lock-in.
• Design authority as bottleneck. Letting architecture governance become a slow gate that teams route around, producing undocumented shadow architecture that is worse than none.
• Build when you should configure. Choosing bespoke builds for commodity needs, on sticker price rather than total cost of ownership, and inheriting a decade of maintenance you did not budget for.
• Never decommissioning. Leaving obsolete systems running "just in case", each one an attack surface, a license cost, and a maintenance drain no one owns.
• Security bolted on. Treating security as a pre-launch gate rather than a design input, so the attack surface is set long before anyone assesses it.
• Lock-in by default. Signing platforms with no open interfaces or data-extraction rights, and discovering the cost of the trap only when you try to leave.

Maturity model#

Checklist#

• A live application portfolio records every system's owner, cost, supportability, and risk, and is reviewed regularly.
• Unsupported and unpatchable critical systems are identified and sit on the corporate risk register, not in a technical spreadsheet.
• A short, agreed set of architecture principles is genuinely used to make and justify decisions.
• A design authority reviews significant, hard-to-reverse decisions and clears routine ones quickly, enabling rather than blocking.
• Cloud adoption is assessed workload by workload, weighing residency, resilience, cost, portability, and carbon.
• Technical debt has a named owner and a funded remediation plan, not just occasional firefighting.
• Duplicated and obsolete systems are rationalized, and decommissioning is resourced with data migration, retention, and dependency checks.
• New capabilities expose open, versioned APIs so components can be replaced without rebuilding around them.
• Security is designed in from the start — minimal attack surface, least privilege, segmentation — not bolted on before launch.
• Build/buy/configure decisions are made on total cost of ownership and lock-in, with exit and data-extraction rights secured before signing.

Key sources#

• NHS England — cloud strategy, technology standards, and the Data Security and Protection Toolkit.
• National Cyber Security Centre (NCSC) — secure design principles and cloud security guidance.
• UK Government (GDS/CDDO) — the Technology Code of Practice and cloud-first policy.
• National Audit Office — reports on NHS legacy systems, the WannaCry attack, and IT-enabled programmes.
• The Open Group — TOGAF, the enterprise architecture framework.
• Government Digital Service — the "thinnest viable platform" concept in the GOV.UK service manual and design community.

References#

1. Enterprise architecture — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_architecture
2. Solution architecture — Wikipedia — https://en.wikipedia.org/wiki/Solution_architecture
3. Systems architecture — Wikipedia — https://en.wikipedia.org/wiki/Systems_architecture
4. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
5. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
6. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
8. Application portfolio management — Wikipedia — https://en.wikipedia.org/wiki/Application_portfolio_management
9. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
10. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
11. Secure by design — Wikipedia — https://en.wikipedia.org/wiki/Secure_by_design
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Cloud strategy — NHS England — https://www.england.nhs.uk/long-read/cloud-centre-of-excellence/
14. Secure design principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-security-design-principles
15. Technology Code of Practice — UK Government (CDDO) — https://www.gov.uk/guidance/the-technology-code-of-practice
16. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
17. TOGAF Standard — The Open Group — https://www.opengroup.org/togaf
18. Service Manual: cloud and platforms — Government Digital Service — https://www.gov.uk/service-manual