Translation Inversion

A 2011 mainframe policy system was decommissioned last quarter. The anti-corruption layer built to translate its model is still in the request path, and over 14 years its translated shape became the one every downstream service understands — including services written after the mainframe stopped being the source of truth.

The adapter has reversed direction. It was protecting the new model from a legacy one; it now converts the current model into a legacy shape that twenty consumers depend on. The thing being protected no longer exists, and the translation is the only place the old vocabulary survives.

Why it matters

It changes what the removal work is. Deleting an adapter is a day's work. Migrating twenty consumers at 5 to 15 days each is two to four quarters of calendar time, and the distinction decides whether the work is scheduled as a chore or funded as a project.

It also explains a confusing organisational signal: teams keep asking why fields are named the way they are, and nobody can answer. The adapter is the only surviving documentation of a model whose authors have left, which makes writing that documentation down the urgent task even if nothing is ever deleted.

The deeper point is about what an adapter accumulates. Fourteen years of "just put the special case here" means the layer contains genuine business rules that live nowhere else, mixed in with compensations for quirks of a system that no longer runs. Those two look identical in the code.

Implementation patterns

• Extract the mapping into a specification first — field by field, with defaults, sentinel codes, date conventions and special cases. This precedes any deletion and is where the surprises are.
• Classify every rule into three buckets: pure renames, genuine business rules, and compensations for quirks of the retired system. Only the third can be deleted outright; the second must be moved somewhere with an owner.
• Serve both shapes from the layer while consumers migrate, with the legacy shape computed as a pure projection of the modern one — never maintained in parallel.
• Instrument consumption per consumer and per field. You will find fields nobody reads and consumers nobody knew about, usually a monthly report or an external integration.
• Migrate newest consumers first. Services written after the legacy system died have the least coupling and validate the new contract cheaply.
• Freeze the legacy shape against new consumers, in the pipeline or in review, before shrinking it. That freeze is the practical point of no return.

Industry example

The dynamic is visible in long-lived financial messaging. Organisations that built adapters around fixed-format standards found the adapter's field conventions — truncated identifiers, date formats, code lists — reproduced throughout their internal systems, so that migrating to a richer standard such as ISO 20022 became a programme about internal consumers rather than about the external interface. The adapter did its job and the conventions escaped anyway.

The same is reported in mainframe offload programmes generally: the facade built to present the mainframe's model survives the mainframe, because every system built during the transition was written against the facade. Adapters outlive their reasons, and the longer they live the more canonical they become.

Failure scenarios

• Silent divergence between the two shapes while both are served: a rule changed in one and not the other yields different answers to the same question with no error, discovered weeks later in a reconciliation mismatch.
• Deleting a business rule believed to be a legacy compensation, which removes behaviour nobody knew was deliberate.
• New consumers joining the legacy shape during the migration, because nothing prevents it, so the population grows while you are trying to shrink it.
• A monthly or quarterly consumer missed entirely, discovered when it next runs.
• The specification never written, so the mapping's meaning is lost when the layer is finally deleted.

Trade-offs

Removing the inversion buys a single model, a shorter request path and a vocabulary new engineers can learn from the domain rather than from history. It costs coordination across every consuming team, a long window in which two shapes coexist, and a continuous comparison harness to detect divergence during that window.

The honest framing for funding: the first few weeks produce the map and are worth doing regardless, and the remaining quarters are opportunistic work attached to each consumer team's existing plans.

When not to use it

If the layer is stable, cheap and blocking nobody, leave it. A translation that works, costs a few milliseconds and changes twice a year is not worth two quarters of cross-team coordination. Removal needs a concrete trigger: the legacy shape blocks a feature, its identifier or date conventions are causing defects, or nobody left understands the mapping.

The last of those changes the priority rather than the decision. Write the specification even when you have decided not to delete anything, because the alternative is an undocumented contract with no owner.

Interview question

Q: You find an anti-corruption layer whose legacy counterpart was switched off a year ago, serving twenty internal consumers. Your manager asks for a two-week plan to delete it. What do you say, and what do you actually deliver in two weeks?

What a strong answer covers: correcting the framing — this is a consumer migration, not an adapter deletion, and twenty consumers is quarters not weeks · what two weeks can genuinely deliver: the field-by-field specification, the three-way classification of rules, and per-consumer per-field consumption data · the discovery risk, that some mapping rules are real business policy rather than legacy compensation · publishing the modern contract alongside the legacy one so consumers have a target, with the legacy shape computed as a projection to prevent divergence · freezing new consumers as the first irreversible step · and the explicit recommendation of whether to proceed at all, based on whether the legacy shape is blocking anything.

Quick check

Quiz: How do you tell an anti-corruption layer that is still working from one that has inverted? — Ask which direction it translates: towards your model from a live external one, or from your model into a shape that only your own consumers still speak.

Flashcard: Which of an inverted adapter's rules can be deleted outright? — Only the compensations for quirks of the retired system. Pure renames need consumer migration, and genuine business rules need a new owner.