# Solution Architecture Health Check: [Solution name]

> Periodic health check of one solution in production, across every
> architecture dimension: fit with the business drivers it was built
> for, quality attribute and NFR drift, reliability, security, cost and
> sustainability, performance and capacity, operability, technology
> lifecycle, technical debt, data, documentation and team ownership. Each
> dimension gets an evidence-based score, the scores roll up into a
> weighted index and a trend, and the findings become a prioritised
> action list. Provider-neutral, with a mapping to the pillars of the AWS
> Well-Architected Framework (6 pillars), the Azure Well-Architected
> Framework (5 pillars) and the Google Cloud Well-Architected Framework
> (6 pillars), and quality characteristics named as in ISO/IEC
> 25010:2023. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- A health check is a light, repeatable scan of a running solution, done
  on a fixed cadence (often yearly, or before a major investment or
  contract renewal). It finds where the solution is drifting so you can
  act before an incident or an audit does it for you.
- It is wider and shallower than a provider review. For a deep
  pillar-by-pillar review of one cloud workload use the Cloud
  Architecture Review (`architecture/cloud-architecture-review`) or the
  provider-specific reviews (`architecture/aws-well-architected-review`,
  `architecture/azure-well-architected-review`,
  `architecture/google-well-architected-review`). Link their results here
  instead of repeating them.
- Fill in this order: 2 (scope and scoring) -> 3 (drivers) -> 4 to 14
  (one dimension each, evidence first, score last) -> 15 (scorecard) ->
  16 (findings and actions) -> 17 (trend) -> 1 (summary, written last).
- Score on evidence you can show. "The team believes it is fine" scores
  as "not evidenced", which is a 1.
- The worked example is the second annual check (month 24) of the
  fictional insurer's customer data hub, compared with the first check
  at month 12.
-->

## Document control

<!-- Guidance: Identify the solution, the check and the previous check it is compared with. Keep each check as a dated version so the trend in section 17 can be traced. -->

| Field | Value |
|---|---|
| Document ID | [AHC-SOLUTION-YYYY] |
| Solution | [Solution name, service ID in the CMDB] |
| Service owner | [@service-owner] |
| Check number | [n, e.g. 2nd annual check] |
| Previous check | [AHC-SOLUTION-YYYY, date] |
| Check period | YYYY-MM-DD to YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner (lead reviewer) | [@lead-reviewer] |
| Approvers / reviewers | [Service owner, domain architect, security architect, FinOps lead] |
| Hosting | [Provider and region, or on-premises site] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Conditions | Date |
|---|---|---|---|---|
| Lead reviewer | [@lead-reviewer] | [Submitted] | [None] | YYYY-MM-DD |
| Service owner | [@service-owner] | [Accepts findings and actions] | [Conditions] | YYYY-MM-DD |
| Domain architect | [@architect] | [Agreed] | [Conditions] | YYYY-MM-DD |
| Security architect | [@security] | [Agreed] | [Conditions] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Scope, inputs requested, previous scores copied for comparison |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Evidence reviewed in a two-hour session with the service team; scores drafted |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Accepted by service owner; actions HC-ACT-01 to HC-ACT-08 opened |

## Contents

