architectural-proposals

An architectural proposal prevents rework by codifying decisions and trade-offs before code is written. You structure it with defined sections including Problem Statement, Proposed Architecture, Key Decisions Needed, and Risks and Mitigations to drive early alignment.

Architecture documentation for product direction shifts should include Problem Statement, Proposed Architecture, What Changes, What Stays the Same, Key Decisions Needed, Risks and Mitigations, and Scope, with optional sections for Implementation Plan and Success Criteria.

You need a formal architectural proposal when decisions shift architecture, alter product direction, or require cross-wave coordination and explicit trade-offs. Proposals ensure alignment before code is written by codifying decisions and capturing trade-offs.

Frame key decisions and manage risks in an architecture proposal by using dedicated sections for Key Decisions Needed and Risks and Mitigations. Apply patterns for Wave management and decision framing to handle architecture shifts and product direction changes.

Yes, you can document alternatives and prior art in an architectural proposal. The structure supports optional extensions including an Appendix for documenting alternatives, Open Questions for unresolved items, and Success Criteria to define measurable outcomes.

The best way to align cross-wave coordination for architecture shifts is applying structured proposal patterns for Wave management and decision framing. This enforces documenting What Changes, What Stays the Same, and Scope to prevent late-stage rework.