Integrations Inventory and Attributes - Glossary of Terms and Phrases

Integrations Inventory and Attributes

Glossary of Terms and Phrases

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.

Legal Disclaimers