Integrations Inventory and Attributes

Description — The specific technology, tool, or platform used to implement this integration. Every distinct value in this attribute across all integration records is a nomination for a record in the Software Technologies Inventory.

Benefit(s) — The Integration Technology attribute is the primary source of integration tooling data for the enterprise. Aggregating across all integration records reveals the full integration technology landscape — how many platforms are in use, which are most prevalent, and which are redundant candidates for rationalization.

Source — Manual.

Examples — Informatica IICS, MuleSoft Anypoint, Azure Data Factory, AWS EventBridge, Apache Kafka, Python (custom), IBM MQ, Boomi AtomSphere, Talend, TIBCO, custom SFTP script

Notes — Use the vendor product name and version where known. Point-to-point integrations with no middleware should be recorded as the specific language or tool used (e.g., Python, Java, Shell Script).

Description — The specific communication protocol or data exchange technology used in this integration.

Benefit(s) — Enables protocol-level portfolio analysis. Identifying all SOAP integrations targeting a system planned for retirement reveals the remediation scope before migration begins.

Source — Manual.

Examples — REST, SOAP, GraphQL, AMQP, MQTT, SFTP, JDBC, gRPC, EDI X12, HL7 v2, FHIR R4, AS2, FTP/S

Description — The format of the payload exchanged between source and target.

Benefit(s) — Identifies format dependencies that must be accounted for during system migrations or API versioning. A target system migration may require format translation if the new system does not support the existing format.

Source — Manual.

Examples — JSON, XML, CSV, Parquet, Avro, Protocol Buffers, HL7 FHIR, EDI X12, PDF, Excel, Fixed-Width Flat File

Description — The mechanism used to authenticate the integration connection between source and target.

Benefit(s) — Surfaces authentication weaknesses across the integration portfolio. Integrations using Basic Auth or API Key without rotation policies are security governance findings waiting to happen.

Source — Manual.

Examples — OAuth 2.0, API Key, mTLS (Mutual TLS), Basic Auth, SAML, AWS IAM Role, Azure Managed Identity, SSH Key

Description — The integration platform or middleware layer that brokers or orchestrates this integration, if any. Distinct from Integration Technology — Middleware/Platform captures the governing platform; Integration Technology captures the specific implementation tool.

Benefit(s) — Enables platform-level governance: which integrations are governed by the enterprise integration platform and which are unmanaged point-to-point connections. Unmanaged integrations are the primary source of integration debt.

Source — Manual.

Examples — MuleSoft Anypoint Platform, Azure Service Bus, AWS EventBridge, IBM MQ, Apache Kafka, None (point-to-point)

Notes — If no middleware or platform governs this integration, record None (point-to-point). Point-to-point integrations with no middleware are a key risk indicator.

Description — The version of the API or interface contract in use for this integration.

Benefit(s) — Critical for change impact analysis. A source or target system upgrade may deprecate an API version that one or more integrations depend on. Without version tracking, API deprecation risks are invisible until they cause failures.

Source — Manual.

Examples — v1.0, v2.3, REST API v4, SOAP WSDL 2021-Q3, HL7 FHIR R4

Description — The specific API endpoint URL, message queue name, topic identifier, or file path that identifies the integration channel.

Benefit(s) — Enables precise technical impact analysis and automated monitoring configuration. At Run maturity, endpoint data feeds integration monitoring tools directly.

Source — Manual.

Notes — Sensitive — populate with appropriate access controls. Consider storing in a secured secrets management system and referencing by secret name rather than recording the literal value in the inventory.