Boundary-Crossing Count

Most architecture metrics measure the function's activity: standards compliance, documentation coverage, review throughput. A system can score perfectly on all of them and be slow, expensive and fragile.

The number of teams that must change for a median feature measures something a system cannot fake: whether the boundaries match how work actually arrives.

Why it matters

A number above two indicates a structural coordination cost paid on every feature, and no amount of process improvement removes it — process is what organisations add when the structure is wrong. It is also predictive: it explains delivery slowness that velocity metrics report without diagnosing.

It is directly actionable in a way most architecture metrics are not. The remedy is either to change the organisation to match the architecture or the architecture to match the organisation, and both are decisions an architecture function can advocate.

Implementation patterns

• Measure from delivered work, not from estimates: for the last thirty features, how many teams had a change merged.
• Distinguish the median from the tail. A few genuinely cross-cutting features are expected; a median above two is the finding.
• Segment by feature type, since a pattern in which one category always crosses the same boundaries identifies exactly which boundary is wrong.
• Pair it with deployment ordering. If releases have a required sequence, the services are not independently deployable whatever the diagram claims — and independent deployability is the entire point of a service boundary.
• Track it over time, since the value is in the trend and in whether a structural change moved it.

Industry example

Logistics and B2B platforms such as Delhivery and Moglix commonly split services by function — onboarding, catalogue, pricing, fulfilment — while work arrives by journey, such as bringing a supplier live with their catalogue and negotiated pricing. Every meaningful feature then crosses all four, and the observable symptom is that delivery slows as the platform matures rather than speeding up.

The metric names the cause, which is what allows the conversation about restructuring to be evidence-based rather than a matter of opinion.

Failure scenarios

• Not measured, so a structural problem is attributed to team performance.
• Measured and responded to with coordination — a programme manager, a release train — which institutionalises the cost.
• Responded to by splitting further, which multiplies the coordination surface.
• Measured on estimates, which reflect intention rather than what happened.
• Interpreted as a target rather than a diagnostic, which produces gaming by defining features narrowly.

Trade-offs

Reducing the count usually means either reorganising teams — slow, political, often outside an architect's authority — or consolidating services, which reduces coordination and increases blast radius and gives up any genuinely independent scaling.

That trade is favourable when the services shared a release cadence anyway, which, if every feature needs all of them, they did. Consolidating services is a legitimate architectural improvement when the split produced coordination instead of independence.

Interview question

"For your last twenty features, how many teams had to change? If the answer is four, tell me what you would do about it — and give me the argument against doing that."