# Your architecture decisions are slow because nobody owns them

Bain's RAPID applied to architecture governance: one owner per decision, vetoes only with grounds, and faster answers for the teams waiting.

_Published 2026-06-30 · 7 min read_

A team needs to pick a message broker. The proposal visits the domain design authority, which
asks for a comparison matrix. Then the security forum, which adds two conditions. Then the
architecture review board, which requests alignment with a platform strategy that is itself under
review. Then an ad hoc session with a principal architect who was on holiday for the first three.
Four forums, eleven weeks, and the decision that finally emerges carries conditions from each,
several of them mutually incompatible. Nobody said no. Nobody said yes either.

Ask who owned that decision and you'll get a list of people who were consulted. The list is the
problem. Slow architecture decisions are an ownership problem, and adding diligence to them adds
waiting: every extra reviewer arrives with the authority to slow the decision and no
accountability for its speed.

Here is what fixing ownership buys the team doing the waiting:

- **One named person decides**, and you know the name before you write the proposal.
- **Vetoes can land only on grounds published in advance**, so you can engineer for them instead
  of guessing.
- **The decision has a clock**, because a single owner can be asked "when," while a committee can
  only be asked "whether."

An answer in days, from a person, with reasons. That is the entire pitch, and it's buildable with
a framework Bain has been publishing since 2006.

## Responsibility matrices manufacture committees

Most organizations that try to fix decision-making reach for a responsibility matrix: RACI,
RASCI, or a local variant. The matrix assigns work, and for work it's fine. Applied to decisions,
it quietly builds the committee it was meant to prevent. Everyone holding a letter feels entitled
to weigh in; every C is an invitation to schedule a meeting. Accountability, the thing the matrix
was bought to create, ends up distributed, which is the polite word for nowhere.

The tell is the question the matrix can't answer: if this decision is wrong, who was wrong? A
RASCI row names five people. Five people can't be wrong together in any way that changes what
happens next quarter.

There's a second mechanical failure, and the opening scene runs on it: conditions accumulate. A
reviewer who lacks the authority to say yes still has to justify the meeting, and the cheapest
justification is a condition. Each forum adds one or two, nobody reconciles them, and the
proposing team inherits the merge conflict. Malice has nothing to do with it. Participation
without ownership produces conditions, every time.

## RAPID, quickly

