A service team can introduce a modest change and discover that the real engineering programme sits outside its own repository. The added field is optional. The producer's tests pass. The application still returns a valid response. Yet an older consumer fails because its interpretation depended on a shape the producing team did not consider part of the contract. The disagreement is not resolved by repeating that the new field should be ignored. The existing consumer does not behave that way, and the bank still has to operate it.
I think of a banking interface transition as a temporary relationship between generations of software. Each generation has users, operating assumptions and a maintenance cost. A responsible release plan must explain that relationship while it exists. It cannot begin with the desired final architecture and treat everything outside it as an administrative obstacle to the launch date. The older behaviour may be inconvenient, but inconvenience does not remove a banking dependency.
The receiving application defines part of the change
At Talverin, a rehearsal across seventy-two consumers found sixty tolerant of an added optional response field and twelve dependent on a rigid shape. The producer had described a compatible addition. The rehearsal showed where that description held and where it did not. I found the consumer count useful because it turned an architectural assertion into a population we could examine. It also gave receiving owners a concrete place in the decision instead of asking them to endorse a general statement about compatibility.
An interface specification is essential, but it is not the whole account of installed behaviour. A consumer may have made assumptions that were never intended. That may require correction in the consumer rather than a permanent restriction on the producer. Even so, the repair has to be owned and sequenced. Discovering that another team should have written different code does not make the current dependency disappear. The bank needs an answer about how the affected service will function during the transition.
I ask for examples that cross the boundary in both directions. What does the producer promise to return, and what does each relevant consumer actually require? Which checks establish that an existing workflow can continue? Which conditions remain outside the rehearsal? These questions are more useful than debating whether the change deserves a particular compatibility label. A label should summarise evidence already examined; it should not become the reason to stop examining a receiving application that behaves differently.
The population also needs an owner. A list of known consumers is not automatically complete forever. New connections can appear, older ones can be overlooked and a nominally retired interface can retain a small but important use. I want the release account to explain how the list was assembled and who maintains it. That gives the next reviewer a basis for challenge without pretending the engineering team can prove the absence of every unknown dependency.
Coexistence has a bill and an owner
We adapted ten of the twelve rigid consumers during seven weeks of work costing USD1.4 million. Seventy of the original seventy-two then supported the new response, while two retained the older contract. This was progress with a remaining operating obligation. A second contract meant more testing, support and explanation. I accepted that cost because a single transition date would have transferred uncertainty to the receiving teams rather than demonstrated that their services were ready.
Coexistence becomes weak management when nobody can describe its purpose or ending. It becomes sound engineering when the retained version supports a named need, has an accountable owner and carries a reviewable path forward. I want those details in the same paper as the new release. Otherwise the organisation celebrates an apparent completion while the maintenance team quietly inherits an additional service whose cost was absent from the investment decision.
The arrangement also needs a coherent support model. When a problem arrives, colleagues should know which contract the consumer is using and which team can investigate the behaviour. It should be possible to reproduce an issue without first reconstructing the migration history through several conversations. The aim is not elaborate documentation for its own sake. It is a usable account of what the bank is operating while its systems are at different stages of change.
This is where a CTO's allocation choices matter. The new capability often has a visible sponsor, while maintenance of the older route can appear to be a distraction from the future. I treat both as part of the transition economics. Funding only the new component does not eliminate the older obligation; it moves the cost into unplanned support, delayed work or an assumption that somebody will cover it. A credible decision should make that trade-off visible before delivery begins.
Retirement is a separate decision
I distinguish releasing the new contract from retiring the old one. The first establishes that a capability is available under stated conditions. The second removes an arrangement on which somebody may still depend. Evidence sufficient for one is not necessarily sufficient for the other. A high migration percentage can support a useful progress report while leaving the final two consumers as the most important question in a retirement decision.
For each remaining consumer, I want a specific explanation of the constraint. Is the adaptation unbuilt, untested, commercially deferred or dependent on another change? Those are different conditions with different owners. Treating all of them as a generic backlog item conceals what management must decide. It also makes it too easy for the older contract to persist without a conscious choice, because no single review can tell whether the obstacle has changed.
The end of coexistence should therefore be an affirmative decision supported by the receiving owners and the relevant operating evidence. It should not arrive merely because a date appears in the original slide deck. Dates matter: they focus effort and reveal the cost of delay. But a missed date requires a revised decision, not a retrospective claim that the dependency was immaterial. The remaining obligation still belongs in the enterprise account.
I would improve our next transition by examining actual consumer behaviour when the response change is first proposed. That would not remove every unexpected dependency. It would give the initial estimate a better foundation and prevent the word optional from doing work that only evidence can perform. The new release earns credibility when its plan includes the old contract, the people still relying on it and the conditions under which the bank can responsibly let it go.