Integrations Inventory and Attributes on International Foundation for Information Technology (IF4IT)

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

About This Inventory

The Integrations Inventory governs every connection through which data or information moves between two entities in the enterprise or between the enterprise and an external party. Each Noun Instance is a single, uniquely identified Integration — an entity-agnostic record that captures the source, the target, the payload, the technology, the environments, and the sensitivity profile of a specific data or information flow. The inventory is not limited to Application-to-Application integrations: any two entities of any recognized Noun Type may appear as source or target, making this inventory the enterprise’s complete data flow map regardless of what kinds of entities are connected.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The following terms are used throughout this document with specific meanings. Terms defined in the IF4IT Enterprise Inventory Management Best Practices document or in discipline-specific Best Practices documents (APM, TPM, etc.) are not duplicated here — refer to those documents for broader inventory governance and discipline-specific vocabulary.

Term	Definition
Integration	A governed connection through which data or information moves between two entities. Also known as a Data and Information Integration — reflecting that both structured data (JSON, CSV, database records) and unstructured information (PDF documents, images, audio files) flow through governed integrations. Each Integration is a Noun Instance in the Integrations Inventory with a unique Semantic ID and a governed attribute set.
Entity-Agnostic Model	The structural design of the Integrations Inventory in which the source and target of any integration can be any recognized Noun Type — Application, Database, File System, Queue, Human, External Partner, or any other. No integration is required to have an Application on either end. This makes the inventory applicable to every data and information flow in the enterprise regardless of what kinds of entities are connected.
Reified Relationship	An integration is a reified relationship — a relationship between two entities that has been promoted to a first-class governed record (a Noun Instance) with its own attributes, identity, lifecycle, and governance. Reification makes implicit connections explicit, governable, and queryable.
Source Entity	The entity that initiates or sends data in an integration. Described by three attributes: Source Entity Type (what kind of entity it is), Source Entity ID (its system-level identifier), and Source Entity Semantic ID (its human-readable name).
Target Entity	The entity that receives data in an integration. Described by three attributes: Target Entity Type, Target Entity ID, and Target Entity Semantic ID — mirroring the Source Entity structure.
Integration Payload	The business-level description of the data or information being transmitted through an integration. The Payload describes what is moving, not how it moves. Both structured data and unstructured information are valid payloads.
Integration Semantic ID	The human-readable unique name for an integration, typically constructed by concatenating Source Entity Semantic ID, Target Entity Semantic ID, and Integration Payload. Example: Salesforce-SAP-CustomerProfile. Permanent once assigned.
Data Sensitivities	The sensitivity classifications of data or information transmitted through an integration. A [Multi-Value] attribute supporting: PII, PHI, PCI, PFI, Confidential, Regulated, and None. Enables per-integration sensitivity governance rather than entity-level approximation.
External Environment	A valid value for Source Environment and Target Environment indicating that the entity exists outside the enterprise boundary — a third-party partner, regulator, customer, or external service provider. When either environment is External, the integration requires enhanced security, cross-border data flow, and compliance governance.
Point-to-Point Integration	An integration implemented directly between source and target without a governing middleware platform. Recorded in the Middleware / Platform attribute as None (point-to-point). Point-to-point integrations represent the highest integration risk profile — typically undocumented, unmonitored, and with no retry or error handling logic.
Integration Complexity Map	The aggregate view of all integration records in the Integrations Inventory, showing the network of connections between all enterprise entities. Integration count per entity is one of the most reliable leading indicators of system retirement cost and risk — a system with 47 integrations is categorically harder to retire than one with 3.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Integrations Inventory governs every connection through which data or information moves between two entities — whether those entities are Applications, Databases, File Systems, Queues, APIs, Human actors, External Partners, or any other recognized Noun Type. A governed integration qualifies for a record when it represents a distinct, identifiable data or information flow with a named source, a named target, a describable payload, a specific technology, and a defined execution context (the environments involved). Every entry is a Noun Instance of the Integration Noun Type — a unique integration with its own Semantic ID, its own governance attributes, its own owner accountability, and its own risk profile.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Enterprise Architecture depends on this inventory as the primary source of data flow structure in the Enterprise Model. Without the Integrations Inventory, EA cannot describe how data moves between systems, cannot produce accurate application dependency diagrams, and cannot assess the true complexity of any proposed system change. The integration map is the connective tissue of the enterprise architecture — it shows not just what systems exist but how they are coupled, what data they share, and what would break if any one of them changed. EA uses this inventory to identify tightly coupled system clusters, model the impact of target-state architecture changes, and design decoupling strategies grounded in actual integration data rather than architectural assumptions.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Integrations Inventory has its most direct relationship with the Applications Inventory and Attributes. Applications are the most common entity type appearing as source or target in integration records. Every Application record in the Applications Inventory can carry a Calculated attribute for integration count — derived from this inventory by counting all records where the Application appears as source or target. The Integrations Inventory is authoritative for integration records; the Applications Inventory is authoritative for Application records. The connecting attributes are the Source Entity Semantic ID and Target Entity Semantic ID on the integration side, matched to Application Semantic IDs on the application side.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Integrations Inventory is one of 38 recognized Noun Types in the IF4IT Enterprise Inventory Management taxonomy — the master catalog of all enterprise inventory types. The full taxonomy, its governance principles, and the Inventory of Inventories are documented in the IF4IT Enterprise Inventory Management Best Practices document. Practitioners should read that document to understand how the Integrations Inventory fits within the broader enterprise governance framework.

