software-system-architect

Start by extracting functional and non-functional requirements, then identify architecture drivers like scale, latency, compliance, and team structure. Model domains and boundaries, compare architecture options with recorded trade-offs, and define APIs, events, and data ownership before planning incremental implementation.

Choose based on architecture drivers such as team structure, scale, deployment independence, and operational capacity. A modular monolith reduces distributed-system complexity for smaller teams, while microservices suit independent scaling and deployment needs. Record the trade-offs in an architecture decision record.

An ADR documents a significant architecture decision, its context, the options considered, and the trade-offs accepted. Write one whenever multiple technically valid options exist, preferring reversible decisions for uncertain areas and recording why alternatives were rejected.

Review the architecture against real operational constraints: check failure modes, security boundaries, scalability limits, and consistency trade-offs. Verify claims against current authoritative documentation, identify technical debt, and produce a risk register with a migration roadmap for corrections.

Architecture artifacts alone do not prove production readiness; a system is not production-ready merely because the design compiles on paper. Security, observability, failure handling, deployment, and rollback must be validated in implementation, and assumptions should be labeled rather than presented as verified facts.