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¶
- On the entity, use Submit for review (e.g. the action on an application page).
- The entity enters Under Review and appears in the Reviews queue.
- While under review, the entity's signals bar shows "ARB review in progress."
Reviewing & approving¶
- Open Decisions & Reviews to see the queue.
- Each item is enriched with context — the entity's risk signals and NFR posture — so the board reviews with substance, not just a name.
- 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 position — Endorse, 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).
Related¶
- Discipline: Architecture governance