The six most closely related Noun Types to Integration, with their named relationships: (1) Application — an Application is the most common entity appearing as Source or Target in an Integration; the Integrations Inventory is the primary source of application coupling and dependency data for APM. Refer to the Applications Inventory and Attributes for the published Applications Inventory. (2) Software Technology — the Integration Technology attribute of every Integration record directly seeds and reconciles the Software Technologies Inventory; every distinct integration tool in use enterprise-wide surfaces here first. The Software Technologies Inventory is not yet published — refer to the IF4IT Enterprise Inventory Management Best Practices document. (3) Capability — an Integration enables the execution of one or more Capabilities by delivering the data those Capabilities require. The Capabilities Inventory and Attributes is published. (4) Data and Information Type — the Integration Payload maps to one or more Data and Information Types; the Integrations Inventory is the primary source of enterprise data flow lineage. The Data and Information Types Inventory is not yet published — refer to the IF4IT Enterprise Inventory Management Best Practices document. (5) Environment — an Integration connects a specific Source Environment to a specific Target Environment; the Integrations Inventory is the primary source of cross-environment data flow governance. The Environments Inventory is not yet published — refer to the IF4IT Enterprise Inventory Management Best Practices document. (6) Data Sensitivity Type — the Data Sensitivities attribute on each Integration record maps to formal Data Sensitivity Type records; the Integrations Inventory is the primary source of per-flow sensitivity governance. The Data Sensitivity Types Inventory is not yet published — refer to the IF4IT Enterprise Inventory Management Best Practices document.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Section A — Sourcing and Harvesting

Before building the Integrations Inventory from scratch, assess whether integration records already exist in any form in the enterprise. Common sources include: integration platform management consoles (MuleSoft Anypoint, Azure Integration Services, AWS EventBridge, IBM MQ, Kafka management tools, and similar platforms typically maintain a catalog of active integrations that can be exported); ITSM configuration management databases (CMDBs often capture integration relationships as configuration item relationships, though typically at lower fidelity than a governed inventory requires); network monitoring and API gateway logs (can reveal undocumented integrations through traffic analysis); application team interviews and architecture review sessions (the most reliable source for point-to-point integrations that exist outside any platform governance). Harvesting from any of these sources reduces the initial discovery effort and surfaces integrations that no single team knows about in full.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

