Skip to content
Spekir

EAInsights

Your architecture model is already out of date. It is not your fault.

Survey fatigue and manual upkeep kill even good EA initiatives. A living model inverts the division of labour: software gathers, agents propose, people confirm.

Rasmus Sloth Nielsen
Rasmus Sloth NielsenFounderLinkedIn

7 min readLiving model / Enterprise Architecture / AI

Jump to section...

Anyone who has worked with enterprise architecture knows the life cycle.

Year zero: excitement. A repository is bought or built, workshops are run, the system map is drawn. It looks good. It makes it into a leadership deck.

Year one: friction. System owners get sent the half-yearly survey. The response rate is, let us call it modest. The architect chases answers, updates by hand, and starts using the phrase "it is roughly accurate".

Year two: silence. A leader makes a decision based on the model, discovers that three of the systems were decommissioned last year, and never trusts the repository again. The model did not die of one error. It died of evaporation.

This is not a story about lazy organisations. It is a story about a division of labour that never worked: people are excellent at confirming and correcting, and terrible at remembering to update registers. The entire classic EA discipline is built on the weakest human ability there is: sustained, voluntary data entry.

Surveys are a polite way to collect wrong data

Let us be honest about the system-owner questionnaire. It asks busy people to interrupt real work to re-enter knowledge that already exists in other systems: who uses the application is in the SSO log, what it costs is in the finance system, when it was last updated is with the vendor.

The survey is, in other words, a manual integration, performed by the most expensive staff, with the lowest possible motivation. That the industry calls the result "survey fatigue" is almost affectionate. It is not fatigue. It is a rational opt-out.

The living model inverts the division of labour

The principle behind a living model is simple: software gathers, agents propose, people decide.

In Atlas it looks like this:

The signals flow in on their own. Import and connectors pull in what is already recorded elsewhere. Nobody is asked to re-enter anything a machine can look up.

Agents write the draft. Background agents enrich records, spot likely duplicates, flag stale information and propose relationships: this system probably supports this capability, this application looks like an AI feature that belongs in the registry. Every suggestion comes with a reason and a source.

People confirm in Verify. Every suggestion lands in one inbox. The system owner who used to get a fifteen-minute questionnaire now gets a draft and a button. Confirm, correct or reject. Ten seconds, not fifteen minutes. That is the whole difference between a model that rots and a model that lives: maintenance is no longer a task someone has to remember. It is a flow the system drives itself.

Freshness is visible. Every fact knows when it was last confirmed, and by what. The model does not claim to be perfect. It shows you exactly where it is confident and where it has gone stale. That sounds humble. It is actually the opposite: it is the only kind of confidence you can check.

Why this matters more now than two years ago

A new reader of the architecture model has arrived, and it reads much faster than we do.

Organisations' own AI assistants and agents need context about the business: which system owns customer data, who approves what, what connects to what. With the Model Context Protocol they can pull that context straight from the model. Atlas serves it with citations, and takes change proposals back through review.

But it sets one unforgiving requirement: the model has to be true. A stale model read by people costs a bad decision now and then. A stale model read by agents in production scales the errors with machine power.

A living model is therefore no longer a quality wish for the architecture team. It is the infrastructure precondition for the entire agentic enterprise.

Test the idea on your own model

Three questions that decide whether your current approach lives or evaporates:

  1. When was your system map last updated by something other than a human on a deadline?
  2. Can you see which parts of the model are fresh, and which are antiques?
  3. If an AI assistant asked your model something tomorrow, would you be proud of the answer?

If the answers sting a little, the problem is not you. It is the division of labour. It can be swapped out, so it holds together.

Try Atlas at atlas.spekir.com. The demo workspace comes with a realistically messy landscape, so you can watch the Verify flow work. Or talk to us about EA.

ShareLinkedInX

Spekir builds the layer that connects strategy to the IT portfolio. See Atlas

Related articles