Worked Example — The Architecture Team Nobody Consulted

This is an illustrative example. The organisation, function and figures are invented. The failure mode — a competent architecture team producing work that nothing consumes — is common and is usually diagnosed as a communication problem when it is not.

The situation#

A financial services company, 1,400 staff, with an enterprise architecture function of four people. Two years old, well staffed, technically strong.

Its output was substantial: a current-state model of 210 applications, a target architecture, a five-year roadmap, twelve standards documents, and a repository maintained in a specialist tool.

In the same two years, six significant technology decisions had been made:

One of six. The function's own view was that the business went around them. The business's view, when asked, was more specific and more useful.

What the business actually said#

Fifteen interviews, conducted by someone outside the function.

"They take six weeks. We had four."

"They tell us what is wrong with the plan. We need to know what to do."

"The repository needs a licence and training. I asked a question in an email instead."

"Every answer is 'it depends' followed by a document."

"By the time architecture is involved, we have signed. That is not their fault, but it is too late to matter."

Nobody said the work was wrong. Several said it was good. The complaints were entirely about speed, form and timing, and those three are what determine whether work is used.

The three things that were actually wrong#

The output was documents, and the input needed was answers. A programme manager choosing between two suppliers needs a recommendation with reasons, this week. What existed was a target architecture and an offer to assess alignment, which is a different thing arriving on a different timescale.

The function engaged after the decision. By the point architecture was asked, a supplier had been chosen and a budget approved. Everything the function could offer at that stage was an objection, which is why it was experienced as an obstacle.

The knowledge was where nobody was. A repository requiring a licence and training is a repository for the architecture team. Everyone else asked a colleague.

What changed#

Nothing about the analysis. Everything about how it reached people.

A 48-hour answer. Any question, answered within two working days: a recommendation, three reasons, and what would change it. If a full assessment was needed, the 48-hour answer said what to do meanwhile.

This was contested inside the function — two days is not enough for rigour. It was adopted anyway, on the argument that a good answer in two days beats a better one after the decision has been made. In practice most questions had been answered before; what was missing was a way to ask.

A place in the purchase process. Any spend over a threshold triggers a one-page architecture view: which capability, what already serves it, what data it duplicates, how many integrations it adds, and a recommendation. One page, three days, before the shortlist rather than after it.

This was the change that mattered most, and it was a change to the procurement process rather than to architecture.

The map moved to a page. The 210-application repository stayed for the people who maintain it. What everyone else got was a single page on the intranet: capabilities, the systems supporting each, the owner of each, and the current disposition. No licence, no training, searchable.

Traffic to it in the first month exceeded two years of repository access.

Standards were cut from twelve documents to one page. Each rule states what it prevents. Anything nobody had followed in two years was deleted rather than restated, on the basis that an ignored standard teaches people that standards are ignorable.

Exceptions got expiry dates. Previously permanent, now maximum twelve months, then reviewed. The register went from 34 permanent exceptions to 11 with dates.

The result#

Three duplicate purchases prevented is the number that funded the function internally. In each case the requesting department had not known a system already existed with the capability, and the one-page view answered it before a supplier was engaged.

What was not fixed#

Recorded honestly. The target architecture still exists and is still largely unread. Some of it is genuinely useful for multi-year planning; a good deal of it describes an end state nobody has committed to.

The function's own view is that roughly half of it should be deleted, and nobody has yet been willing to do it.

What was learned#

Being right is not the same as being used. The analysis was good for two years and changed one decision.

Fit the timescale of the decision, not the timescale of the analysis. A 48-hour answer changed the function's position more than any improvement to the model would have.

Engage before the shortlist. After a supplier is chosen, architecture can only object, and a function that only objects gets routed around.

Knowledge behind a licence does not exist. Two years of repository access were exceeded in one month by a page on the intranet.

Delete the standards nobody follows. Keeping them teaches people that standards are optional, which is a worse outcome than not having them.

Back to Enterprise Architecture