What Is an Integration

An Integration — also known as a Data and Information Integration — is a governed connection through which data or information moves between two entities. The word “integration” in this context is deliberately broad: it encompasses any distinct, identifiable flow of data or information between a source and a target, regardless of what technology implements it, what format the data takes, or what kinds of entities are connected. A real-time API call between two applications, a nightly batch file transfer from a database to a file system, a manual data entry process where a human operator moves information from one system to another, and an automated EDI transaction from an enterprise system to an external trading partner are all Integrations in the governance sense of this inventory. What qualifies a flow as a governed integration is that it can be uniquely identified, it has a source and a target, it carries a describable payload, and it matters to the enterprise if it fails.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Descriptive attributes capture the core identity of each Integration Noun Instance — what it is called, what it connects, what it transmits, and in which direction.

Attribute Name

Maturity

Description and Notes

Integration Semantic ID

Crawl

Description — A human-readable, self-documenting unique name for this integration, typically constructed by concatenating Source Entity Semantic ID, Target Entity Semantic ID, and Integration Payload. Permanent once assigned.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Classification attributes position each Integration within the enterprise integration taxonomy — the type of mechanism it uses and the behavioral pattern it implements.

Attribute Name

Maturity

Description and Notes

Integration Type

Crawl

Description — The broad category of integration mechanism — what kind of integration this is at the architectural level.

Benefit(s) — Enables portfolio-level analysis of integration patterns. Identifying all SFTP file transfers reveals manual, batch-oriented coupling that is typically a modernization target. Identifying all point-to-point API integrations reveals direct dependencies that bypass integration governance.

Mon, 01 Jan 0001 00:00:00 +0000

Security attributes capture the sensitivity of data moving through this Integration and the access controls governing the integration channel.

Attribute Name

Maturity

Description and Notes

Data Sensitivities

[Multi-Value]

Crawl

Description — The sensitivity classifications of the data or information transmitted through this integration. A single integration may carry multiple sensitivity types simultaneously.

Benefit(s) — Enables per-integration sensitivity governance rather than entity-level approximation. Two applications may have five integrations between them but only one that transmits PII — this attribute makes that distinction explicit and actionable for privacy impact assessments, regulatory audits, and encryption enforcement.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Data and Information attributes capture the specific data objects, formats, and transformations involved in this Integration — connecting the integration map to the enterprise data architecture.

Attribute Name

Maturity

Description and Notes

Source Data Object

Walk

Description — The specific entity, table, schema, object, file, queue, or topic in the source system that provides the data for this integration.

Benefit(s) — Enables precise data lineage tracing. When a source system is decommissioned or its schema changes, Source Data Object identifies exactly which integrations are affected and what must be remapped.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Geographic and Jurisdictional attributes capture whether this Integration crosses national or jurisdictional boundaries, triggering data sovereignty and cross-border transfer governance.

Attribute Name

Maturity

Description and Notes

Cross-Border Data Flow

Walk

Description — Whether this integration transmits data across national or jurisdictional boundaries — and if so, which countries or jurisdictions are involved.

Benefit(s) — Immediately surfaces integrations subject to data sovereignty and cross-border transfer regulations. GDPR, CCPA, and similar frameworks impose specific requirements on cross-border data flows that are invisible without this attribute.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Temporal and Effective Date attributes capture validity windows for time-bounded Integrations.

The IF4IT has not yet identified standard attributes in this category for the Integrations Inventory. This does not mean no such attributes exist — organizations building this inventory are encouraged to identify and define attributes in this category that are relevant to their specific context and governance needs.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Contractual and Legal attributes capture any legal instruments governing the terms under which this Integration operates.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Vendor and Supplier attributes capture external parties involved in delivering or supporting this Integration.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

IT Environment attributes capture the specific operating environments of the source and target entities — the environment-pair that defines where this Integration runs.

