Skip to content
Albumi Docs

Key Concepts

Albumi is built on five conceptual building blocks. This page explains each one in a paragraph. The Concepts and Governance sections go into the specifics.

The landscape

Section titled “The landscape”

The landscape is your current-state model of the IT environment — the applications you run, the data that flows between them, the business capabilities they support, and the technology underneath. Everything Albumi does is in service of keeping this model accurate, analyzable, and governed.

The landscape describes what is, not what was or what might be. History lives in the activity feed; planned futures live in initiatives and change requests.

The entity model

Section titled “The entity model”

The landscape is expressed through seven entity types:

  • Application — software that automates business capabilities
  • Integration — a directed data flow between two applications
  • Data Object — a business-level data concept independent of physical storage
  • Business Capability — an ability the business possesses to deliver an outcome
  • IT Component — a technology consumed by applications
  • Organization — a unit in the organizational structure
  • Initiative — a planned change effort affecting the landscape

That is the entire domain model. Governance constructs — Architecture Change Requests, review boards, review sessions — sit on top of it and coordinate how it is changed. Initiatives specifically scope the architectural impact of a change; they do not replace a project-management tool. See Entities Overview.

Lifecycle

Section titled “Lifecycle”

Long-lived entities — applications, integrations, IT components — move through a five-stage lifecycle from planning to end-of-life. In Albumi, status is derived from dates you set, not selected directly. The five stages are sequential: each date must fall on or after the previous one.

This is deliberate: it removes “stale status” as a class of data-quality problem and lets portfolio views answer “what is active today?” without the landscape going out of sync with reality. See Lifecycle & Dates.

Governance

Section titled “Governance”

Significant changes to the landscape go through Architecture Change Requests (ACRs) — a staged set of edits that a reviewer can examine, discuss, and approve before the change becomes current state. ACRs are reviewed by review boards — standing committees with voting and advisory members — in sessions, which are scheduled meetings where the board works through an agenda.

This workflow is a first-class part of the product, not a separate module. Every approved ACR carries an audit trail linking each resulting change back to the ACR that introduced it. See Governance Overview.

Permissions

Section titled “Permissions”

Albumi’s authorization model has three independent dimensions:

  • Role — Admin, Contributor, or Viewer.
  • Ownership (per-entity) — the user accountable for an entity.
  • Entity-level grant — an explicit Contributor right on a specific entity.

Direct edit of an entity is limited to its owner and to Admins. Everyone else must go through the proposal mechanism, which has its own rules — see Permissions & Roles for the details.

Organizational membership is not a permission dimension — belonging to an organization grants no access to its entities.

What Albumi does not model

Section titled “What Albumi does not model”

Several concepts common to EAM literature are intentionally not first-class in Albumi:

  • Architecture principles, standards, and policies — not modeled as entities. Document them in your own knowledge base and link out if needed.
  • Interface as a top-level entity — Applications expose interfaces (name, direction, protocol, format, endpoint, authentication) as part of the application record, and Integrations can reference them, but there is no separate Interface detail page with its own lifecycle or governance.
  • Runtime infrastructure and observability — Albumi describes the logical landscape, not physical deployments or live telemetry. Pair it with a CMDB or observability stack for those.
  • Multi-stakeholder ownership (RACI) — each entity has one owner, not a responsibility matrix.
  • Project planning — initiatives capture architectural impact only; tasks, milestones, and work breakdown belong in your project tracker.

Where to go next

Section titled “Where to go next”