In enterprise environments architectural decisions tend to break in one of two ways: either nothing gets written down (and everyone remembers a different version), or the process becomes so heavy that nobody can move. The model I have found most productive over the years is what I call the “lightweight RFC” discipline: short, time-boxed, clearly owned, and leaving a decision trail behind it.
What does a lightweight RFC actually solve?
A lightweight RFC is especially effective in areas like:
- Platform standardization (logging, auth, network patterns)
- Large-scale changes (landing zone, segmentation, DR model)
- Decisions with security implications (break-glass, key mgmt, secrets)
- Changes that touch the operating model (on-call, rollout, incident)
Four rules of the process
- Single owner: every RFC has one author — there are no “committee documents”.
- Time box: a clear review window such as 3–5 business days.
- Decision trail: accept/reject/defer plus rationale, all in one place.
- Operational reality: the bar is not just “the architecture looks elegant” — runbook, metrics and rollback are part of the story.
RFC template (one page)
The template I recommend is short but complete enough to actually decide:
- Problem: what are we solving, why now?
- Scope: in/out
- Options: 2–3 alternatives (pros/cons)
- Proposal: chosen path and why
- Risks: technical + security + operational
- Cost: team time, licensing, maintenance
- Rollout/rollback: how does it ship, how do we back it out?
- Operations: alerts, runbook, ownership
The strength of this template is that it forces everyone to answer the same questions.
Review model: not “review” but “comment + veto”
A lightweight RFC does not need everyone’s sign-off. I prefer a clearer model:
- Comment: anyone can leave feedback (e.g. for 48 hours)
- Veto: only specific roles (security, network, platform owner) hold a veto
- Decision: the owner (or technical lead) writes up the decision and closes the loop
This balance works well between speed and risk control.
Decision record: roll the RFC into an ADR when it lands
The output of an RFC should turn into a “decision record”. This is what protects long-term consistency:
- The chosen approach
- Alternatives that were rejected
- Date and owner
- Conditions for revisiting (which signal would make us look at this again?)
As the organization grows, the RFC archive becomes architectural memory.
The most common failure: turning the RFC into a project plan
An RFC has to answer “what are we doing and why?” before “how will we do it?”. Otherwise the document collapses into a task list and loses its impact.
Once the lightweight RFC discipline takes hold, you see the shift: architecture decisions become less contentious, post-incident surprises drop, and new team members onboard faster.