Integration catalog and data lineage.
Catalog every integration, every data object that flows through it, and the operation each integration performs on each object - and let lineage emerge from the model.
In any real enterprise, every business application talks to others. The hard part is knowing what data moves where, who changes it, and which flows actually matter when something needs to be migrated or audited. Without a structured model of who carries what to whom, every audit, consolidation, or decommission starts as a discovery project.
Albumi keeps integrations and data objects in the same model, and records the CRUD operation each integration performs on each object. From that single declaration, lineage, impact analysis, and compliance questions all come from the same source of truth instead of three spreadsheets that drift apart.
What goes in the model.
Integration catalog
Every integration records source, target, type, protocol, format, authentication, delivery pattern, initiator, frequency, lifecycle, owner, and the middleware it depends on.
Data object catalog
Customer, Order, Invoice, Claim, or any other business object carries its own classification, PII flag, hierarchy, retention, and ownership metadata.
CRUD authority per flow
Each integration states whether it creates, reads, updates, or deletes the data objects it transports on the target side. That is where lineage starts.
Middleware as real components
ESB, iPaaS, Kafka, and similar platforms live as first-class IT Components instead of labels buried in integration notes. Open the component and see every integration depending on it.
Auto-generated lineage views
Every data object can render a live producer-carrier-consumer map directly from the model, with CRUD labels on nodes and flows.
Inline dependency context
Applications, integrations, and data objects all expose the connected entities you need without a separate reporting step. The catalog becomes the documentation.
What that unlocks.
Compliance audits by filter
PII flags, classification, and CRUD authority sit together, so questions about regulated data become queries instead of audit projects. Compliance happens in the same UI as architecture, not in a separate stale audit module.
Migration scope before decommission
Before retiring an app, integration, or middleware layer, you can see the real downstream impact instead of interviewing half the company or reconstructing the landscape from tickets.
Better onboarding
New engineers and architects can read the model to understand how systems exchange data without relying on tribal memory. The model stays useful because it is the source of truth, not a copy of it.
System-of-record debates with evidence
You may not designate a formal System of Record yet, but you can already see which applications create a data object, which only read it, and where update authority actually sits.
Lineage details.
Can one integration carry multiple data objects?
Yes. Each carried data object gets its own CRUD declaration - integration A → B might Create Customer and Update Order at the same time, and both Customer's and Order's lineage pages will reflect this integration. There's no upper limit; ETL pipelines and message buses commonly carry several data objects per integration.
Can data objects be organized hierarchically?
Yes. Customer can contain Contact, Address, and Payment Method as child data objects; Insurance Data can contain Claims Data, Reinsurance Data, and so on. The hierarchy is your model - high-level for stakeholder conversations, drilled-down for technical work, in one structure. Classification and PII flags can be set per node.
What integration lifecycle stages are tracked?
Plan, Phase-In, Active, Phase-Out, End-of-Life - same lifecycle vocabulary as applications. The lifecycle bar surfaces on every integration's detail page. Filter the catalog by lifecycle to find integrations that need to be retired alongside their source or target applications.
Where does middleware information live in the model?
Middleware platforms (SAP BTP Integration Suite, MuleSoft, Apache Kafka, etc.) are first-class IT Component entities in the workspace, not just labels on integrations. Each integration references the middleware components it runs through. Open an IT Component to see every integration depending on it - useful when consolidating an ESB or migrating off a legacy iPaaS.
Does Albumi designate a System of Record for each data object?
Not currently. Albumi doesn't auto-designate a single System of Record - that's an open product question. What you can compute today is which applications declare a Create operation on a given data object (the producers) versus which only Read (the consumers). Work with explicit CRUD authority for now, rather than a single-SoR designation.
Model the flows you actually depend on.
Build the catalog that turns your integration landscape from a tribal-knowledge spreadsheet into a queryable model.