The previous article defined the dead artefact: disconnected from the decision that produced it, written after the fact, accurate at the moment it was saved and wrong by the time anyone consults it.
The EA repository is where dead artefacts go to accumulate.
Not because repositories are wrong. Because the way most organisations have built them — their structure, their update rhythm, their relationship to delivery — guarantees that what they store drifts from what is real. The repository was designed to record architecture. The decision system requires something different: a mechanism that connects decisions to records at the moment they are made, and keeps those records current as reality changes.
Most repositories cannot do that. This article examines why — and what has to change.
What Repositories Were Built to Do
Enterprise Architecture repositories emerged from a legitimate need: organisations needed a single source of truth for the technology estate. That need is real. The repository served it reasonably well — as an archive. A record of how the estate looked at a point in time, updated periodically, consulted during planning cycles, and referenced in governance forums.
The problem is that delivery no longer operates on planning cycles.
Cloud platforms enable infrastructure to be provisioned in hours. Autonomous teams make architectural decisions continuously, not quarterly. Integration patterns are chosen, tested, and promoted to production before a repository curator has been notified that a question was asked.
The repository was designed for a world where architecture was decided upstream and executed downstream. That world no longer exists in most technology organisations.
This is not an argument against comprehensive repositories. Regulated industries require full traceability. Risk, audit, and compliance depend on a complete record. The argument is not that completeness is wrong. It is that completeness and currency are different obligations, and confusing them produces a repository that satisfies neither.
An archive stores artefacts. An operating system shapes decisions.
The Tuesday Test
Here is a practical diagnostic. It is Tuesday afternoon. A Solution Architect is evaluating a new capability or integration pattern. The decision needs to be made before Friday.
The architect needs answers to four questions:
- Which domains does this touch, and who owns them?
- What constraints apply, and are there existing guardrails or standards for this pattern?
- Has this been done before, and if so, was it approved or an exception?
- What is the escalation path if the pattern conflicts with an existing constraint?
In a functioning decision system, these questions have structured answers that can be retrieved in minutes, not days. In most organisations, none of these answers exist in retrievable form.
The repository exists. The answers do not.
Now scale that failure. A new initiative lands — an AI capability, a platform migration, a regulatory requirement. Four different business units are involved. Four architects are working the problem in parallel. None of them can find the constraints, the ownership, or the precedents in the repository. So each one reconstructs the context independently — through meetings, threads, and conversations with people who were there last time. The same ground is covered four times. The same decisions are renegotiated four times. The same institutional knowledge is rebuilt four times from scratch.
That is not four architects failing. That is one repository failing four architects simultaneously.
We cannot architect in the dark. And a repository that cannot answer the Tuesday Test is not a source of light. It is the darkness itself.
Why Meta-Models Make It Worse
The standard response to repository inadequacy is meta-model investment. If the repository cannot answer delivery questions, the assumption is that the underlying data model needs to be richer, more connected, more comprehensive.
This is usually wrong, and often counterproductive.
The problem is not a lack of volume. It is a lack of relevance. More data creates a bigger archive. Meta-models optimise for completeness. They create a maintenance burden that the organisation cannot sustain at delivery velocity. Every new system, every integration, every change to the application landscape requires a repository update. In practice, those updates happen inconsistently, selectively, and late.
The result is a repository that is comprehensive in structure and unreliable in content. Architects learn not to trust it. Delivery teams learn to route around it.
Here is what that actually costs. When the repository cannot be trusted, organisations make a silent tactical choice: they accept the rework instead. Rework becomes a hidden Opex cost buried in project budgets. Repository maintenance gets classified as unproductive overhead.
The capability to answer the Tuesday Test automatically already exists. Dynamic impact analysis, cross-layer traceability, live landscape visualisation — these are not emerging capabilities. They are available today in mature tooling that most large organisations already know about. The decision not to invest in them is not a capability gap. It is a cost decision that never includes the full cost of what four architects are not doing while they are reconstructing context.
Consider the arithmetic: a senior architect spending two days reconstructing context that should have taken an hour. Multiply that across four parallel programmes, every quarter, across a portfolio. Repository maintenance stops looking like overhead. It starts looking like the cheapest investment the organisation is not making.
The resourcing argument compounds the problem further. There are not enough architects to maintain the repository because the investment in the right roles was never made. No Head of Architecture with mandate. No practice management function with accountability for the integrity of the record. The function gets measured on what it produces, not on whether what it produces is connected to reality. The factory keeps producing. The record keeps decaying. The cycle continues.
A repository updated for auditors, not architects, governs nothing. It records the past and obscures the present.
The Three Structural Failures
EA repositories fail as decision infrastructure in three consistent ways.
Failure 1 — Constraints Live in the Wrong Format
Most repositories store architectural guidance as narrative: principles, position papers, reference architectures, and pattern libraries. These are useful as education. They are not useful as decision infrastructure.
A principle document cannot be queried. It cannot surface the constraints that apply to a specific integration pattern. It requires interpretation — and at delivery velocity, interpretation is a tax that compounds invisibly across hundreds of decisions.
Constraint clarity requires constraints to be expressed in a form that removes interpretive overhead at the point of decision. Structured records with defined scope, explicit enforcement logic, and a named owner. Not prose. Not a position paper that requires a meeting to decode.
The structured constraint is the operative form. The narrative is context. Confusing the two — treating the narrative as the operative form — is where most organisations are currently stuck.
Failure 2 — Ownership Is Implicit, Not Recorded
Domain ownership is the most important piece of context a Solution Architect needs when evaluating a design decision. In most repositories, this information is either absent or stale. It was accurate when the repository was populated. It has not kept pace with reorganisations, platform migrations, and team evolution.
The practical consequence is that Solution Architects reconstruct domain ownership through informal networks. The repository is bypassed not because architects are undisciplined, but because it cannot answer the question they are actually asking.
Failure 3 — Precedents Are Invisible
One of the most valuable things a decision system can provide is precedent: the record of decisions already made, the rationale behind them, and whether they held or were subsequently overridden.
Most repositories do not integrate decision records in any meaningful way. Decisions exist in project folders, email chains, and the memories of architects who have since moved on.
The consequence is that the same architectural questions are renegotiated repeatedly. Institutional memory fails silently. The organisation pays the cost of the first decision multiple times.
Precedent is not authoritative. Context changes. Platforms evolve. A decision record does not tell the next architect what to decide. It tells them what was decided before, under what conditions, and why — so they can determine whether those conditions still apply.
What the Repository Needs to Become
From Narrative to Structured
Architectural guidance needs to exist in two forms. The narrative form — principles, position papers, reference architectures — remains valuable for education and onboarding. But alongside it, the same intent must be expressed as structured constraints: scoped to specific domains, classified by enforcement level, with named owners and explicit escalation paths.
From Inventory to Context
Repository content needs to shift from comprehensive application inventory toward the specific context that delivery decisions require: which domains a capability touches, what constraints apply at that domain boundary, who has authority to approve patterns that cross it, and what precedents exist.
From Periodic to Continuous
The update rhythm of most repositories is incompatible with delivery velocity. The repository needs to be integrated into delivery workflows — not as an additional administrative burden, but as the place where delivery decisions are recorded as they happen.
The principle is simple: the decision triggers the record, not the other way around. The record is not an output produced after the work. It is part of the work.
The Honest Transition
The practical path is containment, not revolution.
Pick one domain where delivery questions are being answered slowly or inconsistently. Identify the three to five constraints that actually govern decisions in that domain. Express them in structured form. Name the owners. Build the escalation path. Connect it to the delivery workflow for one team.
The tooling you have today does not need to be replaced to start. A structured constraint expressed in a shared document, owned by a named person, referenced at the point of decision is more valuable than a sophisticated model that nobody trusts.
Measure decision latency before and after. How long did it take to answer the Tuesday afternoon question? If it compressed, leverage is forming.
Expand from there. One domain at a time. One constraint structure at a time.