Skip to content
Albumi Docs

Governance Overview

In most EAM tools, governance is a module you bolt on: a separate workflow engine, a spreadsheet of approvers, a meeting calendar that lives somewhere else. Albumi treats governance as part of the data model. Every change to the landscape is attributable to an author, routed through a review path the workspace has agreed on, and preserved in an audit trail that links the change back to the decision that approved it.

This page explains why that layer exists, what it is made of, and which path to use for which kind of change. For the specifics, follow the links at the end of each section.

Why governance is built in

Section titled “Why governance is built in”

A landscape model is only useful if the organization trusts it. Trust comes from three things:

  • Attribution. Every record shows who owns it, who last changed it, and when. There are no anonymous edits.
  • Review. Changes that matter go past a second pair of eyes before they become current state. The reviewer, the discussion, and the decision are recorded next to the change.
  • Traceability. From any entity, you can walk back to the change that last modified it, the author who made it, the review that approved it, and the session where it was discussed.

Albumi’s governance layer is what delivers those properties. It is not an optional workflow module — the review workflow, the audit trail, and the permission model share the same entities as the landscape itself.

The three governance primitives

Section titled “The three governance primitives”

Three entity types carry the governance layer. Each has its own detail page; the paragraphs below are the orientation.

Architecture Change Request (ACR). An ACR is a proposed change to the landscape, gathered into a single reviewable package. It can batch edits across multiple entities — add a new application, rewire two integrations, retire an IT Component — and move them through review together, so reviewers see the change as one coherent proposal rather than five disconnected edits. An ACR has an author, an optional review board, a status that progresses through a defined workflow, and a full history of comments and decisions. See Change Requests.

Review Board. A review board is a standing committee: a named chair, a list of voting members, and a list of advisory members. Boards are permanent — the same Architecture Review Board that governs integrations this quarter is the same one that governs them next quarter. A board is who reviews; it is not itself a meeting. See Boards & Sessions.

Review Session. A review session is a scheduled meeting where one board works through an agenda of ACRs. The session has a chair (the session owner, not necessarily the board chair), a set of participants auto-populated from the board, an agenda that the chair curates, and a status that reflects whether the meeting is upcoming, running, or finished. A session is when review happens. See Boards & Sessions.

The separation matters: an ACR can exist without ever being scheduled on a session (quick asynchronous review), and a board can exist without a session in progress. The two become linked when the chair puts the ACR on a session’s agenda.

The two edit paths

Section titled “The two edit paths”

Not every change needs a committee. Albumi supports two legitimate edit paths, and the choice between them is driven by who you are relative to the entity and how significant the change is.

Direct edit. If you own the entity, or you are a workspace Admin, you edit it directly. The change is written to current state immediately and recorded in the activity feed with your name and a timestamp. Use this path for day-to-day curation of entities you are accountable for — updating the description of an application you own, adjusting a lifecycle date, re-scoring functional fit.

Proposed edit. If you do not own the entity, you do not edit it directly; you propose the change. There are two shapes the proposal can take:

  • A per-entity proposal is the lightweight path: you suggest a change to one entity, the owner reviews it, and on approval the change is merged into current state. Use this when the change is narrow and the owner alone can decide.
  • An ACR is the heavyweight path: you bundle one or more edits — possibly across several entities — into a single request, route it to a review board, and a group of reviewers decides. Use this when the change spans multiple owners, has architectural impact beyond one entity, or needs a decision that should be visible on the record.

Both paths produce the same outcome — an update to current state with a full audit trail. They differ in who decides and how many entities are in scope. The activity feed reflects both; direct edits and approved proposals appear with the same level of detail.

Permissions & Roles explains exactly which role plus ownership combination unlocks which path.

How an ACR moves from draft to implemented

Section titled “How an ACR moves from draft to implemented”

The ACR workflow is a linear path with a few branch points. The short form:

  1. Draft. The author creates the ACR and assembles the edits it contains. Only the author (and Admins) can modify a draft; reviewers see nothing yet.
  2. Submitted. The author submits the ACR. From this point on, reviewers can see it, comment, and vote. The chair can place it on a review session’s agenda when appropriate.
  3. Approved. Reviewers approve. Newly-created entities are promoted to current state immediately. Changes to existing entities enter per-owner rollout — they are recorded as Approved but do not appear in current state until each affected entity’s owner implements their own item.
  4. Implemented. Every rollout item has been applied. The ACR is closed as a historical record. Each resulting entity version carries a link back to the ACR that introduced it, and the activity feed records each change — both on the ACR (as an internal event) and on the entity itself (as a mainline event).

Three branch points interrupt that path when needed:

  • Revision. A reviewer asks for changes. The ACR returns to the author, who revises and resubmits.
  • Rejected. A reviewer rejects the ACR. The author can reopen it back to Draft if the decision needs revisiting, or leave it rejected as a record of the decision.
  • Cancelled. The author (or a reviewer) withdraws the ACR. The ACR is preserved for the record but goes no further.

The full state machine with every transition and the exact set of actors authorized for each is documented on Change Requests.

One derived state is worth calling out: when people say an ACR is “under review”, they mean it is currently on the agenda of a session that is in progress. “Under review” is not a status the ACR carries — it is a fact about its position in the review calendar. The same ACR is “under review” during the meeting and returns to its stored status (Submitted, or Revision, or Approved) once the session ends.

Separation of duties

Section titled “Separation of duties”

An ACR author cannot approve, reject, or request revision on their own ACR. The reviewer role and the author role are mutually exclusive on a given request — this is enforced at the authorization layer, not by convention. An author who disagrees with their own proposal withdraws it, cancels it, or revises it; they do not self-approve.

Two carve-outs exist:

  • Admin. An Admin can review any ACR, including one they authored. Without this exception, a single-Admin workspace could never get a change past review. In workspaces with more than one Admin, the norm is for an Admin-authored ACR to be reviewed by another Admin.
  • Cancel. Any workspace Contributor can cancel any ACR, not only the author or a reviewer. This is deliberate — the workspace as a whole can close out stale or superseded proposals without requiring the author’s cooperation.

What governance does not solve

Section titled “What governance does not solve”

Governance in Albumi is a review layer for architectural changes. It is not meant to be:

  • An approval queue for routine edits. Updating an owner’s contact details, fixing a typo in a description, adjusting a date by a day — these are direct edits by the owner. Putting them through an ACR adds ceremony without producing better outcomes.
  • A ticketing system. ACRs do not have severity, SLA timers, or assignment queues. If you need to track work items, use your team’s work tracker and link to the ACR from there.
  • A project management tool. Initiatives in Albumi capture the architectural scope of a change effort — which applications it affects and how — but not the tasks, milestones, or people-days that deliver the work. Keep the project plan in your project tracker; use Initiatives for the architectural footprint.

Using the right tool for the right layer keeps the governance layer useful. Everything in it should be something an architect or reviewer genuinely needs to see; noise crowds out signal.

Section titled “Related”