1. [Health summary](#1-health-summary)
2. [Scope, cadence and method](#2-scope-cadence-and-method)
3. [Solution context and original drivers](#3-solution-context-and-original-drivers)
4. [Quality attributes and NFR drift](#4-quality-attributes-and-nfr-drift)
5. [Reliability and resilience](#5-reliability-and-resilience)
6. [Security posture](#6-security-posture)
7. [Cost and sustainability](#7-cost-and-sustainability)
8. [Performance and capacity](#8-performance-and-capacity)
9. [Operability](#9-operability)
10. [Technology lifecycle and dependencies](#10-technology-lifecycle-and-dependencies)
11. [Technical debt and architecture erosion](#11-technical-debt-and-architecture-erosion)
12. [Data health](#12-data-health)
13. [Documentation and decision currency](#13-documentation-and-decision-currency)
14. [Team, ownership and skills](#14-team-ownership-and-skills)
15. [Scorecard and framework mapping](#15-scorecard-and-framework-mapping)
16. [Findings and prioritised actions](#16-findings-and-prioritised-actions)
17. [Trend and next check](#17-trend-and-next-check)
18. [Glossary and references](#18-glossary-and-references)

## 1. Health summary

<!-- Guidance: One screen for the service owner and portfolio board: the index, the trend, the red dimensions and the three actions that matter most. Write it last. Pitfall: reporting the index alone; a stable index can hide one dimension collapsing. -->

| Item | Result |
|---|---|
| Health index (0 to 100) | *Example:* 62.5 (previous check 62.5) |
| Overall status | *Example:* Amber |
| Red dimensions (score 0 or 1) | *Example:* D8 Technology lifecycle |
| Improved since last check | *Example:* D3 Reliability, D6 Operability |
| Declined since last check | *Example:* D7 Performance and capacity, D8 Technology lifecycle, D11 Documentation |
| Findings | *Example:* 9 (2 high, 4 medium, 3 low) |
| Top actions | *Example:* HC-ACT-01 database engine upgrade; HC-ACT-02 capacity plan for API growth; HC-ACT-03 retire CRM export |
| Decision requested | [Fund HC-ACT-01 in the next quarter; accept the remaining actions] |

*Example narrative:* The hub still serves its purpose and its
reliability has improved since the dead-letter runbook and certificate
automation landed. The index is flat because three dimensions declined by
as much as two improved: the database engine version leaves vendor support
in two months, and API traffic has grown to 92% of design capacity. Both
are predictable and fixable this quarter.

## 2. Scope, cadence and method

<!-- Guidance: Say what is checked, how often, from which evidence, and how scores are given and combined, so the next reviewer can repeat the check and compare. Pitfall: changing weights or the scale between checks, which breaks the trend; if you must change them, recompute the previous index. -->

### 2.1 Scope

| Item | In scope | Out of scope |
|---|---|---|
| Components | *Example:* Hub store, matching service, customer API, event publication, stewardship user interface | Consuming systems |
| Environments | *Example:* Production; disaster recovery region; pre-production for release process only | Developer sandboxes |
| Shared platforms | *Example:* Used as delivered; only their effect on this solution is checked | Platform internals (own checks) |

### 2.2 Cadence and triggers

| Trigger | Check type |
|---|---|
| Fixed cadence: *Example:* every 12 months from the first PIR | Full check, all dimensions |
| Before a contract renewal, major investment or re-platform decision | Full check |
| After a P1 incident with architectural cause | Targeted check on the affected dimensions |
| When a dependency reaches end of support within [6] months | Targeted check on D8 |
| A dimension scored 0 or 1 at the last check | Follow-up on that dimension after [3] months |

### 2.3 Inputs

| Input | Source |
|---|---|
| Original drivers, KPIs and NFRs | Architecture vision, quality attribute record, Architecture Contract |
| Service data for the period | Monitoring, incident and problem records, SLO reports |
| Cost data | Cloud billing and FinOps reports, licence and support invoices |
| Inventory and versions | Configuration management database, software bill of materials, infrastructure as code |
| Security data | Vulnerability scans, access reviews, penetration test, risk register |
| Previous checks and reviews | Previous health check, PIR, provider review results, compliance assessments |
| Team view | A structured session with the service team, [60 to 120] minutes |

### 2.4 Scoring scale

This scale is original to this template.

| Score | Label | Meaning |
|---|---|---|
| 4 | Strong | Meets or exceeds expectations with evidence; improving practices in place |
| 3 | Adequate | Meets expectations with evidence; minor gaps only |
| 2 | Weak | Noticeable gaps; risk is growing but not yet urgent |
| 1 | Poor | Serious gaps, or claims without evidence; action needed this quarter |
| 0 | Critical | Immediate risk to the service, its data or compliance |

### 2.5 Weights and roll-up

Set weights once per solution class and keep them between checks. The
health index is the weighted sum of scores divided by the maximum
possible weighted sum, times 100.

| Dimension | Weight *(Example)* |
|---|---|
| D1 Business fit | 10 |
| D2 Quality attributes and NFRs | 10 |
| D3 Reliability and resilience | 10 |
| D4 Security | 15 |
| D5 Cost | 10 |
| D6 Operability | 10 |
| D7 Performance and capacity | 5 |
| D8 Technology lifecycle | 10 |
| D9 Technical debt | 5 |
| D10 Data health | 5 |
| D11 Documentation and decisions | 5 |
| D12 Team and ownership | 3 |
| D13 Sustainability | 2 |
| **Total** | **100** |

Sections 3 to 14 hold the evidence for each dimension, and section
numbers do not follow dimension numbers: D1 in section 3, D2 in 4, D3
in 5, D4 in 6, D5 and D13 in 7, D7 in 8, D6 in 9, D8 in 10, D9 in 11,
D10 in 12, D11 in 13 and D12 in 14. Cite findings by dimension ID, not
by section number.

Status rules: *Example:* green when the index is at least 75 and no
dimension scores below 2; red when the index is below 50 or any
dimension scores 0; amber otherwise. Each dimension also carries its own
status: 3 or 4 green, 2 amber, 0 or 1 red. Any red dimension is reported
in section 1 whatever the index.

## 3. Solution context and original drivers

<!-- Guidance: Restate what the solution was built to do and check whether those drivers still hold. A solution can be technically healthy and strategically obsolete. Pitfall: skipping this section because "nothing has changed"; ask the business owner, not the team. -->

| Driver or goal | Original target | Still valid? | Current evidence | Note |
|---|---|---|---|---|
| BG-02 *(Example)* One trusted view of the customer | Golden ID for 98% of customers | Yes | 98.3% at month 24 | Reached after policy system C cleansing |
| BG-03 *(Example)* Lower cost to serve | Steward correction hours below 150 per month | Yes | 120 per month | |
| *Example:* Customer data for all channels | 5 consuming systems | Changed: now 8 planned, incl. two AI assistants | 6 live | Load growth drives D7 |
| [Driver] | [Target] | [Yes / Changed / No] | [Evidence] | [Note] |

**D1 Business fit score:** *Example:* 3. Drivers hold and targets are
met; new consumers were not foreseen in the design and need capacity
work.

## 4. Quality attributes and NFR drift

<!-- Guidance: Compare each quality attribute target with production evidence for the period, and note where the target itself is now wrong. Use the ISO/IEC 25010:2023 characteristic names so the record lines up with the quality attribute template. Pitfall: re-using last year's test results as current evidence. -->

| Characteristic (ISO/IEC 25010:2023) | Requirement | Target | Evidence this period | Drift | Note |
|---|---|---|---|---|---|
| Performance efficiency *(Example)* | NFR-PERF-01 API latency p95 | At most 300 ms | 285 ms, rising from 240 ms | Toward limit | Load growth |
| Reliability *(Example)* | Customer API availability | 99.9% per month | 99.95% average; no month below target | Improved | |
| Security *(Example)* | NFR-SEC-01 personal data past retention | 0 records | 0 in all audits | None | |
| Compatibility *(Example)* | Event schema backward compatible | No breaking change without a new version | One breaking change shipped as minor version | Drift | FND-HC-06 |
| Maintainability *(Example)* | Lead time for a matching rule change | Under 5 days | 9 days median | Drift | Single expert (D12) |
| Flexibility *(Example)* | Scale out without code change | Horizontal scaling by configuration | Confirmed in load test | None | |
| Interaction capability *(Example)* | Steward task completion without help | 95% | 96% | None | |
| Functional suitability *(Example)* | Match decisions correct on audit sample | At least 99% | 99.2% | None | |
| Safety *(Example)* | Not significant for this solution | Not applicable | Not applicable | Not applicable | No physical effect |
| [Characteristic] | [Requirement ID] | [Target] | [Evidence] | [None / Toward limit / Drift / Improved] | [Note] |

**D2 Quality attributes score:** *Example:* 3. Most targets met; two
drifts with known causes. Record target changes in the quality attribute
record (`requirements/quality-attributes`).

## 5. Reliability and resilience

<!-- Guidance: Look at incidents, recovery tests and single points of failure for the period. A recovery plan that was not tested in the period scores no higher than 2. Pitfall: counting uptime only and ignoring whether recovery would work in a real regional failure. -->

| Check | Evidence | Result |
|---|---|---|
| Recovery test in the period, against RTO and RPO | *Example:* Regional failover test YYYY-MM-DD: RTO 2 h 10 min against 4 h; RPO 9 min against 15 min | Met |
| Backup restore test | *Example:* Quarterly restore of a full snapshot; last one YYYY-MM-DD | Met |
| P1 and P2 incidents with architectural cause | *Example:* 0 P1, 2 P2 (both consumer-side retries) | Acceptable |
| Known single points of failure | *Example:* Matching rule deployment needs one named engineer (see D12) | Open |
| Dependency failure handling | *Example:* Circuit breakers on policy system calls; tested in a game day | Met |
| [Check] | [Evidence] | [Result] |

**D3 Reliability and resilience score:** *Example:* 3 (previous 2).
Improved after automated certificate renewal and the tested dead-letter
runbook. Use the DR plan (`ops/disaster-recovery-plan`) and game days
(`ops/game-day-plan`) for detail.

## 6. Security posture

<!-- Guidance: Check that the designed controls still operate and that the threat model still matches the solution. New consumers, new data and new integrations since the last check are the usual source of gaps. Pitfall: treating a clean vulnerability scan as a clean security posture. -->

| Check | Evidence | Result |
|---|---|---|
| Threat model updated for changes in the period | *Example:* Updated for the two AI assistant consumers YYYY-MM-DD | Met |
| Vulnerabilities past remediation target | *Example:* 0 critical, 2 high past 30 days (both in the ageing database engine) | Gap |
| Access reviews completed and leavers removed on time | *Example:* 4 of 4 quarterly reviews; leaver removal within 1 day since automation | Met |
| Secrets and keys rotated as scheduled | *Example:* Yes, through the key service | Met |
| Penetration test in the last 12 months | *Example:* YYYY-MM-DD; 1 medium finding fixed | Met |
| Accepted risks reviewed by their due date | *Example:* All reviewed | Met |
| [Check] | [Evidence] | [Result] |

**D4 Security score:** *Example:* 3. Controls operate; the two high
vulnerabilities are tied to the lifecycle finding in D8. Detail lives in
the security architecture (`security/security-architecture`) and threat
model (`security/threat-model`).

## 7. Cost and sustainability

<!-- Guidance: Compare run cost with the estimate and with demand, using unit cost rather than totals, and look for waste. Record sustainability measures where the organisation tracks them. Pitfall: flagging rising total cost when unit cost is falling; growth is not waste. -->

### 7.1 Cost

| Measure | Previous check | This check | Trend | Note |
|---|---|---|---|---|
| Annual run cost (USD) *(Example)* | 214,000 | 236,000 | +10.3% | Traffic up 45% |
| Cost per 1,000 API calls (USD) *(Example)* | 0.46 | 0.35 | Down 24% | Micro-batch matching (decision ADR-027) |
| Idle or unattached resources (USD per year) *(Example)* | 9,000 | 14,000 | Up | Unused pre-production replicas |
| Commitment coverage *(Example)* | 40% | 40% | Flat | Renewal due; reconsider level |
| [Measure] | [Value] | [Value] | [Trend] | [Note] |

**D5 Cost score:** *Example:* 2. Unit cost improved, but idle resources
grew and commitments were not reviewed. Use the FinOps review
(`ops/finops-cost-review`) for the full analysis.

### 7.2 Sustainability

| Measure | This check | Note |
|---|---|---|
| Provider carbon or emissions report available for this workload *(Example)* | Yes, monthly | Location-based figures only |
| Non-production environments scheduled off outside working hours *(Example)* | Partly | Pre-production runs all week |
| Data stored past its business need *(Example)* | None found | Retention enforced (D10) |
| [Measure] | [Value] | [Note] |

**D13 Sustainability score:** *Example:* 2. For a fuller assessment use
the sustainability architecture assessment
(`architecture/sustainability-architecture-assessment`).

## 8. Performance and capacity

<!-- Guidance: Compare current and forecast demand with the design capacity, and check that the scaling assumptions still hold. Pitfall: waiting for latency to breach its target; headroom below about a quarter of capacity is already a finding. -->

| Measure | Design capacity | Previous check | This check | Forecast in 12 months | Headroom now |
|---|---|---|---|---|---|
| Peak API requests per second *(Example)* | 400 | 310 | 368 | 450 | 8% |
| Events per hour at peak *(Example)* | 500,000 | 180,000 | 260,000 | 340,000 | 48% |
| Hub storage (TB) *(Example)* | 4.0 | 1.6 | 2.1 | 2.6 | 48% |
| [Measure] | [Capacity] | [Value] | [Value] | [Forecast] | [%] |

Headroom is (design capacity minus current peak) divided by design
capacity: *Example:* API (400 minus 368) divided by 400 equals 8%.

**D7 Performance and capacity score:** *Example:* 2 (previous 3). The
API will exceed its design capacity within the year at the current
growth. Update the capacity plan (`ops/capacity-plan`).

## 9. Operability

<!-- Guidance: Check whether the operating team can run, change and recover the solution without heroics: runbooks, alerts, release process and toil. Pitfall: measuring only incident counts; high toil and noisy alerts predict the next incident. -->

| Check | Evidence | Result |
|---|---|---|
| Runbooks current for every alert that pages | *Example:* 22 of 23; one new alert lacks a runbook | Minor gap |
| Alert noise | *Example:* 6% of pages were not actionable (previous 18%) | Improved |
| Change failure rate | *Example:* 7% | Met |
| Deployment frequency and lead time | *Example:* Weekly; 2 days from merge to production | Met |
| Toil (manual recurring work) | *Example:* 6 hours per week, down from 14 | Improved |
| SLO reporting to the service owner | *Example:* Monthly, automated | Met |
| [Check] | [Evidence] | [Result] |

**D6 Operability score:** *Example:* 3 (previous 2). See the observability
spec (`ops/observability-spec`) and runbook (`dev/runbook`).

## 10. Technology lifecycle and dependencies

<!-- Guidance: List every product, runtime, library and managed service the solution depends on with its version and vendor support end date. Anything that leaves support within the next planning horizon is a finding now. Pitfall: tracking only the main products; transitive libraries and base images age just as fast. -->

| Component | Type | Version in production | Latest supported | Support ends | Status | Action |
|---|---|---|---|---|---|---|
| *Example:* Relational database engine | Managed service | [major.minor] | [major.minor] | YYYY-MM-DD (in 2 months) | Red | HC-ACT-01 |
| *Example:* Application runtime | Runtime | [version] | [version] | YYYY-MM-DD (in 10 months) | Amber | Plan upgrade |
| *Example:* Matching library | Library | [version] | [version] | Vendor supported | Green | None |
| *Example:* Container base image | Image | [tag] | [tag] | Rebuilt weekly | Green | None |
| *Example:* Stewardship UI framework | Library | [version] | [version] | YYYY-MM-DD (passed) | Red | HC-ACT-04 |
| [Component] | [Type] | [Version] | [Version] | YYYY-MM-DD | [Green / Amber / Red] | [Action] |

Status rule: *Example:* red when support ends within [3] months or has
passed, amber within [12] months, green otherwise. Keep the inventory in
the software bill of materials (`security/supply-chain-security`) and
check the radar status of each product (`architecture/tech-radar`).

**D8 Technology lifecycle score:** *Example:* 1 (previous 2). The
database upgrade flagged at design review was deferred twice.

## 11. Technical debt and architecture erosion

<!-- Guidance: Review the debt register for this solution, look for new erosion (shortcuts, bypassed layers, undocumented interfaces), and check that dispensations are closing. Pitfall: treating the debt register as the full picture; erosion is often found only by comparing the as-built inventory with the approved design. -->

| Item | Previous check | This check | Note |
|---|---|---|---|
| Open debt items for this solution *(Example)* | 5 | 4 | TD-032 (replica read) closed |
| Total estimated interest, hours per month *(Example)* | 46 | 38 | |
| Active dispensations *(Example)* | 1 (DSP-2026-09) | 1, renewed once and then extended by executive decision | CRM export; expires in 3 months; the executive has said it will not renew again |
| Undocumented interfaces found *(Example)* | 1 | 0 | |
| Components or flows not in the approved models *(Example)* | 2 | 1 | Ad hoc export script for audit |
| [Item] | [Value] | [Value] | [Note] |

**D9 Technical debt score:** *Example:* 2. Debt falls, but the CRM
dispensation has been renewed once by the board and once by the
executive (charter section 8.1), and the executive has said it will not
renew it again. See
the tech debt register (`architecture/tech-debt-register`) and fitness
functions (`architecture/fitness-functions`).

## 12. Data health

<!-- Guidance: Check data quality, ownership, retention and lineage for the data the solution masters or holds. Pitfall: reporting data quality scores without saying which entities and rules they cover. -->

| Check | Evidence | Result |
|---|---|---|
| Data quality rules and scores for mastered entities | *Example:* 34 rules; 98.3% golden ID coverage; duplicate rate 1.1% | Met |
| Owners and stewards named and active | *Example:* All entities; one steward vacancy | Minor gap |
| Retention and deletion enforced | *Example:* Monthly job; 0 overdue records | Met |
| Lineage complete from sources | *Example:* All three sources recorded | Met |
| Data shared with new consumers under an agreed purpose | *Example:* AI assistants use a minimised view under DPIA update | Met |
| [Check] | [Evidence] | [Result] |

**D10 Data health score:** *Example:* 3. See the data dictionary
(`architecture/data-dictionary`).

## 13. Documentation and decision currency

<!-- Guidance: Check whether someone new could understand, change and run the solution from its records: models, decision records, runbooks and interface specifications, each dated and matching production. Pitfall: counting documents instead of checking that they match what runs. -->

| Record | Last updated | Matches production? | Note |
|---|---|---|---|
| Solution design and as-built models *(Example)* | 14 months ago | No | AI assistant consumers missing |
| Decision records *(Example)* | Last ADR 3 months ago | Yes | 4 new ADRs this period |
| Interface specifications *(Example)* | Current | Partly | Event schema change not versioned (FND-HC-06) |
| Runbooks *(Example)* | Current | Yes, except one | See D6 |
| Architecture repository entry *(Example)* | 14 months ago | No | Update with models |
| [Record] | [Date] | [Yes / Partly / No] | [Note] |

**D11 Documentation and decisions score:** *Example:* 2 (previous 3).
Use the decision log (`architecture/architecture-decision-log`) and C4
models (`architecture/c4-architecture`) to bring records up to date.

## 14. Team, ownership and skills

<!-- Guidance: Check that the solution has a named owner, a funded team and enough people who can change and recover it. Pitfall: ignoring key-person risk because nothing has gone wrong yet. -->

| Check | Evidence | Result |
|---|---|---|
| Named service owner and product owner | *Example:* Both named and active | Met |
| People able to change matching rules | *Example:* 1 (target 2) | Gap |
| People able to run a regional failover | *Example:* 4 | Met |
| Funded roadmap for the next 12 months | *Example:* Yes, including capacity work | Met |
| Supplier knowledge dependency | *Example:* Matching library support by supplier; contract renews in 8 months | Watch |
| [Check] | [Evidence] | [Result] |

**D12 Team and ownership score:** *Example:* 2.

## 15. Scorecard and framework mapping

<!-- Guidance: Bring the scores together, show the arithmetic, and map each dimension to the pillars of the provider framework the organisation uses, so the results can be compared with provider reviews. Pitfall: mixing provider pillar names; Azure has five pillars and treats sustainability as workload guidance, Google names its pillars differently from AWS. -->

### 15.1 Scorecard

| Dimension | Weight | Previous score | Score | Weighted score | Status |
|---|---|---|---|---|---|
| D1 Business fit *(Example)* | 10 | 3 | 3 | 30 | Green |
| D2 Quality attributes and NFRs *(Example)* | 10 | 3 | 3 | 30 | Green |
| D3 Reliability and resilience *(Example)* | 10 | 2 | 3 | 30 | Green |
| D4 Security *(Example)* | 15 | 3 | 3 | 45 | Green |
| D5 Cost *(Example)* | 10 | 2 | 2 | 20 | Amber |
| D6 Operability *(Example)* | 10 | 2 | 3 | 30 | Green |
| D7 Performance and capacity *(Example)* | 5 | 3 | 2 | 10 | Amber |
| D8 Technology lifecycle *(Example)* | 10 | 2 | 1 | 10 | Red |
| D9 Technical debt *(Example)* | 5 | 2 | 2 | 10 | Amber |
| D10 Data health *(Example)* | 5 | 3 | 3 | 15 | Green |
| D11 Documentation and decisions *(Example)* | 5 | 3 | 2 | 10 | Amber |
| D12 Team and ownership *(Example)* | 3 | 2 | 2 | 6 | Amber |
| D13 Sustainability *(Example)* | 2 | 2 | 2 | 4 | Amber |
| **Total** | **100** | | | **250** | |

Arithmetic: maximum weighted sum is 100 times 4, which is 400. Health
index equals 250 divided by 400, times 100, which is 62.5. The previous
scores column, with the same weights, also sums to 250, so the previous
index was also 62.5. Status: amber, because the index
is between 50 and 75 and D8 scores 1.

### 15.2 Mapping to provider frameworks

| Dimension | AWS Well-Architected pillar | Azure Well-Architected pillar | Google Cloud Well-Architected pillar |
|---|---|---|---|
| D3 Reliability and resilience | Reliability | Reliability | Reliability |
| D4 Security | Security | Security | Security, privacy, and compliance |
| D5 Cost | Cost optimization | Cost Optimization | Cost optimization |
| D6 Operability | Operational excellence | Operational Excellence | Operational excellence |
| D7 Performance and capacity | Performance efficiency | Performance Efficiency | Performance optimization |
| D13 Sustainability | Sustainability | No pillar: sustainability workload guidance | Sustainability |
| D1, D2, D8 to D12 | No direct pillar; partly covered across pillars | No direct pillar | No direct pillar |

Where a provider review was run in the period, enter its high-risk count
next to the matching dimension and explain any difference in score.

## 16. Findings and prioritised actions

<!-- Guidance: One finding per problem, with the dimension, severity, the action, an owner and a date. Order by severity and then by cost of delay. Pitfall: findings without owners, which reappear unchanged at the next check. -->

### 16.1 Findings

| Finding ID | Dimension | Severity | Finding | Action |
|---|---|---|---|---|
| FND-HC-01 *(Example)* | D8 | High | Database engine leaves vendor support in 2 months; upgrade deferred twice | HC-ACT-01 |
| FND-HC-02 *(Example)* | D7 | High | API at 92% of design capacity; forecast exceeds it within 12 months | HC-ACT-02 |
| FND-HC-03 *(Example)* | D9 | Medium | CRM export dispensation expires in 3 months; the executive will not renew it again | HC-ACT-03 |
| FND-HC-04 *(Example)* | D8 | Medium | Stewardship UI framework past end of support | HC-ACT-04 |
| FND-HC-05 *(Example)* | D12 | Medium | One person can change matching rules | HC-ACT-05 |
| FND-HC-06 *(Example)* | D2, D11 | Medium | Breaking event schema change released as a minor version | HC-ACT-06 |
| FND-HC-07 *(Example)* | D5 | Low | Idle pre-production replicas cost about USD 14,000 a year | HC-ACT-07 |
| FND-HC-08 *(Example)* | D11 | Low | As-built models 14 months old | HC-ACT-08 |
| FND-HC-09 *(Example)* | D6 | Low | One paging alert without a runbook | HC-ACT-08 |
| [FND-HC-nn] | [Dn] | [High / Medium / Low] | [Finding] | [HC-ACT-nn] |

### 16.2 Action plan

| Action ID | Action | Owner | Due | Effort | Status |
|---|---|---|---|---|---|
| HC-ACT-01 *(Example)* | Upgrade the database engine to a supported version, with rehearsal in pre-production | [@platform-lead] | YYYY-MM-DD (before support ends) | [n] person-weeks | Open |
| HC-ACT-02 *(Example)* | Revise the capacity plan and scale the API tier; add a headroom alert at 75% | [@sre-lead] | YYYY-MM-DD | [n] person-weeks | Open |
| HC-ACT-03 *(Example)* | Present the CRM retirement decision to the board before the dispensation expires | [@service-owner] | YYYY-MM-DD | Decision | Open |
| HC-ACT-04 *(Example)* | Upgrade the stewardship UI framework | [@dev-lead] | YYYY-MM-DD | [n] person-weeks | Open |
| HC-ACT-05 *(Example)* | Train a second engineer on matching rules and pair on the next two changes | [@service-owner] | YYYY-MM-DD | [n] days | Open |
| HC-ACT-06 *(Example)* | Add a schema compatibility check to the pipeline | [@integration-lead] | YYYY-MM-DD | [n] days | Open |
| HC-ACT-07 *(Example)* | Schedule pre-production replicas off outside test windows | [@finops-lead] | YYYY-MM-DD | [n] days | Open |
| HC-ACT-08 *(Example)* | Refresh as-built models and write the missing runbook | [@solution-architect] | YYYY-MM-DD | [n] days | Open |
| [HC-ACT-nn] | [Action] | [@owner] | YYYY-MM-DD | [Effort] | [Open / Done] |

Large or cross-team actions go to the architecture roadmap
(`architecture/architecture-roadmap-transition`); changes that alter the
approved architecture need a change request
(`architecture/architecture-change-request`).

## 17. Trend and next check

<!-- Guidance: Show how the solution's health moves over time and set the date and focus of the next check. A trend over three or more checks is more useful than any single score. Pitfall: no next date, which turns the health check into a one-off audit. -->

```mermaid
xychart-beta
  title "Health index by check (Example)"
  x-axis ["PIR baseline", "Check 1 (month 12)", "Check 2 (month 24)"]
  y-axis "Index" 0 --> 100
  bar [55, 62.5, 62.5]
```

| Check | Date | Index | Red dimensions | Note |
|---|---|---|---|---|
| PIR baseline *(Example)* | YYYY-MM-DD | 55.0 | D9 | Scored retrospectively from the PIR evidence |
| Check 1 *(Example)* | YYYY-MM-DD | 62.5 | None | |
| Check 2 *(Example)* | YYYY-MM-DD | 62.5 | D8 | This document |
| [Check n] | YYYY-MM-DD | [Index] | [Dn] | [Note] |

| Item | Decision |
|---|---|
| Next full check | *Example:* Month 36, YYYY-MM-DD |
| Follow-up checks | *Example:* D8 and D7 at month 27, after HC-ACT-01 and HC-ACT-02 |
| Escalation | Report the red dimension and its action to the architecture board at its next meeting |

## 18. Glossary and references

<!-- Guidance: Define the scoring terms and list the frameworks and internal records used. -->

### 18.1 Glossary

| Term | Meaning in this document |
|---|---|
| Health check | A periodic, evidence-based scan of a running solution across all architecture dimensions |
| Dimension | One area of the solution scored on its own (D1 to D13) |
| Health index | Weighted sum of dimension scores as a percentage of the maximum |
| Drift | Movement of an observed quality away from its target, or of the running system away from its approved design |
| Erosion | Gradual loss of architectural structure through shortcuts and unrecorded changes |
| Headroom | Share of design capacity still unused at current peak demand |
| End of support | Date after which the vendor or community stops issuing fixes for a version |
| Pillar | A top-level area of a cloud provider's well-architected framework |
| [Term] | [Meaning] |

### 18.2 References

| ID | Reference | Version / date |
|---|---|---|
| REF-01 | AWS Well-Architected Framework (whitepaper; six pillars) | Publication date 2024-11-06, as listed on 2026-10-23 |
| REF-02 | Azure Well-Architected Framework (five pillars, workload guides, assessment tool) | Hub page updated 2026-09-11 |
| REF-03 | Google Cloud Well-Architected Framework (six pillars, cross-pillar perspectives) | Last updated 2026-10-13 |
| REF-04 | ISO/IEC 25010:2023, Systems and software quality models: product quality model | Edition 2, 2023-11 |
| REF-05 | Cloud Architecture Review (`architecture/cloud-architecture-review`) | [x.y] |
| REF-06 | Post-Implementation Review (`project/post-implementation-review`) | [x.y] |
| REF-07 | Quality attributes (`requirements/quality-attributes`) | [x.y] |
| REF-08 | Tech debt register (`architecture/tech-debt-register`) | [Date] |

## Standard and licence note

Structure aligned with the cloud provider well-architected frameworks and
with ISO/IEC 25010:2023: the pillar names of the AWS Well-Architected
Framework (operational excellence, security, reliability, performance
efficiency, cost optimization, sustainability), the Azure Well-Architected
Framework (Reliability, Security, Cost Optimization, Operational
Excellence, Performance Efficiency) and the Google Cloud Well-Architected
Framework (operational excellence; security, privacy, and compliance;
reliability; cost optimization; performance optimization; sustainability)
are used only to map results, and the nine quality characteristic names
of ISO/IEC 25010:2023 are used as labels. The thirteen dimensions, the
scoring scale, weights, checks, questions and all text are original; no
questions, best practices or other text from the frameworks or the
standard are reproduced. Obtain ISO/IEC 25010 from ISO for its full
content. AWS, Azure and Google Cloud are trademarks of their owners; this
template is not affiliated with or endorsed by them. Check the current
framework versions at docs.aws.amazon.com, learn.microsoft.com and
cloud.google.com. Template licence: MIT.