Integration Landscapes
Overview
The integration landscape is the map of how systems connect: who calls whom, by what means, with what coupling.
It is where the hidden cost of enterprise architecture lives. An individually simple system may have forty integrations — and the cost of maintaining those connections exceeds the cost of maintaining the system.
And it is the part of the current state that diverges most from what people believe.
Problem
Integrations grow by accumulation. Each new need produces a new connection, built the fastest way available at the time.
The aggregate, after a few years:
quadratic growth N systems can have up to N² connections
divergent forms API, file, shared database, queue, all at once
invisible coupling no one knows who depends on whom
expensive change altering one system requires coordinating with ten
And the cost is not attributed: it shows up as "changes take forever", "everything is coupled", "we can't touch that" — without anyone pointing at the landscape as the cause.
Core Concepts
The growth is quadratic
10 systems, all connected up to 45 connections
20 systems up to 190
40 systems up to 780
In practice no organization connects everything to everything, and the trend is clear: the number of integrations grows faster than the number of systems.
This means the decision to add a system carries a cost that is not the cost of the system — it is the cost of the connections it will need.
And it is why integration patterns matter: forty connections built in thirty different ways are far more expensive than forty built in three.
The types of coupling, in order of cost
shared database the worst — one system's schema becomes the other's contract
direct access to another's DB almost as bad
synchronous API couples availability
event couples format, not availability
file minimal coupling, high latency
The first two are the ones that show up most in old landscapes and the ones that block the most: they turn a system's internal model into a public contract, preventing any refactoring.
See data ownership.
The real landscape differs from the declared one
The map drawn in a meeting shows the official integrations. Reality includes:
direct queries against another system's database
processes that read files generated by another
tables replicated by forgotten jobs
integrations built by someone who has since left
API consumers no one knows exist
The way to find them is to observe: database access logs, network traffic, distributed tracing. See distributed tracing.
The typical finding: between 30% and 50% more integrations than documented.
The patterns that produce disproportionate cost
Looking at the landscape, a few patterns jump out:
A system with many connections. A system with thirty integrations is a coupling point — any change to it is expensive.
Cycles. A calls B, which calls C, which calls A. Hard to reason about, hard to deploy independently.
Long chains. A request that crosses six systems has poor composed availability. See availability.
Duplicated paths. Four integrations carrying the same data between the same systems, built at different times.
An unrecognized single point. A system many depend on, with no redundancy and no plan.
The last one is the highest-value finding: it is operational risk that the landscape reveals and that no per-system analysis finds.
Coupling is organizational, not just technical
An integration connects two systems and two teams.
changing the contract requires negotiating with the other team
deploying requires coordination
investigating a problem requires involving both
A system with thirty integrations is a system whose team negotiates with many others. See integration contracts.
This explains why teams with many dependencies deliver slowly — and why reducing integrations is a speed intervention, not just an architectural one.
Reducing is more valuable than organizing
The temptation, faced with a complex landscape, is to introduce a central intermediary — a bus everything passes through.
That reorganizes the diagram and keeps the coupling: the systems still depend on each other, now with one additional central point.
What actually reduces:
eliminate duplication four paths for the same data become one
clear ownership one owner, the rest consume
events instead of queries consumers stop asking
retire systems each one removed takes its connections with it
better boundaries less need to talk
The last is the deepest: a complex landscape frequently reflects poorly drawn system boundaries. See bounded context.
Mental Model
The landscape is where the aggregate cost shows up. Reducing connections is worth more than organizing them.
When to Use
- Before modernization programs.
- To assess the impact of changes or of retirement.
- When investigating why the organization delivers slowly.
- After acquisitions.
- To identify single-point risk.
When Not to Use
Mapped by interview alone.
Introducing a central intermediary without reducing coupling.
As a static diagram that is out of date.
Without including informal integrations.
Documenting without deciding what to do with what you find.
Alternatives
- Derived dependency map — automatic, real, always current.
- Per-system analysis — what each one consumes and exposes, without the global map.
- Contract catalog — what is published, who consumes it. See integration contracts.
Trade-offs
| Complete map | Focused analysis |
|---|---|
| Reveals global patterns | Local depth |
| Expensive to maintain | On demand |
| Finds the unexpected | Only what you look for |
| Derived | Documented |
|---|---|
| Real and current | Includes the uninstrumented |
| Limited to the observable | Captures intent |
Failure Modes
Invisible informal integration. Breaks when something changes.
A bus without reduction. Reorganizes without decoupling.
An unrecognized single point.
A cycle between systems. Independent deployment impossible.
A long chain. Poor composed availability.
Duplicated paths. Four integrations, one purpose.
Common Mistakes
Mapping by interview. People remember the integrations they use and forget the old ones — which are precisely the ones that break when someone turns a system off.
Not including direct access to another system's database. It is the most coupled integration there is and the one that appears least in maps, because it goes through no API.
Introducing an intermediary as the solution. A bus in the middle of poorly designed integrations merely centralizes the problem and creates an organizational bottleneck — the coupling remains, now with one more system to operate.
Not measuring the maintenance cost of integrations. It is where a good share of engineering capacity is consumed, and it appears on no budget line.
Not using the landscape to decide — only documenting it. The map exists to choose what to consolidate and what to shut down. Without that link, it is a poster.
Real-World Example
A logistics company was investigating why software delivery was slow despite competent teams and good automation.
The integration landscape, derived from access logs and tracing, revealed:
systems 68
documented integrations 190
real integrations 312
One hundred and twenty-two undocumented integrations — 39% of the total.
The patterns found:
One system with 47 integrations. The customer record, accessed directly in the database by 19 systems. Any schema change required coordinating with 19 teams, and for that reason the schema had not changed in four years.
Seven cycles. Sets of systems calling each other, making independent deployment impossible.
Duplication. Route data was carried by six different paths between the same systems — API, file, database replication, queue, and two scheduled jobs.
A single point. A geocoding service, maintained by one person, on which 22 systems depended synchronously.
The intervention prioritized reduction, not reorganization:
Customer record with declared ownership. The 19 direct database accesses were replaced by an API and by events, over eighteen months. The schema could change again.
Cycles broken by dependency inversion — the system that was being called started publishing events.
Duplication eliminated. The six route-data paths became one.
Single point addressed. Cache at the consumer, an alternative provider, and knowledge transfer.
Result in two years: 312 integrations down to 180, and the average delivery time for a feature crossing systems dropped from 11 weeks to 4.
And one deliberate decision: the proposal to introduce a central bus was refused. The analysis showed it would reorganize the diagram without reducing the number of dependencies between teams — which was the cause of the slowness.
The slowness had been attributed to process and tooling. The cause was structural, and it became visible only when someone drew the map from what actually happens, rather than from what is documented.
Related Concepts
Practical Exercise
Derive the dependency map of your most central system from access logs and tracing, and compare it with what is documented.
The difference is the landscape you didn't know you had.
Interview Questions
- Why does the number of integrations grow faster than the number of systems?
- Why does a central bus not reduce coupling?
- Why is integration coupling also organizational?
Further Reading
- Hohpe, Gregor; Woolf, Bobby. Enterprise Integration Patterns. Addison-Wesley, 2003.
- Newman, Sam. Building Microservices. 2nd ed. O'Reilly, 2021.
- Skelton, Matthew; Pais, Manuel. Team Topologies. IT Revolution, 2019.