Fix links to NHS architecture principles

patterns/outsource-bottom-up.md

@@ -15,8 +15,8 @@
 
 - These notes are part of a broader set of [principles](../principles.md)
 - This is related to:
-  - [ARCHITECTURE-CLOUD](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/public-cloud-first)
-  - [ARCHITECTURE-REUSE](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build)
+  - [ARCHITECTURE-CLOUD](https://digital.nhs.uk/developer/architecture/principles/public-cloud-first)
+  - [ARCHITECTURE-REUSE](https://digital.nhs.uk/developer/architecture/principles/reuse-before-buy-build)
 
 ## The pattern
 

practices/cloud-services.md

@@ -10,8 +10,8 @@
 - Practices in this section contribute to [service reliability](service-reliability.md)
 - See also [observability](observability.md)
 - This is related to:
-  - [ARCHITECTURE-CLOUD](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/public-cloud-first)
-  - [ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services)
+  - [ARCHITECTURE-CLOUD](https://digital.nhs.uk/developer/architecture/principles/public-cloud-first)
+  - [ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/developer/architecture/principles/deliver-sustainable-services)
   - [SERVICE-TOOLS](https://service-manual.nhs.uk/service-standard/11-choose-the-right-tools-and-technology)
 
 ## Details

practices/security.md

@@ -102,7 +102,7 @@ The remainder of this page gives more detailed and specific recommendations to b
   - Only allow access for emergencies using a "break glass" pattern, e.g. using Azure AD [Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure)
   - Audit access to production and alert for unexpected access
   - Frequently asked questions:
-    - Q: If I can't access production, how can I check data, for example to respond to a support call? A: one approach is to build a facility (which must be automated, controlled and secured - so likely to be triggered via a pipeline) to clone the production database into a short-lived and isolated copy, so that data can be checked safely without anyone accessing production. Read-replicas can potentially be used instead, but they are (obviously) limited to read-only, and will often consume more cost and energy than on-demand clones ([ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services)). As above, access must be audited and strictly controlled.
+    - Q: If I can't access production, how can I check data, for example to respond to a support call? A: one approach is to build a facility (which must be automated, controlled and secured - so likely to be triggered via a pipeline) to clone the production database into a short-lived and isolated copy, so that data can be checked safely without anyone accessing production. Read-replicas can potentially be used instead, but they are (obviously) limited to read-only, and will often consume more cost and energy than on-demand clones ([ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/developer/architecture/principles/deliver-sustainable-services)). As above, access must be audited and strictly controlled.
     - Q: If I can't access production, how can I update data that is incorrect? A: to update data safely and with confidence, all data changes should be scripted, tested against production data (using a clone, as above) and applied (both for testing and to production) via delivery pipelines rather than via manual updates.
     - Q: If I can't access production, how can I refresh static / reference data? A: as above, one approach is to script the data changes required and apply them via delivery pipelines; another approach is to build a housekeeping facility that refreshes an entire static dataset based on a file (for example CSV or JSON) - if using this approach, access and usage must be audited and strictly controlled.
 - **Secure the route** to infrastructure: all access to infrastructure (production or otherwise) must be via a secured route, for example via a hardened bastion only accessible via a VPN (with MFA challenge), and with an audit of usage.

principles.md

@@ -20,13 +20,13 @@ Waste is anything that interferes with giving customers what they really value a
 
 - **Inventory — partially done work**, e.g. plans and designs, code shelved halfway. Limit work in progress (WIP) and use a pull-based approach.
 
-- **Inventory — [unnecessary resources](practices/cloud-services.md)** [[ARCHITECTURE-SUSTAINABILITY]](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services), e.g. server over-provisioning, complicated tools where simple ones would do. Adopt a "just enough, not just in case" mindset.
+- **Inventory — [unnecessary resources](practices/cloud-services.md)** [[ARCHITECTURE-SUSTAINABILITY]](https://digital.nhs.uk/developer/architecture/principles/deliver-sustainable-services), e.g. server over-provisioning, complicated tools where simple ones would do. Adopt a "just enough, not just in case" mindset.
 
 - **Overproduction — planning or designing in excessive detail.** Requirements change, therefore use a "just enough, just in time" approach to both. Detail should be added as you move to the right in the [cone of uncertainty](http://www.agilenutshell.com/cone_of_uncertainty).
 
 - **Overproduction — overengineering**, i.e. building unnecessary features, unwarranted levels of code perfection or quantities of tests, or premature optimisation. Start simple and prefer explicit logic to implicit. Be pragmatic and balance effort now with saved effort or risk in the future. Remember [KISS](http://principles-wiki.net/principles:keep_it_simple_stupid) and [YAGNI](https://www.martinfowler.com/bliki/Yagni.html) and see the caveats in [structured code](practices/structured-code.md).
 
-- **Overproduction — reinventing the wheel.** Solving the same problem repeatedly in an organisation, or building when you could reuse or buy [[ARCHITECTURE-REUSE]](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build). Make sure there are effective ways to share knowledge between teams to avoid this.
+- **Overproduction — reinventing the wheel.** Solving the same problem repeatedly in an organisation, or building when you could reuse or buy [[ARCHITECTURE-REUSE]](https://digital.nhs.uk/developer/architecture/principles/reuse-before-buy-build). Make sure there are effective ways to share knowledge between teams to avoid this.
 
 - **Extra Processing — due to delayed integration** making merging / reconciliation and testing harder. Use [continuous integration](practices/continuous-integration.md) with frequent merges. When combined with Test-Driven Development, this will allow bugs to be detected early when they are cheap to fix.