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.

Document control

Approvals

Revision history

Contents

1. Health summary
2. Scope, cadence and method
3. Solution context and original drivers
4. Quality attributes and NFR drift
5. Reliability and resilience
6. Security posture
7. Cost and sustainability
8. Performance and capacity
9. Operability
10. Technology lifecycle and dependencies
11. Technical debt and architecture erosion
12. Data health
13. Documentation and decision currency
14. Team, ownership and skills
15. Scorecard and framework mapping
16. Findings and prioritised actions
17. Trend and next check
18. Glossary and references

1. Health summary

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

2.1 Scope

2.2 Cadence and triggers

2.3 Inputs

2.4 Scoring scale

This scale is original to this template.

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.

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

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

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

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

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

7.1 Cost

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

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

8. Performance and capacity

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

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

10. Technology lifecycle and dependencies

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

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

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

13. Documentation and decision currency

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

D12 Team and ownership score: Example: 2.

15. Scorecard and framework mapping

15.1 Scorecard

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

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

16.1 Findings

16.2 Action plan

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

18. Glossary and references

18.1 Glossary

18.2 References

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.