Skip to content
Albumi Docs

Integrations

An Integration is a directed data flow from one Application to another — the thing the EA cares about when asking “what flows in and out of this system, and where does it go next?” The platform that physically carries the flow (an ESB, an iPaaS, a message broker, an API gateway) is not the Integration; it is an IT Component the Integration references as middleware.

Integrations are the relationship every EAM user misreads the first time. This page defines the direction rule, the orthogonal initiator that keeps getting confused with it, what an Integration does and does not model, and how it connects to neighboring entities.

For the five lifecycle stages an Integration shares with Applications and IT Components, see Lifecycle & Dates. This page does not repeat them.

Direction is the direction of DATA, not of the request

Section titled “Direction is the direction of DATA, not of the request”
source  →  target
producer     consumer
  • Source is the Application that produces the data.
  • Target is the Application that consumes the data.

This is the single most common modeling mistake in any EAM tool: drawing the arrow in the direction of the HTTP call. Albumi’s arrow follows the payload, not the initiator of the connection. Which side opens the socket is a separate attribute (see Initiator below).

Two worked examples make the distinction unmissable:

  • CRM publishes new customers to the billing system. Customer data originates in the CRM and ends up in Billing. The Integration is CRM → Billing. It does not matter whether CRM pushes each event or Billing polls CRM for changes — the data flow is the same.
  • Billing pulls the product catalogue from the PIM nightly. The request starts in Billing, but the data starts in PIM and arrives in Billing. The Integration is PIM → Billing, with initiator = Pull. Drawing this as “Billing → PIM” because Billing made the call is the mistake the direction rule exists to prevent.

If the answer to “where did this data originate?” is A, and the answer to “where does this data end up being used?” is B, the Integration is A → B. Always. Do not re-derive this from network semantics.

Initiator is orthogonal to direction

Section titled “Initiator is orthogonal to direction”

Once the direction is fixed by the data flow, a second attribute records who opens the connection:

  • Push — the source Application sends the data to the target.
  • Pull — the target Application fetches the data from the source.
  • Event Driven — neither side calls the other directly; the flow is mediated by an event bus, a queue, or a broker, and the two sides are decoupled in time.

Initiator and direction are independent. CRM → Billing can be Push (CRM sends on each change), Pull (Billing queries CRM on a schedule), or Event Driven (CRM emits a CustomerCreated event that Billing subscribes to). In all three cases the data flow is identical, the source is CRM, and the target is Billing. What differs is the runtime mechanism, not the architecture.

This distinction is what makes “request direction” and “data direction” independent degrees of freedom in the model. Collapsing the two is the single failure mode this page tries to prevent.

Operations are Create, Update, Delete — Read is not one of them

Section titled “Operations are Create, Update, Delete — Read is not one of them”

An Integration can carry a set of Data Objects, and for each Data Object the Integration records which operations it performs on the target side: Create, Update, Delete. That is the complete set. Read is not an integration operation and the product actively rejects it.

The reason is conceptual, not technical. Create, Update, and Delete change the state of the consumer; they are architecturally significant facts about the flow. “Read” is what any application does with its own data — it does not describe a flow between two applications. If a client-server call returns data to the caller, that return value IS the data flow, and the flow is already captured by the direction rule: the data moved from the side that held it to the side that asked for it.

If you want to record “App X reads from App Y”, the correct model is an Integration Y → X with initiator = Pull. Y is the source because the data lives there; X is the target because the data ends up there; Pull records that X initiated the call. You do not need (and cannot express) a “Read” operation on that Integration — the Integration itself is the read.

The CRUD attributes for “which applications touch this data at all” live on the Application, not on the Integration. See Applications → Operates on Data Object for the CRUD declaration per application.

Middleware: model the platform once, the flows separately

Section titled “Middleware: model the platform once, the flows separately”

An integration platform — an ESB, an iPaaS like MuleSoft or Dell Boomi, a message broker like Apache Kafka or RabbitMQ, an API gateway — is a piece of technology. It has a version, a vendor, a lifecycle, and it runs on infrastructure. All of that makes it an IT Component, not an Integration.

The business-meaningful flows that pass through the platform are a different thing. Each flow connects a specific producer to a specific consumer and carries specific data. Those are the Integrations.

Albumi captures both by letting an Integration reference one or more IT Components as its middleware. The Integration itself stays what it is — a flow between two Applications — and the middleware attribute records what it travels through. If the same Kafka cluster carries forty distinct flows, you model one IT Component (the Kafka cluster) and forty Integrations, each of them referencing that IT Component.

Modeling the platform as an Integration, or as an Application, is the mistake that turns the landscape unreadable. Seven ESBs on the landscape diagram is wrong; seven ESBs on the technology inventory plus two hundred Integrations flowing through them is right.

Interfaces on source and target

Section titled “Interfaces on source and target”

An Integration can optionally reference an Interface on each side — a named technical surface the Application exposes (a REST endpoint, a Kafka topic, an SFTP drop, a JDBC link). Interfaces are part of the Application — they live inside the Application record, not as a separate top-level entity — and any Application can expose several of them.

The Integration’s sourceInterface names which surface on the source Application produces this flow; the Integration’s targetInterface names which surface on the target Application consumes it. Both are optional. Setting them pins the flow to concrete technical contracts when those contracts are worth tracking; leaving them unset keeps the Integration at the logical level.

