Skip to content

Architecture reviews

ArcaMira's review workflow (the ARB queue) lets you govern significant changes without turning every edit into a ceremony. Reviews live in the Decisions & Reviews hub under Governance → Decisions & Reviews (/governance/decisions-reviews), alongside ADRs, the standing Review Board, tracked conditions, and the denials register.

Two review methods

When you start a review you pick a method:

  • Solution review (the default) — govern a proposed change against the estate: affected entities, applicable principles, blast radius, a documented decision.
  • Selection scorecard — compare candidate technologies or vendors on weighted criteria. Score each 0–5 per criterion; the tool computes a weighted total and flags the leader, and the board records which candidate was selected (it can override the leader with rationale). A defensible "we picked X because…" decision.

Everything below describes the solution review; the scorecard swaps the "affected entities" step for the candidate/criteria matrix but shares the same board, positions, conditions, and sharing.

The lifecycle

Entities move through a status workflow:

Draft → Under Review → Approved → Archived

You don't review everything — use this for significant new entities or material changes to existing ones.

Submitting for review

  1. On the entity, use Submit for review (e.g. the action on an application page).
  2. The entity enters Under Review and appears in the Reviews queue.
  3. While under review, the entity's signals bar shows "ARB review in progress."

Reviewing & approving

  1. Open Decisions & Reviews to see the queue.
  2. Each item is enriched with context — the entity's risk signals and NFR posture — so the board reviews with substance, not just a name.
  3. Approvers (configured under Admin → Approval Workflow) approve, which moves the entity to Approved, or send it back.

Gathering positions: the review board

A review isn't a solo sign-off. A standing Architecture Review Board can weigh in asynchronously — no meeting required.

Reviewer positions

Each reviewer on a review registers a positionEndorse, Concerns, Object, or Abstain — with an optional comment, over a response window. Positions are advisory: they inform the chair, who still records the decision. A live board meeting is the same thing projected on screen; the tool captures the outcome either way.

Seats, not just names

Reviewers are modelled as seats — the disciplines that weigh in (Enterprise Architecture, Security, Data, Infrastructure & Network, Application, Business, or any you define). The seat carries the meaning: "Security: concerns" says more than a name, and the seat persists when the person filling it changes.

The standing board

Configure the board once under Governance → Decisions & Reviews → Review Board: define your seats and assign an occupant to each. Every new review is then auto-populated with those board members, and the chair adds ad-hoc subject-matter experts on top as needed.

Seat coverage is checked automatically: if a review touches, say, technology entities but no Infrastructure/Network seat is on the roster, an advisory note flags the gap — a nudge to pull in the right discipline, never a hard gate.

Conditions: "approved provided…"

When a review is approved with conditions, capture each condition as a tracked commitment rather than a line of prose: the text, the entity it concerns, an owner, and a due date, with a lifecycle — open → met / breached / waived. Overdue open conditions flip to breached automatically.

The payoff is that conditions don't die in the minutes: an open or breached condition surfaces on the affected entity's page (under Governance / Review conditions) with a link back to the review. A commitment made in an ARB stays visible against the estate until it's met.

Denials register

Reviews that end in rejected or deferred are collected in the Denials register (Governance → Decisions & Reviews → Denials) — searchable by title, rationale, or affected entity — so "have we said no to something like this before?" is answerable. Institutional memory, not a lost decision.

Communicating with impacted people

The people a change impacts usually aren't on the board and don't have accounts — but they need the result, and sometimes hold detail you need before deciding. Both directions work without giving anyone system access.

Share the decision (outbound)

On a decided review, use Share the decision to mint a read-only, no-login link. It renders a clean decision pack — the outcome, conditions, what the change touched, and the board's disposition by seat — with no estate access. Send it to impacted teams however you like; revoke it any time.

Request input (inbound)

Use Request input to ask a named person for detail — optionally about a specific affected entity ("does anything downstream depend on this you're aware of?"). They get a personal, one-time link, answer a lightweight form with no account, and their response lands on the review as an external · unverified note the board weighs before deciding. ArcaMira suggests recipients from the owners of the affected entities and their downstream dependents; you can also add an email so the link is sent for you.

This is the structured replacement for the ARB email chain — the input is captured on the review, not scattered across inboxes.

Keeping approvals fresh: check-in cadence

Approval isn't forever. Entities can be put on a check-in cadence (configured under Admin → Check-in Cadence). Overdue entities surface in the Intelligence hub and on the entity's signals bar ("never checked in" / overdue), so governance stays alive instead of a one-time stamp.

Decisions and standards alongside reviews

  • Record the why behind significant choices as Decisions / ADRs, kept in the same Decisions & Reviews hub (/governance/decisions-reviews) and linked to the entities they affect.
  • Track which Standards entities comply with; principles, standards, the policy-exception register, and compliance posture all live in the Standards & Principles hub (/governance/standards-principles).