RAPID vs DACI: The decision matrix every CIO should steal
A practical guide for architecture decisions, with copy-paste templates, meeting scripts, and an ADR-ready record.
If you’re a CIO choosing RAPID vs DACI for architecture decisions, use the matrix above. Pick one model per decision, name the roles in 10 minutes, and write the decision down in an ADR so you don’t relitigate it next month. Because the fastest way to slow a tech organisation down isn’t a bad architecture choice, it’s a decision that never actually lands. You’ve seen the pattern: “just one more stakeholder”, “we need alignment”, “let’s socialise it”, and suddenly a simple call turns into a four-week saga. This article gives you a clean way to choose the right decision model, run the meeting, and ship the outcome without turning governance into theatre.
The real problem isn’t the framework, it’s decision fog
Decision fog is what happens when nobody can clearly answer three questions: What are we deciding? Who decides? When is it decided? In architecture, it shows up as endless pre-reads that nobody finishes, “quick alignments” that turn into debate clubs, silent vetoes that appear after the meeting, and surprise stakeholders joining late with “one more concern” that resets the whole conversation.
The cost isn’t just frustration. Decision fog slows delivery, pushes teams into building their own versions of “the standard”, and creates security gaps because controls get negotiated differently every time. Over a few quarters, it turns into platform drift: five logging patterns, three ways of doing auth, two pipelines “temporarily” bypassing checks, and an Architecture Review Board that feels like a weekly rerun.
Mini-story: I’ve sat in ARB sessions where the room is full of smart people and the doc is 20 pages long… and still, nobody can name the decider. Everyone has input, someone has a concern, the meeting ends with “we’ll take it offline”, and the team ships anyway because the sprint clock doesn’t care.
By the end of this, you’ll know when to use RAPID vs DACI, and you’ll have templates you can copy-paste into your next decision so it sticks.
RAPID and DACI in one minute
RAPID (roles)
RAPID is built for decisions where ownership and follow-through are the main risks. It forces you to name who proposes, who can block, who ships, and who makes the final call.
• R — Recommend: writes the proposal and options
• A — Agree: limited, explicit veto / approval points
• P — Perform: owns delivery and adoption
• I — Input: consulted experts
• D — Decide: final decision maker
DACI (roles)
DACI is built for decisions where coordination and clarity are the main risks. It makes the process visible: who drives it, who approves it, who contributes, and who just needs to know.
• D — Driver: runs the process, keeps it moving
• A — Approver: final call
• C — Contributors: provide input and work
• I — Informed: kept in the loop, not part of the decision
The difference in one line: RAPID makes execution ownership explicit; DACI makes facilitation and participation explicit.
When RAPID wins for architecture decisions
RAPID is your pick when the decision isn’t the hard part, getting it executed across teams is. It’s built for calls that need a clear decider, explicit guardrails, and a named owner who will actually make it real in delivery.
Best-fit decision types (examples)
Use RAPID for decisions like these:
• Cloud landing zone standards, guardrails, and exceptions
Things like network patterns, identity boundaries, logging baselines, and the “no, you can’t do that” rules, plus the exception process.
• “Build vs buy” for a shared platform capability
CI/CD platforms, observability stacks, API gateways, feature flag platforms, and secrets tooling choices that will shape teams for years.
• Security boundary calls
CDE scope, tokenisation boundaries, encryption approach, key management patterns, where secrets live, what’s allowed in which environment.
• Integration patterns that affect many squads
Sync vs async, eventing vs request/response, canonical models, contract standards, idempotency rules, the stuff that becomes organisational muscle memory.
What to watch for (failure modes)
RAPID works brilliantly… until people blur the roles.
• Too many “Agree” roles becomes a hidden committee
“Agree” is not “everyone who cares”. Keep it to true veto points (security, risk, legal) or you’ve rebuilt the problem you were trying to fix.
• The decider avoids deciding and turns “Input” into voting
If “Input” becomes a poll, you’ll get “alignment” and still no outcome. Input is advice, not a referendum.
• “Perform” isn’t named, so the decision never lands in production
This is the silent killer. If there’s no delivery owner, the decision becomes a document, not a change. RAPID only works when “Perform” is a real person with capacity and a plan.
When DACI wins for architecture decisions
DACI is the better tool when the main problem is coordination. You don’t need a heavyweight decision chain; you need one person to drive the process, pull in the right contributors, and land the outcome cleanly without everyone feeling like they have to attend every meeting.
Best-fit decision types (examples)
DACI works well for decisions like:
• API standards updates and versioning rules
Naming conventions, error formats, pagination rules, deprecation timelines, and decisions that need consistency and a simple way to socialise change.
• Reference architecture updates
Logging and tracing standards, CI/CD guardrails, “golden path” patterns where the goal is repeatability and predictable adoption.
• Repeated “same-shaped” decisions across squads
The sort of decisions you make every month: “Which pattern is the default?”, “What’s the exception path?”, “What’s the minimum bar?” If you’ll do it again, DACI keeps it lightweight.
• Tooling choices inside a lane
Observability, feature flags, testing strategy, secrets tooling, especially when it’s a platform capability that needs input from a few teams but shouldn’t become an all-hands debate.
What to watch for (failure modes)
DACI breaks down when the roles become symbolic.
• The Driver becomes a note-taker instead of a closer
The Driver’s job is to move the decision to a finish line: set deadlines, chase inputs, frame options, and force a call with the Approver. If the Driver is only capturing comments, you’ll loop forever.
• Too many Contributors, no quality bar for input
If everyone is a contributor, nobody is accountable. Keep contributors tight, and ask for input in a useful shape: risks, trade-offs, and a recommendation, not essay-length opinions.
• “Informed” stakeholders show up late and try to reopen the call
This is where DACI needs backbone. Informed means they get the decision, not a seat at the table. If someone comes in late with new information, treat it as a change request; don’t replay the whole decision.
The “architecture decision types” checklist (pick a model fast)
Use this like a quick diagnostic. Don’t overthink it. Count the “yes” answers and pick the model that matches the shape of the decision.
Score RAPID if you answer “yes” to 3+
• Does the decision require cross-team execution and adoption? (Multiple squads will need to change how they build, deploy, or integrate.)
• Are there true veto points (security, risk, legal, finance)? (Someone must be able to say “no” for real reasons, not preference.)
• Will this decision change delivery roadmaps or operational load? (New work across teams, new on-call burden, new runbooks, new costs.)
• Is there a high cost of rollback? (Undoing it later would be expensive, disruptive, or risky.)
Score DACI if you answer “yes” to 3+
• Is the main pain coordination and stakeholder clarity? (The decision itself isn’t scary, the process keeps wobbling.)
• Is this a recurring decision pattern (you’ll do it again soon)? (Standards, templates, playbooks, “default patterns” that repeat.)
• Do you need one person to drive inputs and timeboxes? (The herding cats problem. You need a Driver who closes.)
• Is the change easy to roll forward with a clear standard? (You can iterate, refine, and improve without massive rollback risk.)
Templates (copy-paste)
These are designed to be fast. Paste them into Confluence/Notion/Google Docs, fill the blanks, and you’re ready to run the decision.
Template 1: RAPID roles table (one decision)
Decision statement: [One sentence: what are we deciding?]
Timebox + meeting date:
Input closes: DD MMM
Decision meeting: DD MMM (max 30–45 mins)
Decision locked in ADR by: DD MMM (same day)
“Agree” guardrails (what counts as a veto):
Veto is valid only if it’s tied to: security / legal / risk / finance policy
Must include: specific concern + impact + proposed mitigation/alternative
No “veto by vibe”
Template 2: DACI roles table (one decision)
Decision statement: [One sentence: what are we deciding?]
Input deadline + decision date:
Input due: DD MMM (written input, max 5 bullets each)
Decision date: DD MMM
Publish outcome by: DD MMM (same day)
How the outcome will be shared:
Posted in: #architecture (Slack/Teams) + linked in Confluence
Recorded as: ADR-###
Rollout note: who changes what by when
Template 3: One-page architecture decision brief (works for both)
Title: Decision: [X]
Owner: [Name]
Decision date: DD MMM YYYY
Framework: RAPID / DACI
Context (3 bullets)
What’s happening / why now?
What’s broken or at risk?
What success looks like
Options (2–3 options, with trade-offs)
Option A: …
Pros: …
Cons: …
Risks: …
Option B: …
Pros: …
Cons: …
Risks: …
Option C (if needed): …
Recommendation (1 paragraph)
State the call, the core reason, and the trade-off you’re accepting.
Risks and mitigations
Risk: … → Mitigation: …
Risk: … → Mitigation: …
Rollout plan (who, when, how we measure)
Who: Perform/Owners
When: milestones + dates
Measures: adoption %, incident rate, cost, latency, time-to-ship, etc.
Decision record (ADR link)
ADR-###: [link]
Template 4: ADR mini-template (so decisions stick)
Title: Decision: [X]
Status: Proposed / Accepted / Superseded
Date: DD MMM YYYY
Owner: [Name]
Decision
What we decided, in 2–5 lines.
Rationale (trade-offs)
Why this option over the others
What we’re optimising for
What we’re consciously accepting
Consequences
Positive: …
Negative: …
Follow-ups: … (tickets, migration plan, deprecation)
Links
Decision brief: …
Threat model / risk assessment: …
Diagrams: …
Related ADRs: …
Meeting scripts (short lines that actually work)
These are the lines you can use in the room without sounding like you’re quoting a framework. Short, calm, and they move things forward.
When the meeting starts to spiral
• “We’re mixing input with decision. Who’s the decider for this call?”
• “Let’s timebox. What do you need to be comfortable, and by when?”
When someone wants a vote
• “Happy to take input. We’re trading off, not running a poll.”
When late stakeholders try to reopen it
• “If there’s new information, let’s log it as a change request against the ADR.”
How to operationalise this in your architecture governance
Frameworks don’t fix anything on their own. What changes behaviour is making the decision process repeatable and boring: same roles, same timeboxes, same place to record outcomes. That’s what enterprise architecture governance is meant to do: keep standards consistent, make decision rights visible, and stop every team inventing their own “rules” in isolation.
Where it fits
• Squad-level decisions (DACI most of the time)
Most day-to-day architecture calls are local: API patterns, small tooling choices, reference implementation updates. DACI keeps it lightweight and fast, with a clear Driver and Approver so it doesn’t stall.
• Cross-domain decisions (RAPID for clarity)
When a decision spans squads, platforms, or risk domains, RAPID keeps it clean: one decider, explicit veto points, and a named “Perform” who owns delivery and adoption.
• ARB as “red lines only” with explicit veto criteria
Treat the ARB like a safety rail, not a weekly court hearing. If something doesn’t hit a red line (security boundary, compliance, material risk, major cost), it shouldn’t need ARB airtime. And if it does hit a red line, the veto criteria should be written down so it’s predictable, not personal.
Simple cadence
• Weekly decision slot (30 mins)
One recurring slot for decisions that need cross-team visibility. Keep it tight: two decisions max, timeboxed discussion, clear outcome.
• Decisions written same day (ADR link)
Don’t rely on memory. Publish the decision and the “why” while it’s fresh, then link it everywhere the delivery teams will actually see it.
• Monthly review of exceptions and drift (standards vs reality)
This is where governance earns its keep. Review what teams are deviating from, why they needed exceptions, and whether the standard should change. Standards that don’t match reality don’t get followed, they get worked around.
Close: your operating model in 5 lines
• Pick one model per decision.
• Name roles in 10 minutes.
• Timebox inputs.
• Decide once, record it (ADR).
• Review exceptions, not old arguments.
If you want architecture playbooks you can run on Monday morning, subscribe to my newsletter.