Interface is not a substitute for Integration, and Integration is not a substitute for Interface. An Interface is a capability to be talked to; an Integration is a specific conversation. One REST endpoint can be the source interface of several Integrations (one per consumer). One Integration can reference only one source interface and one target interface — because it is a single flow.

Data Objects carried

Section titled “Data Objects carried”

An Integration can carry one or more Data Objects — the business-level data concepts that actually move. Customer, Order, Invoice, Product. For each Data Object carried, the Integration records the operations performed on it in the target (Create, Update, Delete, as above) and, optionally, transformation notes that describe how the payload is shaped on the way across.

A flow that moves nothing is not a flow. An Integration with no Data Objects is a modeling hole that will show up in dependency analysis and data-lineage reports as a dead edge. Add the Data Objects it carries.

Identity and ownership

Section titled “Identity and ownership”

Every Integration has five things fixed at creation and never null: a name, a source Application, a target Application, an owning organization, and — because the five lifecycle dates drive status — at least a Plan date is usually set in practice. An Integration without both endpoints is not a meaningful artifact; the product will refuse to create one.

Owning organization classifies the Integration for reporting (the department that funds it, the domain that runs it). If nothing specific fits, it sits under the workspace root organization. Organization is not a permission dimension — users in the owning organization have no special rights to the Integration.

Owner (user) is the person accountable for the Integration. This is who gets pinged when the flow breaks, who reviews changes to it, and — governance-wise — who can edit it directly. A non-owner Contributor must propose the change rather than edit directly. Ownership may be unset; organization is always set. See Permissions & Roles for how ownership drives edit rights.

Type, pattern, protocol, format, frequency, authentication

Section titled “Type, pattern, protocol, format, frequency, authentication”

An Integration carries a small set of descriptive attributes that classify the flow without governing it. They drive filters, reports, and portfolio segmentation; they do not affect who can edit the Integration or which stage of the lifecycle it sits in.

  • Integration type — the broad family of flow: API, File Transfer, Message Queue, Event, Data Exchange, Database Link. Pick the primary mechanism. One type per Integration.
  • Delivery pattern — how the flow behaves at the architectural level: Request Response, Fire And Forget, Publish Subscribe, Event Driven, Batch, Streaming. This is about the shape of the interaction, not the transport.
  • Protocol — the concrete wire protocol when one applies: HTTPS, gRPC, AMQP, Kafka, SFTP, JDBC, SOAP, and similar. Optional; leave unset when the Integration is being modeled at the logical level.
  • Data format — the payload encoding: JSON, XML, CSV, Protobuf, Avro, Parquet, Binary. Optional.
  • Frequency — how often the flow runs: Real Time, Near Real Time, Hourly, Daily, Weekly, Monthly, On Demand. Most useful for batch and scheduled flows; can be left unset for event-driven ones.
  • Authentication — the auth scheme the flow uses: None, API Key, Basic, OAuth2, mTLS, SAML, JWT. Optional.

None of these are required. Set them when a report or view you actually use reads them; leave them unset rather than guessing.

Lifecycle

Section titled “Lifecycle”

Integrations move through the same five-stage dated lifecycle as Applications and IT Components. Status is computed from the five dates and today’s date — there is no status dropdown. A flow with an Active date of next quarter is a Plan-stage Integration today and becomes Active automatically when the date is reached.

The stages, the ordering rules, and the editing mechanics are documented once, in Lifecycle & Dates. Everything said there applies to Integrations.

One practical consequence worth repeating: an Integration in Phase-Out is a flow whose replacement is underway. New consumers should not be added to it, and new Data Objects should not be piled onto it. The product does not enforce that — it is a modeling discipline the stage is telling you to follow.

Common modeling mistakes

Section titled “Common modeling mistakes”
  • Drawing the arrow in the direction of the API call. If Billing calls CRM to fetch customers, the Integration is CRM → Billing, not the other way around. The direction is the data’s direction. Initiator records who made the call.
  • Modeling a read-only flow as a Read operation. There is no Read. If App X reads Data Object D from App Y, model an Integration Y → X with initiator = Pull. The “read” is the integration, not an operation on it.
  • Treating the integration platform as an Integration. The ESB, the iPaaS tenant, the Kafka cluster, the API gateway are IT Components. Create one IT Component for the platform and one Integration per business-meaningful flow that passes through it. The Integrations reference the platform as middleware.
  • Creating one Integration per REST endpoint or per Kafka topic. An Integration is a flow between two Applications for a business purpose, not a unit of technical plumbing. Ten endpoints that together move Customer data from CRM to Billing are one Integration. Splitting per endpoint produces a landscape diagram no one can read.
  • Confusing Interface with Integration. An Interface is a surface an Application exposes; an Integration is a specific use of one or two such surfaces. The same REST endpoint can be the source interface of five different Integrations — one per consumer. You do not model each consumer as an extension of the Interface; you model five Integrations, each pointing at the same source interface.
  • Modeling a SaaS vendor’s internal microservice traffic. If you run Salesforce and Workday, the calls Salesforce makes to its own internals are not part of your landscape. Model only the flows between Applications you track on your portfolio.
  • Using organization as access control. Organization is classification. A user in the owning organization of an Integration has no special rights on it. Ownership is per-entity, not per-organization.
Section titled “Related”