Attribute Name

Maturity

Description and Notes

Source Environment

Crawl

Description — The IT operating environment in which the source entity resides for this integration record. External is a valid value, indicating the source entity exists outside the enterprise boundary.

Benefit(s) — Enables cross-environment integration governance. Without Source Environment, the Integrations Inventory cannot distinguish a Production-to-Production integration (live operational dependency) from a Production-to-UAT integration (test data flow requiring data sanitization governance) or an External-to-Production integration (inbound third-party feed requiring enhanced security controls).

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Skills and Competencies attributes capture the technical skills required to build, maintain, and support this Integration.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Provenance and Audit attributes capture metadata about the integration record itself — how it was created, when it was last updated, and the reliability of its content.

Attribute Name

Maturity

Description and Notes

Record Created Date

Walk

Description — The date on which this integration record was first created in the inventory.

Benefit(s) — Supports audit and compliance reporting.

Source — Manual.

Examples — 2024-03-15, 2023-11-01

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Risk attributes capture the known risk profile of each Integration — the likelihood and impact of failure, data compromise, or compliance breach.

Attribute Name

Maturity

Description and Notes

Assessed Risk

Crawl

Description — The overall risk rating for this integration — the combined assessment of likelihood and impact of integration failure, data loss, or security compromise.

Benefit(s) — Surfaces high-risk integrations for priority governance attention. The combination of Assessed Risk, Business Criticality, and Data Sensitivities produces the integration risk profile that drives monitoring investment, remediation prioritization, and change management controls.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Compliance and Regulatory attributes capture the regulatory obligations that apply to data transmitted through this Integration and the current compliance status.

Attribute Name

Maturity

Description and Notes

Regulatory Obligations

[Multi-Value]

Walk

Description — The specific regulatory requirements, laws, or compliance frameworks that apply to the data transmitted through this integration.

Benefit(s) — Enables per-integration regulatory scoping. When a regulator asks for all integrations in scope for GDPR Article 28 or HIPAA Security Rule, this attribute produces the answer directly.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Financial attributes capture the cost profile of each Integration — what it costs to build, license, and maintain annually.

Attribute Name

Maturity

Description and Notes

Annual Integration Cost

Walk

Description — The total annual cost to build, license, and maintain this integration, including middleware platform licensing allocation, engineering maintenance time, and monitoring tooling.

Benefit(s) — Enables cost-per-integration analysis. High-cost integrations that carry low-criticality payloads are rationalization candidates. The aggregate of Annual Integration Cost across all integrations reveals the enterprise’s total integration investment.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Relationship attributes connect each Integration to related Noun Instances in other inventories, forming the edges of the Enterprise Model graph for the Integration Noun Type.

Every attribute in this category is Calculated or Derived from records in other inventories. No manual data entry is required for any attribute in this category. Do not create data entry fields for any attribute listed here.

Attribute Name

Maturity

Description and Notes

Source Inventory Reference

Run

Description — The Semantic ID of the source entity in its governing Noun Type inventory — the formal cross-inventory reference connecting this integration record to the source entity’s authoritative record.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Applications are the most common entity type appearing on either side of an integration record. The Integrations Inventory and the Applications Inventory are mutually reinforcing: the Applications Inventory is authoritative for Application records and their attributes; the Integrations Inventory is authoritative for integration records and the data flows they govern. The connecting attributes are the Source Entity Semantic ID and Target Entity Semantic ID on the integration side — when Source Entity Type or Target Entity Type equals Application, those Semantic IDs reference Application records in the Applications Inventory.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Integrations Inventory is the primary source of integration technology data for the Software Technologies Inventory (not yet published — refer to the IF4IT Enterprise Inventory Management Best Practices document for its current definition in the Noun Type taxonomy). Every distinct Integration Technology value across all integration records nominates a Software Technology record. The relationship is seeding: the Integrations Inventory creates demand for Software Technology records by documenting which integration tools are in operational use.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Integrations enable Capabilities — many business capabilities depend on data flowing from one system to another to function. An Invoice Processing capability requires integration flows that deliver supplier invoices from procurement systems to accounts payable systems. A Customer Onboarding capability requires integration flows that distribute customer data to CRM, ERP, and identity management systems. The Integrations Inventory documents which integrations support which capabilities through its Related Capabilities relationship attribute.

