Integrations Inventory and Attributes

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.

AI agents are effective tools for bootstrapping the Integrations Inventory at Crawl maturity, particularly for integrations that are publicly documented or architecturally standard. An AI agent can be prompted to generate initial integration records from architecture diagrams, data flow diagrams, system interface specifications, or integration platform exports — producing a draft inventory that practitioners validate and extend rather than building from scratch. AI-generated records must be treated as a starting point requiring human validation, not as authoritative records. The generation method and validation status should be documented in the Provenance and Audit Attributes category of each AI-generated record.

Where no automated discovery is possible and integration platform exports are unavailable, the Integrations Inventory must be built through structured discovery sessions with application owners, integration architects, and data engineers. A focused session of two to four hours per application domain, with practitioners who understand both the sending and receiving sides of each integration, typically produces a workable set of Crawl-level records for that domain. Prioritize high-criticality and sensitive-data integrations first — a partial inventory that covers Mission-Critical and PII-carrying integrations is immediately governable, even before the full portfolio is documented.

Section B — Ownership and Accountability

Every inventory must have a named owner accountable for the accuracy, completeness, and governance of the inventory as a whole. Inventory ownership is distinct from the accountability of individual integration records: the record Accountable Party is responsible for one specific integration; the inventory owner is accountable for the schema, the governance process, and the overall health of the Integrations Inventory as a governance artifact. For the Integrations Inventory, the Enterprise Architecture function or an Integration Competency Center is the natural organizational owner where one exists. In organizations without a formal integration governance function, APM or a shared IT governance body is an appropriate alternative. Ownership by committee without a named accountable individual is not recommended — it produces diffused accountability and inconsistent governance.

Section C — Lifecycle and Review Cadence

The Integrations Inventory is a living governance artifact that changes every time a system is added, retired, or modified. It must be actively maintained through a formal lifecycle — not treated as a one-time discovery exercise. Every integration record moves through defined lifecycle states: Proposed, Active, Under Review, Deprecated, and Retired. Lifecycle state is governed by the inventory owner and documented in the Lifecycle and Status Attributes category of each record. Reconciliation cadence should be established and enforced: Crawl maturity, quarterly reconciliation minimum; Walk maturity, monthly reconciliation or event-driven reconciliation triggered by any system change that affects integration endpoints; Run maturity, continuous or near-continuous reconciliation through integration platform API feeds, with human review for exceptions and new discoveries. An integration that is retired but not marked Retired in the inventory is an inventory gap that will corrupt dependency analysis.

Section D — Data Quality and Starting Approach

Do not attempt to populate all attributes for all integrations simultaneously. The most common failure mode for integration inventory initiatives is scope overreach — attempting to document every attribute for every integration before any governance value is delivered. Recommended approach: (1) Identify all known integrations and create a stub record for each with only the 14 Baseline Integration Attributes. This produces a complete, if thin, inventory that is immediately usable for dependency analysis and sensitivity governance. (2) Validate Baseline completeness — all 14 Crawl attributes populated for all known integrations — before advancing to Walk. (3) Populate Walk attributes systematically, prioritizing Mission-Critical integrations and those carrying sensitive data first. (4) Introduce Run attributes only when integration platform tooling and observability infrastructure justify automated derivation. Quality threshold: Crawl attributes must be 100% complete before Walk begins. An integration record with any Crawl attribute missing is a governance gap.

Section E — Access Control

The Integrations Inventory contains governance-sensitive data including integration technology details, endpoint information, and sensitivity classifications. Access should be governed explicitly: read access broadly available to APM, TPM, EA, and security teams; write access restricted to the inventory steward, designated integration owners, and authorized automated feeds from integration platforms; schema change access reserved for the inventory owner and governing body. The Endpoint / Topic attribute at Run maturity may contain sensitive connection details — consider storing literal endpoint values in a secured secrets management system and referencing by secret name in the inventory record.

Section F — Change Management

The attribute schema of the Integrations Inventory is itself a governed artifact. Schema changes — adding, removing, or renaming attributes — follow a five-step process: Propose → Review → Approve → Implement → Communicate. Schema changes should not be made during an active reconciliation cycle. Changes must be recorded in the inventory document’s change log. Integration records themselves must be updated whenever a change to a source or target system affects the integration’s attributes — a system migration that changes an API endpoint, authentication method, or data format requires corresponding record updates before the change is deployed to production.

Section G — Archival and Retention

When an integration is decommissioned, its record is not deleted — deletion destroys audit history and breaks historical dependency analysis. Update the Lifecycle Status to Retired, retain the record for one full reconciliation cycle in the active inventory, then archive it. Archived records remain queryable for historical analysis but are excluded from active governance reporting and dependency counts. Retain indefinitely any record for an integration involved in a significant decision — a system retirement, a data breach, a compliance finding, or a major investment decision. For all others, define a retention period consistent with applicable regulatory requirements and organizational policy.