You inherit an enterprise architecture function that delivery teams route around and executives consider overhead. What do you change?

Diagnose the two failures separately

Teams route around it because it is a queue that adds latency without adding value — decisions made by people distant from the work, at a checkpoint too late to change anything.

Executives consider it overhead because it reports outputs — models produced, reviews conducted, standards published — rather than anything that changed.

Both have the same root: the function is producing artefacts rather than decisions.

Stop modelling for completeness

The failure that makes EA unpopular is describing the estate rather than answering questions. A full fine-grained model takes years, is stale on delivery, and answers nothing anyone asked.

Apply one test to every artefact: which decision does this inform, and who is waiting for it? Stop producing anything that fails it.

Keep two things current because they earn their place: a capability map at two or three levels, and an application landscape with ownership, capabilities supported, integrations, lifecycle status and cost. The mapping between them is what produces findings nobody else can — duplication, gaps, concentration risk, and technical risk expressed in business terms.

Replace the gate with automation and advice

Automated policy for anything mechanically checkable: dependency direction, forbidden versions, API compatibility, security configuration, licence compliance. This replaces most of what the review board was doing, and does it on every commit rather than at a checkpoint — objectively, in minutes, to the person who caused the drift.

Published team decision rights. Telling teams what they may simply decide is, in most organisations, the single largest governance improvement available.

Advisory review for significant designs, at 20% completion rather than 90%, with reviewers who have read the material and criteria published in advance. Teams come because it improves their design.

Escalation reserved for the genuinely irreversible: data models, public contracts, vendor commitments, regional topology.

Build the thing teams actually want

The most durable influence is making the right thing easy. A paved road — service templates, deployment pipeline, observability wired in, authentication, standard libraries, a working reference implementation — converts guidance into the path of least resistance.

Adoption is then a signal, not a compliance statistic: low adoption means the road does not fit the problems teams have. Mandating use destroys that signal permanently.

Change what is measured

Report on the estate and on the organisation's ability to change it: application and integration count, technologies under support, spend against business volume, proportion of the estate on supported technology, lead time for change and deployment frequency, and paved road adoption.

Baseline before starting, and attribute conservatively — a modest defensible claim repeated over years builds more standing than a large disputed one.

Sequence it

First quarter: stop the low-value artefacts, publish decision rights, and fix one thing teams are visibly blocked on — which buys the credibility for everything else. Then the automated policy. Then the paved road. The measurement framework runs from the start, because without a baseline none of it can be demonstrated later.