The connecting attribute is the Capability Semantic ID referenced in the Related Capabilities relationship attribute of integration records. The Capabilities Inventory and Attributes is published and available. When this relationship is maintained, capability-level impact analysis becomes possible: if a specific integration fails, which capabilities are impaired? If an integration must be retired, which capabilities require alternative data flow paths before retirement can proceed?

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Integration Payload attribute captures the business-level description of the data or information flowing through each integration. The Data and Information Types Inventory (not yet published — refer to the IF4IT Enterprise Inventory Management Best Practices document) will provide the formal taxonomy to which those payloads are mapped. The relationship is consumption: the Integrations Inventory consumes Data and Information Type definitions to formally classify its payloads.

When the Data and Information Types Inventory is published, the Integration Payload attribute will be supplemented by a formal reference to one or more Data and Information Type Semantic IDs. Until then, Integration Payload values are documented as descriptive text. The Integrations Inventory is itself a discovery source for the Data and Information Types Inventory — the set of distinct Payload values across all integration records reveals the range of data and information types the enterprise moves through its integration fabric.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

Every integration record carries a Source Environment and Target Environment attribute that identifies the IT operating environments in which the source and target entities reside. The Environments Inventory (not yet published — refer to the IF4IT Enterprise Inventory Management Best Practices document) will govern the formal taxonomy of IT operating environments to which these values are mapped.

The relationship is consumption: the Integrations Inventory consumes environment definitions to formally classify its source and target environments. Until the Environments Inventory is published, environment values are documented using the standard value set (Development, Systems Integration Testing, User Acceptance Testing, Production, Disaster Recovery, External). When published, Source Environment and Target Environment will carry formal Environment Semantic ID references.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Data Sensitivities attribute on each integration record carries the sensitivity classifications of data transmitted through the integration. The Data Sensitivity Types Inventory (not yet published — refer to the IF4IT Enterprise Inventory Management Best Practices document) will govern the formal taxonomy of sensitivity classifications to which these values are mapped.

The relationship is consumption: the Integrations Inventory consumes Data Sensitivity Type definitions to formally classify its integration payloads by sensitivity. Until the Data Sensitivity Types Inventory is published, Data Sensitivities values are documented using the standard value set (PII, PHI, PCI, PFI, Confidential, Regulated, None). When published, Data Sensitivities will carry formal Data Sensitivity Type Semantic ID references through the Related Data Sensitivity Types relationship attribute.

Integrations Inventory and Attributes

Mon, 01 Jan 0001 00:00:00 +0000

The Integrations Inventory and Attributes document is one of many Noun Type inventories in the IF4IT Enterprise Inventory Management taxonomy. Each inventory in the taxonomy governs a distinct class of enterprise asset, relationship, or organizational construct — and each contributes its records and relationships to the Enterprise Model that connects them all. The full catalog of recognized Noun Types, the principles that govern inventory design and federation, the Inventory of Inventories, and guidance for building, connecting, and maturing a complete enterprise inventory program are documented in the IF4IT Enterprise Inventory Management Best Practices document. Practitioners who find value in the Integrations Inventory are encouraged to explore the broader taxonomy — each additional inventory that is built and governed strengthens the Enterprise Model and expands the range of questions that AI-assisted enterprise analysis can answer. The IF4IT welcomes contributions from practitioners who develop attribute categories, attribute definitions, or governance approaches not covered in this document — your real-world experience is how this framework matures.