Agility Is a Coordination Problem: Architect for Blast Radius, Not for Speed Lanes

Ask a CIO why a pricing change takes eleven weeks and you will rarely hear "our developers are slow." You will hear about the order management team, the integration middleware freeze window, the finance reconciliation job, and the two vendors who own the interfaces. The delay isn't coding time. It's consent time — the calendar cost of getting a dozen owners to agree, test together, and release together. Enterprise architecture's real contribution to business agility is shrinking that number, and most as-is/to-be roadmaps never measure it.

The metric that actually predicts agility

Delivery organisations have adopted DORA's four keys, and the 2025 State of DevOps research continues to show that throughput improves only when the surrounding system does — AI-assisted coding amplifies friction in weakly structured environments rather than removing it. That is the giveaway. Lead time is largely an architectural property. If shipping a change to one business capability requires coordinated releases across four others, no amount of pipeline tooling will fix it.

So add one blunt measure to your architecture practice: the consent count — how many distinct owning teams must approve, change code, or align a release window for a representative business change. Track it per capability, per quarter. It is cheap to gather, impossible to fake, and it correlates far better with perceived business agility than any maturity score.

Your as-is model is a diagram; it should be a dependency ledger

Most as-is architectures are drawn to be presented, not used. They show boxes and arrows at a level of abstraction where everything looks reasonable. What a roadmap needs instead is a ledger of coupling: which systems share a database, which integrations are point-to-point, which processes cannot run without a nightly batch, and which vendor contracts make a change commercially expensive regardless of technical effort.

• Data coupling: two systems writing the same entity with no owner. This is the most expensive form and the least visible on a landscape diagram.
• Release coupling: components that cannot be deployed independently, usually discovered during the first attempt at a hotfix.
• Semantic coupling: the same term meaning different things across ERP, CRM and the analytics layer — the tax you pay on every cross-domain initiative.
• Commercial coupling: licensing, support boundaries, and SI scope that turn a two-day change into a change request cycle.

Model those four and your as-is becomes a diagnostic instrument rather than wall art. Our architecture advisory work almost always starts here, because the coupling ledger determines what the to-be roadmap is even allowed to sequence.

Sequence the roadmap by decoupling value, not by system age

Roadmaps typically order work by risk, cost, or vendor end-of-life dates. A better ordering principle is how much future optionality each move creates. Extracting a shared customer master may deliver no visible feature, but it may reduce the consent count on six downstream initiatives. Gartner has noted that only a small minority of leaders believe their organisations respond effectively to technology disruption; that gap is mostly about optionality, not foresight.

The economics reinforce this. McKinsey's analysis of technology budgets shows that new platforms stacked on top of unretired legacy compound operating burden rather than relieve it. Every to-be increment should therefore specify what it removes, not only what it adds.

Pace layering is fine — unshared contracts are not

Running a stable core at one cadence and customer-facing capabilities at another is legitimate; ERP and a promotions engine genuinely have different change rates. The failure mode is when the two speeds are separated organisationally but joined technically — a fast team shipping weekly against an interface the slow team can change without notice. Pace layering only works when the boundary is an explicit, versioned contract with a stated compatibility policy and a named owner. Without that, you have not created two speeds; you have created a queue. We see this constantly in SAP-centred landscapes, where the core is governed carefully and the edge is governed by whoever built it last.

What to do in the next quarter

Pick three business changes the organisation is likely to want within eighteen months. Walk each one through the current landscape and count the owners. Publish the numbers. Then make the to-be roadmap a plan to reduce those counts, with a retirement date attached to at least one dependency per increment. Architecture earns its budget when the second change is visibly cheaper than the first — and that is a claim you can evidence rather than assert.