Every financial services organization I've worked with has an integration problem. Not a small one. A structural one that accumulates over years, becomes progressively more expensive to maintain, and progressively harder to change.
The problem is predictable: systems acquired, built, or inherited over decades, each with its own data model, each interfacing with others through a collection of point-to-point connections, scheduled batch jobs, file transfers, and manual reconciliations. The sum of these connections is not an architecture. It's a topology that emerged without design.
Why Integration Gets Deferred
The reason integration debt accumulates is structural: fixing it is expensive, invisible, and doesn't deliver visible business value.
When an organization builds a new customer-facing feature, the value is visible immediately. When it fixes the underlying integration between the policy administration system and the actuarial data warehouse, the value is defensive — it reduces reconciliation overhead, improves data quality, makes future changes cheaper. None of these appear on any dashboard.
The pattern I've watched unfold repeatedly: a new regulatory requirement arrives. The quickest path to compliance is a point-to-point connection from the source system to the reporting pipeline. The connection is built. The deadline is met. The integration debt increases. When the next regulatory requirement arrives, the same path is taken. Over time, the reporting infrastructure has direct dependencies on fifteen different source systems, each of which must be accommodated when it changes.
This is the technical equivalent of compound interest on unpaid debt.
What Good Integration Infrastructure Looks Like
I'll be specific, because this is a domain where abstract principles don't help much.
A canonical integration layer. Rather than point-to-point connections between systems, a central integration layer that translates between the internal representations of different systems. When a source system changes, the integration layer is updated once. The downstream consumers don't need to know. This is what I built at Anadolu Hayat Emeklilik using BizTalk Server — a centralized payment integration that replaced a collection of direct system connections with a single managed layer. The operational benefit was immediate: changes to one system no longer required changes across all systems that connected to it.
Event-driven where it matters, batch where it doesn't. Not everything needs to be real-time. Regulatory reporting in Turkey operates on defined submission cycles. The data doesn't need to flow in real-time to be accurate. But the assumption that batch is always acceptable leads to architectures where data is stale in ways that matter — a customer's recent transaction doesn't appear in the risk model, a payment is processed against yesterday's policy data. The integration architecture should reflect the actual latency requirements of each data flow, not a default assumption about how systems communicate.
Explicit contracts between systems. When System A sends data to System B, the schema, the semantics, and the validation rules should be documented and enforced. When System A changes, the contract is updated, both parties review it, and the change is managed deliberately. In most legacy integration environments, the contracts are implicit — encoded in both systems without documentation. When one changes, the other breaks in ways that aren't immediately obvious.
The Talent Dimension
Integration work requires a specific skill set that's increasingly rare: deep understanding of the data models of legacy enterprise systems, the ability to translate between them, and the operational instinct to build integration that is observable, debuggable, and maintainable.
The engineers who are drawn to greenfield development find integration unglamorous. It's working with somebody else's data model, inside somebody else's constraints, producing no visible user-facing output. But in financial services organizations with complex legacy environments, it's some of the highest-leverage work available — because the quality of every downstream data product depends on the quality of the integration that feeds it.
When I'm hiring for data roles in regulated environments, I specifically look for people who've done this work and don't apologize for it. They understand the problem domain in a way that engineers who've only built new systems don't.
The Investment Case
Making the integration investment case internally is hard for the reasons already described: the value is defensive and invisible. The approach that works is to make the current cost visible.
How many hours per week does the team spend reconciling data between systems that should agree but don't? How many production incidents trace back to an integration failure? How many times has a regulatory change required updates to multiple systems because the integration wasn't centralized?
When those costs are quantified — even roughly — the investment in integration infrastructure looks different. The architecture that reduces reconciliation overhead, centralizes change management, and makes the system observable is an investment in operational capacity, not just technical tidiness.
Integration is the part of the data architecture that nobody wants to own and everybody depends on. The organizations that invest in it deliberately, rather than letting it accumulate through expedience, spend less time on firefighting and more time on work that matters.