Uses a structured proposal and review process to make non-trivial technical or product changes discussable and decidable.
Which change does the team propose, with which rationale, alternatives and tradeoffs, and who decides by when?
An RFC clarifies architecture context, options, and consequences. It structures technical context, alternatives, tradeoffs, open questions, and review feedback, and captures the result as an RFC document, reviewer comments, and a decision rationale.
The author describes problem and context, sharpens motivation and goals, details the proposed solution, explains alternatives and tradeoffs, marks open questions and risks, opens a review round with stakeholders, incorporates comments, sets a status, and translates the accepted decision into ADRs or tickets.
Method sketch for a quick mental model.
The runsheet guides execution with 7 phases, timeboxes, 6 pitfalls, and clear stop criteria.
Open runsheetA Request for Comments is a structured proposal document that originated in the IETF process and is now widely used in engineering organizations for non-trivial changes. The document usually covers context, motivation, solution, alternatives, drawbacks, and unresolved questions. It is reviewed asynchronously or in a defined review window. The author incorporates feedback, and a named decision authority moves the proposal to accepted, rejected, or withdrawn. The process makes assumptions, tradeoffs, and rejected options durable.
Keep the template short and consistent. Set a review window, name a decision authority, and use clear status values. Separate discussion from the final decision and translate accepted RFCs into ADRs and implementation tickets.
Compact working template for Request for Comments with context, input, output artifacts, and next step.
Structured proposal document that describes a non-trivial change and intentionally collects feedback.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Short decision aid for existing alternatives.
Statt Request for Comments, wenn eine einzelne Architekturentscheidung dokumentiert und später leicht wiederauffindbar sein soll.
Turns architecture context, options, and consequences into a tangible result by defining the problem, collecting goals and constraints, and determining next investigations.
Moves architecture context, options, and consequences toward a concrete result through "place the architecture diagram or plan in the center", "set risk categories such as technical, organizational, and external", and "assign an owner and next steps for each top risk".
Turns architecture context, options, and consequences into a tangible result by naming the decision, describing context, and capturing consequences.
Statt Request for Comments, wenn eine einzelne Architekturentscheidung dokumentiert und später leicht wiederauffindbar sein soll.
Turns architecture context, options, and consequences into a tangible result by collecting stakeholder goals, eliciting quality scenarios, and documenting architecture implications.
Turns architecture context, options, and outcomes into a tangible result by identifying stakeholders, selecting views, and validating completeness.
Turns architecture context, options, and consequences into a tangible result by capturing goals and stakeholders, scoping context, and linking risks and decisions.