Transitional Architecture

Transitional architecture is software introduced to support a replacement whose role is intended to end as the transition completes. Cartwright, Horn, and Lewis describe temporary integrations that make intermediate configurations workable even though they are absent from the target design. Like scaffolding, such work can enable earlier delivery or safer steps. It is an option whose benefit must justify construction, operation, and eventual removal costs, not an unavoidable ingredient of every change.

What qualifies, and what does not

A temporary seam or legacy mimic can connect new capabilities to existing flows. A service-providing mimic exposes a new implementation through a legacy interface; a service-consuming mimic interacts with legacy through its existing contract. In the authors’ example, these mimics disappear while an external-partner anti-corruption layer remains. The distinction is its intended role in the target, not simply whether the other system will survive. The partner might adopt a new interface and make the translation unnecessary. Microsoft likewise asks whether a migration’s anti-corruption layer is permanent or temporary. A component can contain both enduring functions and temporary routing or translation rules; track the exit conditions of those responsibilities separately.

Temporary software can bring a useful capability forward and allow smaller exposures during migration. Its value depends on the alternatives, the length of coexistence, and the controls it provides. Interception can simplify changing a route, but safe recovery also depends on accepted data changes and side effects. Keep necessary transition costs distinct from additional burden caused by unjustified delay. Give each temporary responsibility an owner, removal conditions, and a target or review date. Remove it only after consumer, support, data, and recovery obligations have been resolved, and verify that its code, configuration, and resources are no longer required. In a fictional retailer’s strangler fig replacement, twenty-three adapters supplied legacy reporting; four also had other consumers. Moving reporting opened a path to retire nineteen, not all twenty-three. The register and decisions are developed in Twenty-Three Adapters and No Retirement Dates.

References:

• Ian Cartwright, Rob Horn, and James Lewis, Transitional Architecture (2022).
• Ian Cartwright, Rob Horn, and James Lewis, Legacy Mimic (2022).
• Microsoft Azure Architecture Center, Anti-Corruption Layer pattern.