Solution Architecture

Produce enough design evidence to decide and implement safely. A small change can use one note; a regulated or cross-team design may need a formal package. Enterprise architecture binding is opt-in for a named consumer.

Workflow

1. Inspect the brief and relevant current source, interfaces, deployment constraints and prior decisions. Identify assumptions and unknowns; do not require an archaeology report before direct inspection.
2. Define outcome, scope, constraints and acceptance. Quantify consequential NFRs with workload/environment, metric, target, measurement method and owner.
3. Compare feasible options, including retaining the current system. Explain costs, failure modes, dependencies and reversibility rather than recommending fashionable technology.
4. Trace the consequential requirements to design mechanisms and verification. Name data/authority boundaries, compatibility, migration, duplicate/retry behavior and recovery constraints.
5. Record significant choices as ADRs where future maintainers need rationale. Assess existing architecture and technical debt using evidence, impact, exposure and cost of delay.
6. Size review to risk. Check contradictions, unsupported claims and uncovered requirements; clean reviews are valid with stated coverage.
7. If a multi-artifact package is requested, reconcile cross-document versions/ownership before handoff. Otherwise keep the evidence in one reviewable note.

Minimum useful evidence

Decision/outcome; source baseline; requirements and constraints; chosen option and alternatives; material risks/dependencies; acceptance/verification and remaining unknowns. Technical debt adds location/evidence, consequence, category, effort range, urgency/confidence, proposed action and owner/trigger. Prioritize demonstrated impact/exposure and dependencies rather than a universal security-first ordering.

Optional references