Ask a chief information officer what happens if the company replaces its customer relationship system, and watch how long the answer takes. In estates built one purchase at a time, nobody can say within a week which interfaces break, who owns them, or whether anything downstream silently depends on a nightly file that a contractor wrote four years ago. That uncertainty is the actual cost of point-to-point integration, and it is almost never on the invoice that created it.
Point-to-point integration is not an architecture. It is a record of the order in which you bought things
Every direct connection made sense on the day it was built. The finance system needed payroll figures, so somebody wrote a job. The warehouse needed orders, so the vendor supplied a connector. The bank needed a payment file, so a script was scheduled. None of those decisions was wrong in isolation, and collectively they produce an estate whose shape reflects procurement history rather than any deliberate design. The arithmetic is unforgiving. Connecting five systems directly can require up to ten interfaces; ten systems can require forty-five. Nobody builds every possible pair, but the growth is quadratic and the maintenance burden grows with it. More importantly, the cost of change is proportional to the number of connections touching the system being changed — which is why estates like this become progressively harder to modernise, and why the ERP replacement everyone agreed to in principle keeps slipping.
What an integration layer actually buys
Not fewer interfaces. The same information still has to move. What changes is where the logic lives and what happens when something fails. Change tolerance. Endpoints connect to the layer rather than to each other, so replacing a system means re-pointing its connections rather than renegotiating every counterpart. One place for failure handling. Retries, dead-letter queues, alerting and replay, built once and applied everywhere, instead of thirty scripts each with its own idea of what to do at three in the morning. Observability. A single answer to the question of whether yesterday's data actually moved, which most organisations currently answer by waiting for someone to complain. An audit trail. What moved, when, in what state, and who changed the mapping — increasingly a compliance requirement rather than an operational nicety. Reuse. The customer record transformation written once rather than re-implemented per connection, with the inevitable divergence between versions.
What it does not buy
It does not fix master data, and a platform mapping between two systems with inconsistent supplier records will move the inconsistency faster. It does not remove the need to understand the business process. It adds a licence, an operating responsibility and a skill you must either hire or rent. And it introduces a component whose failure affects everything, which is manageable with competent operations and genuinely worse than point-to-point without them. Anyone selling this as a way to avoid thinking about your data model is selling you a faster route to the same place.
| Approach | Question for the owner |
|---|---|
| Direct connection | Can a small, stable interface be supported and tested without shared orchestration? |
| Integration platform | Who owns failure visibility, mapping changes and safe replay across jobs? |
| Reporting feed | Is the requirement read-only reporting rather than operational transactions? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
When each approach is right
Direct connections remain the correct answer for a small, stable estate: fewer than about five systems, low volume, interfaces that have not changed in two years, and no replacement on the horizon. Adding a platform to that is overhead in search of a problem. A platform starts paying when any of the following is true: you have more than roughly ten interfaces; a major system replacement is planned within three years; you operate multiple entities with differing systems; interfaces carry statutory obligations with deadlines; or — the most common trigger in practice — you cannot currently produce a list of your interfaces.
The interfaces nobody counts
Before evaluating platforms, count the human integration layer. Spreadsheets emailed monthly between departments. Reports exported from one system and imported into another. Staff re-keying figures because two systems never spoke. Files dropped on a shared folder that somebody picks up. In most mid-sized organisations this hidden layer moves more information than the automated one, costs more in salary than any platform licence, and is invisible in every architecture diagram. It is also where errors originate, because nothing validates a paste. Counting it usually changes the business case more than any vendor comparison.
Practical Guidance for Integration Architecture Review
- Inventory every interface, including scheduled scripts, file drops and manual re-keying.
- Name an owner for each one, and find the ones whose owner has left.
- Separate statutory interfaces into their own monitored tier.
- Evaluate error handling and replay before evaluating connector catalogues.
- Test the change scenario: what breaks if you replace your largest system.
- Keep transformation logic in the layer, not inside endpoint customisations.
- Check exportability of flows and mappings before signing.
- Cost the human layer and put it in the business case.
The Regional Angle
Three factors make this more urgent for groups operating in this region than the general argument suggests. The first is that a new category of interface has appeared and it does not tolerate the old operating model. Electronic invoicing clearance, wage protection files, customs and port systems, bank host-to-host connections and, increasingly, tax authority reporting are interfaces with statutory clocks, government endpoints and validation rules that change when a circular is published. A failed nightly job to a reporting database is an inconvenience; a failed clearance submission is a compliance event with a penalty attached and, in some regimes, an invoice that is not legally valid. These belong in a separate tier with active monitoring, named owners, tested fallbacks and a documented response when the government endpoint changes without notice. What actually exists in most regional estates is a scheduled task on a server, written by whoever was available, alerting to a mailbox nobody reads. The second is that integration is quietly being sold here as an alternative to fixing a fragmented application estate. Regional groups that grew by acquisition run several ERPs, several payroll systems and several chart-of-account structures, and a platform can absolutely stitch them into a consolidated view. Sometimes that is the right decision — buying five years of coherence while deferring a rationalisation the group cannot yet afford. But it should be a stated, time-bounded choice with a review date, not an accident. The failure mode is specific and common: the integration layer makes the fragmentation tolerable, the rationalisation never gets funded, and in five years the group has both a fragmented estate and a platform dependency, with the integration layer now encoding business rules that exist nowhere else. The third is a personnel risk peculiar to how technical work is staffed here. A large proportion of regional interfaces were built by contractors or by employees on project-linked visas who have since left the country, with credentials embedded in scripts, no documentation, and no handover. The useful diagnostic is not an architecture review; it is a single question put to the team: can we re-run yesterday's failed interface, correctly, without the person who built it? Where the answer is no, that interface is an outage waiting for a trigger. Inventory scheduled jobs and service accounts first, before choosing any platform, because that inventory is both the migration scope and, usually, the business case.
The objection worth taking seriously
The strongest objection is that integration platforms are a tax on estates that no longer need one. Modern applications ship with native connectors to the systems you actually use; webhooks and well-documented interfaces have made direct connections far less painful than the enterprise service bus era that gave middleware its bad name; and a platform is a licence, a specialist skill and a new single point of failure. Small teams move faster connecting two products directly than routing through a layer that someone has to operate and pay for. For a genuinely small and stable estate, that is correct, and the vendor pitch consistently overstates the value of connector catalogues, which are the cheapest part of the problem. The argument weakens on two specific points. Native connectors are built to move data on the happy path; they rarely give you replay, reconciliation, or an answer to what happened to the ninety-seven records that failed validation on Tuesday. And the case is not really about today's cost of moving data — it is about the cost of the next change. Organisations discover this at replacement time, when a twelve-month programme becomes eighteen because nobody could establish what depended on the system being retired. If your estate is stable and will remain so, do nothing. If you know a major replacement is coming, the cheapest time to build the layer is before you need it, not during.
Common Questions
Do we need a platform to consolidate reporting?
Often not. A data warehouse or reporting layer solves read-only consolidation. Integration platforms earn their place when data must move both ways and processes depend on it.
Can we build our own?
You can, and many competent teams do. The part that is consistently underestimated is not the moving of data but the operational apparatus around it — monitoring, retries, replay, versioning and the runbook for three in the morning.
How do we avoid replacing lock-in with different lock-in?
Insist on exportable flow definitions, keep transformation logic documented outside the tool, and avoid encoding business rules in the layer that belong in an application.
What should we expect over the next twelve months?
Expect every integration vendor to add AI-assisted mapping this year; the first drafts will be genuinely useful and the error-handling design will still be yours to do. Expect more government endpoints as electronic invoicing and tax reporting mandates spread across this region and Europe, which will push statutory interfaces further up the priority list. Expect pricing to keep shifting towards consumption-based models, which makes early volume estimates matter commercially. And expect at least one major system replacement in your peer group to slip by two quarters, with integration debt named as the cause — which is the argument for doing this inventory now, while it is cheap.
Integration Architecture Review — we map every interface including the human ones, find the jobs whose owner has left, and tell you whether a platform is worth buying or just worth planning for.