Architecture Review Checklist
Establish standardized architecture review process with clear criteria and repeatable outcomes.
Context
You are conducting architecture reviews. Evaluate designs against principles, quality attributes, operational readiness. Use consistent checklist; document decisions and rationale.
Domain Context
Based on architecture review frameworks and governance:
- Design Review: Does proposed design align with principles? Are quality attributes met? Trade-offs understood?
- Operational Readiness: Monitoring, alerting, logging, runbooks documented? Disaster recovery plan? Capacity forecast?
- Security Review: Authentication, authorization, secrets management, data protection? Compliance with regulations?
- Cost Impact: Infrastructure cost projections? Optimizations considered? Budget alignment?
Instructions
Prepare Checklist:
- Alignment: Does design follow architecture principles?
- Quality Attributes: Addresses scalability, reliability, security, maintainability?
- Dependencies: External services, databases, message queues? All documented?
- Operations: Monitoring, alerting, logging, runbooks? On-call procedure?
- Testing: Unit tests, integration tests, chaos testing? Coverage adequate?
- Compliance: GDPR, CCPA, HIPAA? Data residency requirements met?
- Cost: Projected monthly cost? Optimization opportunities?
Conduct Review: Present architecture. Walk through checklist. Score each item: met, partially met, not met. Discuss gaps and remediation.
Document Decision: Record what's approved, what needs work, contingencies. Link to design document. Assign owners for open items.
Track Follow-Up: Monitor that remediation happens before deployment. Close items only after verification.
Iterate: If review uncovers major issues, schedule follow-up review. Use past reviews to improve checklist.
Anti-Patterns
- Reviews Without Teeth: Checklist completed, issues noted, nothing changes. Result: wastes time. Guard: Reviews block deployment; open items must be resolved or documented as accepted risk.
- Checklist Without Context: Rote questions without understanding trade-offs. Result: surface-level feedback. Guard: Reviewer understands domain; asks "why?" on answers.
- No Documentation: Verbal feedback, forgotten after meeting. Result: team doesn't know what was approved. Guard: Written decision with rationale; link to design docs.
- Infrequent Reviews: Only at major milestones. Result: missed issues accumulate. Guard: Reviews on feature gates, before production, monthly architecture sync.
Further Reading
- Software Architecture in Practice by Len Bass et al. — architecture review processes
- Architectural Thinking by Nathaniel Schutta — critical evaluation skills
- Software Architecture Fundamentals by Mark Richards — review and governance
1---2name: architecture-review-checklist3description: Standardized architecture review process with consistent criteria. Evaluate systems against principles, quality attributes, and operational readiness. Use when conducting architecture reviews.4---56# Architecture Review Checklist78Establish standardized architecture review process with clear criteria and repeatable outcomes.910## Context1112You are conducting architecture reviews. Evaluate designs against principles, quality attributes, operational readiness. Use consistent checklist; document decisions and rationale.1314## Domain Context1516Based on architecture review frameworks and governance:1718- **Design Review**: Does proposed design align with principles? Are quality attributes met? Trade-offs understood?19- **Operational Readiness**: Monitoring, alerting, logging, runbooks documented? Disaster recovery plan? Capacity forecast?20- **Security Review**: Authentication, authorization, secrets management, data protection? Compliance with regulations?21- **Cost Impact**: Infrastructure cost projections? Optimizations considered? Budget alignment?2223## Instructions24251. **Prepare Checklist**:26 - Alignment: Does design follow architecture principles?27 - Quality Attributes: Addresses scalability, reliability, security, maintainability?28 - Dependencies: External services, databases, message queues? All documented?29 - Operations: Monitoring, alerting, logging, runbooks? On-call procedure?30 - Testing: Unit tests, integration tests, chaos testing? Coverage adequate?31 - Compliance: GDPR, CCPA, HIPAA? Data residency requirements met?32 - Cost: Projected monthly cost? Optimization opportunities?33342. **Conduct Review**: Present architecture. Walk through checklist. Score each item: met, partially met, not met. Discuss gaps and remediation.35363. **Document Decision**: Record what's approved, what needs work, contingencies. Link to design document. Assign owners for open items.37384. **Track Follow-Up**: Monitor that remediation happens before deployment. Close items only after verification.39405. **Iterate**: If review uncovers major issues, schedule follow-up review. Use past reviews to improve checklist.4142## Anti-Patterns4344- **Reviews Without Teeth**: Checklist completed, issues noted, nothing changes. Result: wastes time. **Guard**: Reviews block deployment; open items must be resolved or documented as accepted risk.45- **Checklist Without Context**: Rote questions without understanding trade-offs. Result: surface-level feedback. **Guard**: Reviewer understands domain; asks "why?" on answers.46- **No Documentation**: Verbal feedback, forgotten after meeting. Result: team doesn't know what was approved. **Guard**: Written decision with rationale; link to design docs.47- **Infrequent Reviews**: Only at major milestones. Result: missed issues accumulate. **Guard**: Reviews on feature gates, before production, monthly architecture sync.4849## Further Reading5051- _Software Architecture in Practice_ by Len Bass et al. — architecture review processes52- _Architectural Thinking_ by Nathaniel Schutta — critical evaluation skills53- _Software Architecture Fundamentals_ by Mark Richards — review and governance
sethdford