The anti-corruption adapter: connecting to a legacy core without inheriting its model.

The first time you connect a platform to an insurer's core system, you can let that insurer's concepts through into your own model, and everything works.

I want to be fair to that choice, because I have made it. An insurer's core was built for the job that insurer does, shaped by decades of decisions that made sense where they were made. It was never meant to be one node in somebody else's network, and there is no reason it should have been. When there is one of them and one of you, translating between two vocabularies looks like paperwork for its own sake.

The pattern is worth the early cost, and it has a name in software design: the anti-corruption layer. The corruption has nothing to do with fraud. It means one system's concepts leaking in and reshaping another's.

Where the cost actually arrives

With one partner connected, your shared vocabulary and that partner's are indistinguishable, so nothing looks wrong. With two, the differences are small and get absorbed. By the fourth, the vocabulary you build everything on is a pile of four partners' concepts stacked together and belongs to none of them.

What degrades is not correctness. Every integration still works. What degrades is the cost of adding the next one, which was the whole reason to have a platform. A new partner now has to be reconciled against four accumulated histories rather than against one definition.

I should be honest that I cannot give you a threshold with evidence behind it. The reason is built into the problem: nothing fails while this happens, and there is no test that goes red when a shared vocabulary drifts. If you want a measurable version, watch two things. How many concepts in your model carry more than one partner's fingerprints, and whether time-to-integrate partner N is falling or rising.

What sits at the boundary instead

Each partner gets an adapter, and that adapter is the only component in the system that knows the partner's interface exists.

It translates in both directions between the partner's shapes and your shared vocabulary, and it absorbs everything that partner requires: its identifiers, its fixed lists of permitted values, the order it expects things in, its idea of what a complete record is. Inside the boundary, everything speaks the standard. A service handling a claim does not know which partner it came from.

In our motor claims deployment this is two adapters doing quite different jobs. One absorbs a broker's claim-request protocol. The other absorbs a dealer management system's work-estimate protocol. Each runs under its own machine identity, permitted to do only what its own job needs.

The response path is where the pattern shows what it is for. Our core reports failures in a standard format, RFC 7807, a published convention for machine-readable errors. Each adapter translates those back into the partner's own legacy codes before they leave, and preserves the partner's response shapes. Where their interface expects a per-record result across a batch, it gets one. Where a field carries either a matched claim number or an empty value, it gets exactly that.

The counterparty sees no behavioural change at all. That is what lets us modernise the inside of the platform without asking anyone's permission. In this market a change request against an insurer's core can be measured in quarters, so not needing permission is most of the value.

What it buys, and what it costs

Three things, and they compound. Adding a partner becomes writing one adapter against a vocabulary that already exists. When a partner changes its interface, one component changes and nothing else knows. And the shared vocabulary stays a description of insurance rather than a history of who integrated first.

The cost side deserves more than I usually see it given. Adapters do not remove complexity, they relocate it, from one messy model that everyone can see into N components with N owners. Every change to the shared vocabulary is an N-way migration. Each adapter carries its own deployable, its own tests, its own mapping table, and its own opportunity to drift from its siblings. That bill arrives monthly and forever, and any honest account of the pattern has to put it on the ledger next to the savings.

So the trade is not complexity against simplicity. It is diffuse, invisible, unfixable complexity against concentrated, visible, maintainable complexity. I think the second is worth paying for. An operation that will only ever connect one partner should not pay it at all.

The question I would ask a platform

Ask what happens when a partner sends a field your model has no concept of.

If the field is rejected, the platform cannot represent something a partner considers real. If it is mapped onto a near neighbour, a small untruth has been recorded as fact. If it is added to the model, the boundary is not holding.