An integration inventory explains dependency in operating terms
An enterprise integration inventory should answer more than which endpoints exist. It connects each interface to a business journey, accountable owner, information exchange, failure consequence and recovery path. That context allows teams to decide what must be protected, changed, tested or retired.
Start with critical journeys and trace the systems they cross. Record applications, files, queues, APIs, scheduled jobs, manual uploads and local automations. A nightly spreadsheet may be less elegant than an API but more important to Monday morning operations. Excluding it creates a false architecture.
Keep the inventory small enough to maintain and structured enough to query. Use stable identifiers for systems and interfaces, then link technical details rather than copying every configuration into one document. The inventory is a decision map, not a substitute for code, monitoring or runbooks.
| Dimension | Record | Why it matters |
|---|---|---|
| Purpose | Journey and outcome supported | Sets business criticality |
| Ownership | Business, application and support owners | Clarifies decisions and response |
| Exchange | Entities, direction, timing and volume | Explains data movement |
| Control | Identity, validation and monitoring | Shows how trust is maintained |
| Failure | Detection, impact, retry and recovery | Makes resilience testable |
Choose a boundary and naming model
Define what counts as an integration for this inventory. Include exchanges that cross system, ownership or security boundaries and any manual bridge that materially supports a service. Do not record every internal function call, and do not omit an exchange merely because no development team owns it.
Give every interface a stable name based on source, destination and purpose. Record aliases used by teams and vendors. Clear identifiers prevent a risk, incident or change from referring to “the CRM feed” when several flows share that description.
Separate the logical exchange from its implementations. A customer update may travel through a managed platform today and a direct API tomorrow while serving the same business purpose. This distinction supports migration analysis and preserves history when technology changes.
Map information, not just transport
Record the business entities and important attributes exchanged, their authoritative source and how identifiers are matched. Note whether the interface creates, updates, appends, deletes or merely reads. A transport diagram cannot reveal which system is allowed to decide truth.
Document frequency, latency, volume, ordering, duplication tolerance and time-zone treatment. A daily batch and a near-real-time event can both be described as automated while producing very different operating choices and recovery problems.
Classify sensitivity and retention at a useful level. Avoid copying whole data catalogues, but identify personal, financial, confidential or security-relevant content that changes access, logging, transfer or deletion requirements. Link to the authoritative record for detailed classification.
Expose authentication and trust boundaries
Record identities, credentials, scopes, network boundaries, encryption and certificate ownership for every interface. Include expiry and rotation. Integrations often fail not because the payload changed but because a service account, secret or trusted endpoint changed without a visible owner.
Distinguish supplier-managed, customer-managed and shared controls. A managed connector may reduce local code while creating dependence on the provider’s permissions, release cycle and incident handling. Keep that dependency visible beside the convenience.
Where software components or connectors materially affect supply-chain risk, consult the CISA SBOM resources library. An SBOM can improve component transparency, but it does not replace interface ownership, configuration evidence or an assessment of the actual service.
Document failure as a designed state
For each flow, describe how failure is detected, who receives the signal and how business users learn that data may be incomplete. Record retries, queues, dead-letter handling, reconciliation and manual alternatives. Silence is not a recovery strategy.
Test partial failure. A successful request followed by a failed acknowledgement can create duplicates; an out-of-order update can restore an old value; a delayed reference record can reject valid transactions. Include these scenarios in integration and operational acceptance.
State recovery objectives in relation to the journey, then validate them. An interface may restart within minutes while the backlog takes hours to clear. Measure restored business state and reconciled information, not only the availability of a technical endpoint.
Connect monitoring to ownership and action
Record which signals show availability, latency, throughput, errors, backlog, data quality and business completion. A green HTTP status can coexist with rejected records or an empty feed. Choose signals that expose the failure modes the journey actually carries.
Every alert needs a responsible team, usable context, severity rule and escalation path. Test whether the named team has access to logs, credentials, supplier contacts and reconciliation tools. A contact list does not prove that a responder can restore the service.
Review recurring incidents and manual repairs with the service desk management pathway. Integration demand should influence product, data and process backlogs instead of remaining a queue of disconnected technical tickets.
Use the inventory for change and rationalisation
Before changing a system, query inbound and outbound dependencies, owners, critical periods, test environments and recovery routes. Require teams to confirm the result, because an inventory can lag behind local automation. The review is both a control and a way to improve the record.
Identify duplicate exchanges, unused reports, point-to-point chains and flows with no accountable consumer. Do not retire them from traffic alone. A low-frequency regulatory or year-end process may be important despite months of inactivity. Confirm the business purpose and calendar.
The GOV.UK Service Standard guidance on open standards and APIs connects interoperability with flexibility and authoritative data. Its context is public services, but the questions help any organisation examine avoidable coupling and duplicated sources.
Keep evidence current through lightweight controls
Update the inventory through normal release, onboarding and decommissioning workflows. Require an interface record before production access and a closure record when it is removed. Periodically compare the inventory with gateway, scheduler, repository, identity and monitoring evidence.
Assign review frequency by criticality and change rate. A stable low-impact file does not need the same cadence as a privileged real-time customer interface. Trigger review after incidents, supplier changes, authentication changes and material data expansion.
A trustworthy inventory will never be perfect. It becomes useful when gaps are visible, owners can correct them and important decisions start by consulting it. The measure of success is not the number of rows but whether teams can explain and test the dependencies behind a change.
Run an integration inventory workshop
Select one critical journey and bring process, application, data, security and support owners together. Trace the normal path, an exception and a recovery. Capture unknowns explicitly and assign evidence gathering rather than filling the diagram with assumptions.
Validate the map against observable sources: configuration, schedules, API gateways, logs, service accounts, file locations and support records. Compare what architecture expects with what operations actually uses. Differences are investigation leads, not automatic proof that one side is wrong.
Finish with three decisions: the most important unowned dependency, the weakest recovery path and the next planned change that needs this evidence. This turns documentation into an operating control and gives the organisation a practical starting point for the broader enterprise application landscape.
Reconcile the inventory with an observable sample
Select integrations from different patterns: synchronous API, scheduled batch, event stream, managed connector and manual file. Compare each record with configuration, credentials, schedules, monitoring and recent support. Record gaps by consequence rather than demanding that the whole inventory become perfect at once.
Trace one record through source, transformation, transport, destination and business use. Confirm identifiers, timing, failure handling and ownership. A sample that cannot be explained end to end identifies the next evidence task more clearly than another architecture workshop.
Publish coverage and date with every inventory report. Decision makers should know which systems and patterns were reconciled, which relied on owner confirmation and which remain unknown. Honest scope makes the inventory safer to use and easier to improve.
