Skip to content

Entities Overview

Albumi models the landscape through seven entity types. This page is the map: what each entity represents, how the entities connect, and which entity to reach for when the choice is not obvious. For attributes, lifecycle behavior, and governance specifics of any single entity, follow the link to its dedicated page.

If you have not read Key Concepts yet, start there.

The diagram shows the structural relationships between landscape entities. Edge labels name the semantic of the relationship, not a UI action.

flowchart LR
  Cap[Business Capability]
  App[Application]
  Int[Integration]
  Data[Data Object]
  ITC[IT Component]

  App -- realizes --> Cap
  App -- uses --> ITC
  Int -- source --> App
  Int -- target --> App
  Int -- carries --> Data
  Int -- middleware --> ITC
  App -- operates on --> Data

Two entity types reach across the whole landscape and are kept out of the diagram to preserve clarity:

  • Organization owns every entity. Ownership is classification, not access control.
  • Initiative scopes a change effort. Initiatives currently reference the Applications they affect (with an impact type: Add, Modify, Remove).
EntityOne-line definitionOwns relationship toTypical examplesNot to be confused with
ApplicationSoftware that automates business capabilities.Capability, IT Component, Integration (as source or target), Data Object, InterfaceCRM, ERP, billing system, internal portalIT Component (technology under an application)
IntegrationA directed data flow from one application to another.Application (source, target), Data Object (carried)Nightly export from ERP to data warehouse, real-time order push from web to fulfillmentMiddleware itself, which is modeled as an IT Component
Data ObjectA business-level data concept independent of physical storage.Application (via operations), Integration (carrier)Customer, Order, Invoice, ProductDatabase or table, which is an IT Component
Business CapabilityAn ability the business possesses to deliver an outcome.Application (realizer)Order Management, Customer Onboarding, Financial ReportingProcess (a capability is what, a process is how)
IT ComponentA technology used by applications.Application (consumer)PostgreSQL, Kafka, Kubernetes cluster, OktaApplication (business-facing software)
OrganizationA unit in the organizational structure.Every other entity (as owner)Finance department, EMEA region, Platform teamRole or team assignment for a single person
InitiativeA planned change effort affecting the landscape.Application (with impact type)Cloud migration, CRM replacement, GDPR remediationA project plan — Albumi captures architectural scope only

Relationships follow a fixed set of patterns. Thinking by pattern is faster than memorizing every pair.

  • Realization — Application realizes Business Capability. The capability is what the business can do; the application is how it is done today. Edited from the application side.
  • Ownership — Organization owns every other entity. Ownership is classification, not access control; see Permissions & Roles. Edited from either side.
  • Data flow — Integration carries data from a source Application to a target Application. Direction is the direction of data, not of the request that moves it. The integration carries one or more Data Objects. Edited from the integration.
  • Data operations — Application operates on Data Object. The application declares which operations it performs on the data — Create, Read, Update, Delete. Edited from the application.
  • Technology use — Application uses IT Component. The technology an application depends on to operate — databases, message brokers, identity providers, runtime platforms. Edited from the application.
  • Middleware — Integration references IT Component. The technology platform (ESB, iPaaS, API gateway, message broker) that physically carries the flow. Edited from the integration.
  • Interface exposure — Application exposes Interface. A named technical surface (REST endpoint, Kafka topic, SFTP drop) that an Integration can optionally reference on its source or target side. Edited from the application.
  • Change scope — Initiative affects Applications. Each link carries an impact type (Add, Modify, Remove). Edited from the initiative.

Principles, standards, and target-state models are not modeled at all — see Key Concepts for the full list of intentional omissions.

Three modeling questions come up repeatedly. The answers below are the canonical choice in Albumi.

An ESB, iPaaS, API gateway, or message broker is a piece of technology that carries integrations — it is not itself an integration, and it is not a business-facing application. Model the platform as an IT Component. Model each concrete data flow it carries as an Integration between the producing and consuming applications. The IT Component captures the technology fact (version, vendor, lifecycle); the Integrations capture the business-meaningful flows.

Salesforce, Workday, and similar SaaS products are business-facing software that automates capabilities for users. Model them as Applications. The underlying cloud or hosting is an IT Component only if you track it as a distinct technology asset with its own lifecycle (for example, your AWS account or Azure tenant). Do not model every SaaS vendor’s internal infrastructure — Albumi describes the logical landscape, not the provider’s stack.

A database, warehouse, lake, or storage bucket is technology — model it as an IT Component and link it as the runtime of the applications that use it. The business data it contains (Customer, Order, Invoice) is separate: model each as a Data Object. If a dataset is exposed to users as a product in its own right (for example, a BI portal or a data-product UI), that product is an Application.