Good architecture needs two things that often pull in opposite directions: space to think and stability to build.
From Discussion to Decision — How RFCs and ADRs Work Together in Practice
Good architecture needs two things that often pull in opposite directions:
space to think and stability to build.
- When there is only space, architecture never settles.
- When there is only stability, architecture hardens too early.
Over the past weeks, while writing about Architectural Decision Records (ADRs), several thoughtful responses highlighted the complementary role of Requests for Comments (RFCs) — especially in federated or mesh-inspired operating models.
That feedback reflects a pattern I’ve seen repeatedly in practice.
RFCs and ADRs are not competing tools. They solve different problems at different moments in the architectural lifecycle.
This article explains how they work best together — and why separating their roles leads to clearer decisions, better alignment, and more durable architecture.
Architecture needs both space and commitment
Before any architectural decision is made, uncertainty is unavoidable.
Different stakeholders bring:
- Different constraints
- Different priorities
- Different risk perceptions
Trying to shortcut that uncertainty usually leads to fragile decisions that resurface later under pressure.
RFCs exist to create structured space :
- Space to explore alternatives
- Space to surface trade-offs
- Space to challenge assumptions safely
ADRs exist to create commitment :
- A clear decision
- A shared rationale
- A stable reference over time
Treating both as the same artifact blurs these responsibilities — and weakens both.
What RFCs are good at
An RFC is fundamentally an exploration tool.
Well-used RFCs:
- Frame a problem clearly
- Present multiple viable options
- Make trade-offs explicit
- Invite feedback across teams and domains
They are especially valuable when:
- Impact spans multiple domains
- Organizational alignment matters
- The problem space is still evolving
RFCs help prevent premature decisions by making disagreement and uncertainty visible early , when they are still cheap to address.
What RFCs are not designed to do is to act as long-term architectural anchors. They are intentionally open-ended.
What ADRs are good at
ADRs begin where RFCs end.
An ADR records:
- What was decided
- Why this option was chosen
- Under which context
- What consequences follow
A good ADR is:
- Short
- Opinionated
- Stable
Its purpose is not to reopen discussion, but to prevent rediscovery.
In MDDE, ADRs are deliberately lean. They avoid extensive implementation detail and instead point to executable artifacts — rules, generators, validation logic — that enforce the decision consistently.
The handover moment: RFC → ADR
The most important architectural moment is not writing an RFC or publishing an ADR.
It is the transition between them.
An RFC becomes an ADR when:
- The discussion has converged
- Alternatives have been evaluated
- A decision must now be applied consistently
At that point:
- Exploration gives way to commitment
- Debate gives way to enforcement
- Flexibility gives way to clarity
Without this handover, architecture oscillates endlessly.
With it, architecture becomes deliberate and repeatable.
Federated and mesh models: why this matters even more
In federated or mesh-inspired operating models, this separation is critical.
RFCs support:
- Cross-domain input
- Alignment without hierarchy
- Shared understanding of impact
ADRs provide:
- A single, stable outcome
- A reference point across domains
- A basis for validation and enforcement
Some organizations choose to include more implementation guidance directly in ADRs, often combined with a central validation authority. Others keep ADRs lean and reference executable standards instead.
Both approaches can work.
What matters is not the format — but clarity about when discussion ends and decisions begin.
How this fits into MDDE
In MDDE, the flow is explicit:
RFC
→ explore options and trade-offs
ADR
→ record the decision and rationale
Executable rules, generation, validation
→ enforce the decision consistently
This ensures:
- Discussion is explicit
- Decisions are durable
- Enforcement is automatic
Architecture stops living only in documents and starts showing up in system behavior.
Practical templates
Minimal RFC outline
- Problem statement
- Context and constraints
- Options considered
- Trade-offs
- Open questions
Minimal ADR outline
- Context
- Decision
- Rationale
- Consequences
Keeping both lightweight dramatically increases the chance they are actually used.
Architecture as a living conversation
RFCs and ADRs are not rivals.
They are different phases of the same architectural conversation.
RFCs ensure the right decision is made.
ADRs ensure the decision sticks.
Together, they create a healthy rhythm:
explore → decide → execute → observe
That rhythm is what allows architecture to scale across teams, domains, and time — without losing either flexibility or coherence.
What’s next
In upcoming articles, I’ll explore:
- How ADRs evolve without erasing history
- How executable rules reference decisions
- When exceptions should trigger new RFCs
- Governance patterns that avoid central bottlenecks
All focused on the same goal:
architecture that remains deliberate, explicit, and adaptable under continuous change.