Integration architecture guide
How do you design a business system integration layer?
Give applications stable business contracts across APIs, events, queues and batch exchange. Keep source ownership explicit, contain vendor-specific translation, and design security, failure recovery and support as part of the integration.
The direct architecture
Start with a system and data ownership map. Define business-oriented contracts for the reads, commands and events consumers need. Put source-specific APIs, files, protocols and schemas behind adapters. Use synchronous calls only for interactions that need an immediate response and asynchronous messaging where buffering, decoupling or durable processing creates value.
Add consistent authentication, authorisation, correlation, retries, reconciliation and operational ownership. The integration layer is a product that needs contracts and support, not a collection of invisible scripts.
01
Use an integration layer to create stable boundaries
| Problem | Integration-layer response |
|---|---|
| Every application calls vendor interfaces differently | Provide one governed business contract and adapter |
| System changes break several consumers | Contain source changes and version consumer contracts |
| Cross-system workflows fail silently | Correlate, monitor and reconcile business operations |
| Credentials spread across applications | Use constrained service identities and central secret management |
| Point-to-point scripts multiply | Reuse owned patterns without creating a central monolith |
A direct integration can remain appropriate when one stable consumer uses one well-owned source. Add a layer when translation, reuse, resilience or governance is a real requirement.
02
Map business ownership before technical connections
- which system creates and owns each entity;
- which system may change each important state;
- which identifiers link records across systems;
- which consumers need reads, commands or events;
- what freshness, response time and volume each interaction requires;
- which business rules must remain with the source domain; and
- who resolves failed, delayed or inconsistent transactions.
This prevents the integration layer from becoming an accidental source of truth or a hidden owner of business policy.
03
Use a layered reference architecture
Stable operations, schemas, versions and error meanings.
Routing, queues, scheduling and state where cross-system work requires it.
Protocols, vendor schemas, identifiers and source-specific errors.
Correlation, metrics, alerts, replay and reconciliation.
Microsoft's integration guidance notes that direct API calls, asynchronous messaging and events suit different communication requirements. The layer can use several patterns without exposing those choices to every consumer.
04
Design contracts around intent and failure
| Contract | Use for | Must define |
|---|---|---|
| Query API | Current data needed immediately | Scope, freshness, paging, limits and errors |
| Command API | Validated business action | Authorisation, idempotency and completion semantics |
| Event | Announcement that a fact occurred | Event identity, version, time and replay |
| Queued command | Durable asynchronous work | Retry, ordering, deduplication and dead-letter ownership |
| Batch exchange | Large or legacy data transfer | File schema, cut-off, totals, partial failure and retention |
Compare APIs, webhooks and queues for a deeper pattern decision.
05
Treat integration as a security boundary
- authenticate every machine and human caller appropriately;
- authorise business operations and records, not only endpoints;
- use separate least-privilege identities per environment and integration;
- validate input, constrain payloads and minimise returned fields;
- protect secrets, tokens, certificates and webhook signing keys;
- rate-limit and isolate consumers so one cannot exhaust shared capacity;
- audit privileged operations and configuration changes; and
- avoid logging credentials or unnecessary sensitive payloads.
06
Operate integrations by business outcome
Trace
One correlation path
Follow a request across application, message, adapter and source outcome.
Measure
Business reliability
Monitor latency, success, backlog age, duplicates and reconciliation gaps.
Recover
Owned exceptions
Give failed messages and mismatches a safe correction and replay procedure.
Change
Contract lifecycle
Version, test and deprecate contracts with known consumers and dates.
07
Deliver the layer through one valuable business flow
- Inventory systems, owners, consumers and current failures.
- Select one cross-system workflow with a measurable outcome.
- Define ownership, contract, timing and failure semantics.
- Prototype the least certain source interface and volume.
- Build contract tests, observability and recovery with the flow.
- Pilot with representative data and dependency outages.
- Reuse components only after the first boundary proves stable.
Sources
Primary references
Questions
Frequently asked questions
What is a business system integration layer?
It is a controlled set of APIs, adapters, messages, workflows and operational controls that lets applications exchange data and actions without every consumer depending directly on every source system.
Do you always need a separate integration platform?
No. A small application may use well-structured internal modules and background jobs. Introduce a shared service or platform when several systems, teams or workflows need reusable contracts, routing, security and operations.
What belongs in the integration layer?
Protocol and data translation, routing, validation at the boundary, delivery, retries, correlation and integration observability belong there. Core business decisions should remain with the domain or system that owns them.
Should systems share one database instead?
A shared database creates strong schema and release coupling and can bypass business rules. Prefer explicit service, event or data contracts unless the shared database is an intentional owned boundary with clear controls.
How do you prevent an integration layer becoming a bottleneck?
Keep contracts domain-focused, distribute ownership appropriately, avoid placing every business rule in a central service, design for independent scaling and monitor latency, backlog and failure by business operation.
Design the integration layer
Bring the systems, workflows, interfaces and recurring failures.
LCR can help define the smallest useful integration boundary and an incremental delivery plan around real business operations.