Architecture Decision method
Documents a technical proposal so affected people can review, decide, and later trace it asynchronously.
An internal RFC borrows the idea of open technical discussion but is not the IETF standards process. Problem, context, goals, non-goals, design, alternatives, risks, migration, and decision log are defined locally.
Is the proposal decision-ready with alternatives, consequences, and a migration path?
Request for Comments (RFC) uses versioned proposal with open review window, resolved comments, and explicit status. Assessments remain justified and context-bound.
Draft
Write problem, goals, non-goals, proposal, alternatives, and migration.
Review
Invite affected reviewers with a deadline and collect comments.
Decision
Resolve comments and have the decision owner decide with rationale.
Lifecycle
Track implementation, deviations, and supersession separately.
Update after new evidence or a material context change and retain the previous version.
For reversible or consequential technical decisions affecting several teams.
RFC record with traceable sources, assumptions, and domain decisions.
Owners, dates, and next review for RFC record.
Fictional worked example
versioned proposal with open review window, resolved comments, and explicit status as a precise working structure with a fictional example.
Problem/goals information to record
Schema Evolution; kein neuer Broker.
Proposal/alternatives information to record
CloudEvents+JSON Schema vs. Avro.
Review/decision information to record
Security-Einwand beantwortet; Accepted.
Migration/status information to record
30 Tage Dual Publish; Implementing separat.
The example demonstrates the domain logic of Request for Comments (RFC); worksheets remain blank.
Start with the core question: Is the proposal decision-ready with alternatives, consequences, and a migration path?
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.
A 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.
The method guide walks execution through 4 phases, timing, 4 pitfalls, and clear stop criteria.
Open method guideYour perspective
Your feedback helps shape the next improvements to methodatlas.
Plan Request for Comments (RFC) around its domain steps and the concrete decision question.
To be confirmed
To be confirmed
Establish and review the practice Time: 2–10 working days by consequence
Complete this worksheet on paper or in your own document during the work.
Problem/goals information to record
...
Proposal/alternatives information to record
...
Review/decision information to record
...
Migration/status information to record
...
Enter only real input, sources, and decisions.
IETF RFC 2026: The Internet Standards Process
Expected artifact: RFC draft
RFC draft · source · uncertainty · next decision
Entry:
...
Expected artifact: review record
review record · source · uncertainty · next decision
Entry:
...
Expected artifact: RFC decision
RFC decision · source · uncertainty · next decision
Entry:
...
Expected artifact: RFC lifecycle
RFC lifecycle · source · uncertainty · next decision
Entry:
...
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/rfc/run-sheet
Fitting alternatives with decision guidance, followed by other related methods.
Instead of Request for Comments, choose Architecture Decision Record when a single architecture decision should be documented and easily findable again later.
Developers try a preliminary technical design through typical tasks, showing what makes it easy or difficult to use.
Bundles problem, goals, stakeholders, and risks into a starting picture that sorts early architecture questions.
Examines how architecture decisions support important quality goals and makes risks and trade-offs visible.
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".
Uses concrete tasks to show how well an architecture supports use and change.