Paul Rogers and Marcia Blenko published
["Who Has the D?"](https://www.bain.com/insights/who-has-the-d/) in Harvard Business Review in
2006, drawing on Bain's decision-effectiveness practice. Their RAPID framework assigns five roles
per decision, and the letters are jobs rather than seats at a table:

- **R, Recommend:** builds the proposal and owns its quality.
- **I, Input:** supplies facts and constraints to the R, with no vote attached.
- **A, Agree:** holds a veto, and the veto comes with obligations.
- **D, Decide:** one person who commits the organization to action, in the authors' words "the
  single point of accountability."
- **P, Perform:** executes what was decided.

Two design choices carry the framework's force. The D is singular by construction; the moment two
people share it, you've rebuilt the committee under a new name. And the A is deliberately scarce.
Rogers and Blenko warn that "only a few should have such veto power," and a legitimate veto must
come with grounds and an alternative, never a bare no.

## The architecture mapping

Apply this to architecture governance and the enabler model turns into something concrete: a role
assignment.

Break architecture decisions into classes: technology selection inside one team's boundary,
cross-team interface contracts, deviations from a standard, platform-wide choices. Give each
class one D, and place that D where the consequences live. For most classes that means the team
that ships and runs the system. They hold the pager; they hold the D.

The central architecture function takes different letters, and takes them deliberately:

- **A** on the small set of grounds where a local decision can hurt the whole: security,
  compliance, interoperability. Grounds published in advance, veto exercised with a written
  alternative.
- **R** on genuinely enterprise-wide questions, platform choices and cross-cutting contracts,
  where someone has to do the comparative work honestly.
- **I** everywhere else: real expertise, offered into someone else's decision, with no vote
  attached.

### One dispute, worked through

Two teams need an interface contract; each prefers its own event schema. Under forum governance
this becomes a standards debate that outlives the feature. Under RAPID it has a shape: the
architecture function holds R and does the comparative work in the open, both teams and the
platform group hold I, the D sits with the team that will own the interface once it ships, and
architecture's A can veto only on interoperability grounds, in writing, with an alternative
attached. The dispute still happens. It just happens once, inside a week, with a named person
accountable for the answer.

The gatekeeper-to-enabler shift the industry keeps writing about compresses into one sentence:
the central function stops holding every D and becomes a bounded A. Influence then has to be
earned the only durable way, through the quality of its R work and its I contributions. An
architect whose recommendation keeps being right gets invited into decisions no org chart routes
to them.

![Matrix of architecture decision classes against RAPID letters, showing a single Decide owner per class and the architecture function holding bounded Agree and Recommend roles.](/images/writing/architecture-decisions-nobody-owns/architecture-decisions-nobody-owns.d1.svg)

I've been close to a decision process inside a global enterprise that made this move: from
board-approval, where proposals queued for a slot and left with conditions, to owner-plus-grounds,
where each decision class had a named D and the central function's veto surface was written down.
Decisions got measurably faster, and a quality effect nobody expected surfaced quickly. When the
veto grounds are published, teams engineer for them before submitting, so the vetoes mostly stop
happening. The opening scene inverts: instead of the decision traveling to the reviewers, the
constraints travel to the decision.

What the change costs is honesty about authority. A review board can feel authoritative while
deciding nothing. A bounded A with published grounds is checkable: either the veto cited a ground
or it didn't. Some architects experience that as a demotion. The ones who thrive under it are the
ones whose influence never depended on the queue.

## Decisions on a sprint rhythm

![One decision's path through RAPID roles compared with the committee loop: recommendation prepared, time-boxed input, a single decider, a grounds-based veto check, then execution.](/images/writing/architecture-decisions-nobody-owns/architecture-decisions-nobody-owns.d2.svg)

Ownership fixes who decides. Cadence fixes when. A decision class with a named D can commit to a
clock: input windows time-boxed, a decision date set when the R work starts, the answer shipped
on a rhythm delivery teams can plan around. Rigby, Sutherland and Noble's
["Agile at Scale"](https://hbr.org/2018/05/agile-at-scale) documents the same pattern: teams
working in small, fast cycles outpace traditional structures on time to market. Bain's broader
decision-effectiveness research ties it together: organizations that decide quickly and well
perform better, and deciding quickly is a design property, available to anyone willing to name an
owner.

Close each decision with a record: what was decided, by whom, on what grounds, which alternatives
lost. The record does double duty. It's the audit trail that makes the bounded A checkable, and
it's the raw material your standards and defaults get built from. A decision that lives only in
the meeting where it happened will be re-litigated by people who weren't there.

One forward note, because the next readers of your decision-rights map won't all be human. As
agents start participating in engineering work, the letters split cleanly: an agent can hold R, I
and P today, drafting recommendations, supplying analysis, executing decisions. D and A stay
human. That single sentence is most of an AI governance policy.

## Put it to work

Pick one decision class that recurs, the one whose queue your engineers complain about. Write
three things on one page: the single D by name, the A-grounds on which a veto can land, and the
clock. Publish the page. Route the next real decision of that class through it, and time it
against the last one that went through the forums.

Worth taking away:

- **Decisions need owners, matrices assign work.** If your framework can't answer "who was
  wrong," it isn't a decision framework.
- **Scarce vetoes, published grounds.** Teams engineer for constraints they can see, and the
  vetoes stop happening.
- **The D belongs with whoever holds the pager.** The central function earns influence through
  recommendations, and holds its veto for the few grounds that protect the whole.
- **Write the decision down.** The record kills re-litigation and becomes the seed of your
  standards.