An Integration Is a Business Dependency with Technical Machinery
Integrations connect business processes across application boundaries. When they fail, the consequence is often operational: orders stop, resources disappear, invoices do not post or reporting becomes incomplete.
Integration management therefore covers ownership, design, build, testing, monitoring and support—not only interface development.
23.1 Maintain an Integration Catalogue
Record source, target, business purpose, data objects, frequency, pattern, owner, security classification, volumes and support team.
The catalogue provides one view of the integration landscape and release dependencies.
23.2 Define Business Ownership
Every interface should have a business owner who understands the consequence of delayed or incorrect data.
Technical ownership alone is insufficient for deciding reconciliation and exception priorities.
23.3 Choose the Right Pattern
Select synchronous, event-driven, asynchronous, batch or file-based approaches based on latency, reliability, volume and coupling requirements.
Do not use real-time integration simply because it appears more modern.
23.4 Design for Failure
Define retry, idempotency, duplicate handling, dead-letter or exception queues, alerting and manual recovery.
The unsuccessful path deserves as much design attention as the happy path.
23.5 Secure the Interface
Use least privilege, secure credential handling, encryption, appropriate network controls and audit logging.
Review sensitive fields and regulatory restrictions on data movement.
23.6 Test End to End
Validate field mapping, business rules, sequencing, volume, performance, failure recovery and reconciliation across real system boundaries.
A unit-tested API is not an end-to-end tested business integration.
23.7 Monitor Operational Health
Define dashboards and alerts around message failure, backlog, latency and reconciliation exceptions.
Monitoring should identify meaningful business impact rather than generate unmanageable noise.
23.8 Define Support and Change Ownership
Document who investigates source issues, integration-platform failures and target rejects. Coordinate changes across all dependent systems.
Interface ownership becomes especially important after the project team leaves.
From the Delivery Floor
An interface successfully transmitted customer updates, but failures accumulated silently in a retry queue. Users discovered stale customer data only after orders began failing.
The team introduced business-level monitoring, aging thresholds and clear recovery ownership. Integration health became an operational control rather than a hidden technical metric.
23.9 The Delivery Leader's View
Treat critical integrations as dependencies in the integrated plan and go-live readiness model. A system may be technically live while the business process remains unusable because one interface is not operationally ready.
Chapter 23 Implementation Checklist
- Is every integration catalogued?
- Are business and technical owners assigned?
- Is the integration pattern justified?
- Are volume and latency requirements known?
- Is failure behavior designed?
- Are retries and duplicate handling controlled?
- Is security reviewed?
- Has end-to-end testing been completed?
- Is monitoring actionable?
- Are support and change responsibilities documented?
Key Takeaways
Integrations are business-process dependencies.
Pattern selection should follow requirements, not fashion.
Design failure handling explicitly.
End-to-end testing includes recovery and reconciliation.
Operational monitoring and ownership determine post-go-live reliability.
Closing Thought
A reliable integration is not one that never fails. It is one whose failures are visible, controlled and recoverable before they become business surprises.