An architect proposes a design requiring three teams to coordinate on every release. The organisation will not restructure. What are the options?

Recognising the situation

A design requiring continuous coordination between teams that ship independently will erode. Coordination is expensive, so the teams will find shortcuts — a shared table, a direct call, a copied library — and the boundary will become porous. Not through negligence, but because the design is fighting the organisation.

The options, in order of preference

1. Change the design to match the organisation. Redraw boundaries so each team owns a complete capability, even if that produces a technically less elegant decomposition. A design that one team can change alone is usually better in practice than a purer one requiring three-way coordination — because the second will decay into the first, badly.

2. Change the coordination cost rather than the structure. If the boundary is right and the coordination is the problem, attack the coordination: contract tests so a change fails the provider's build before merge, expand-and-contract migrations so schema changes never require sequenced releases, and versioned interfaces so teams deploy independently. This converts coordination into a protocol, which is frequently the highest- value intervention available and is entirely within an architect's gift.

3. Own the seam explicitly. Keep the boundary and give one team the mandate to define and enforce the contract across it. Less good than restructuring and usually what is politically achievable.

4. Consolidate the deployable unit. Three teams working in one well-modularised codebase with enforced internal boundaries, deployed together, is often better than three services requiring coordinated releases. It keeps the module boundaries and removes the distributed-systems cost.

5. Make the case for restructuring anyway, with evidence — coordination cost measured in lead time and incidents rather than asserted. Organisations do restructure, and a measured argument is what makes it possible.

What not to do

Proceed with the design and rely on discipline. It will work while the architect is watching and erode afterwards, and the erosion will be blamed on the teams rather than on the design.

The general principle

Architecture that fights the organisation loses. Either change the organisation, change the design, or change the cost of coordination — and the third is usually the fastest and most durable option available to an architect who cannot do the first.