Which enterprise architecture artefacts would you actually maintain, and why those?

What is being tested

Editorial judgement about what survives contact with reality — which is the same skill as knowing what to document for a system handover.

The five worth maintaining

1. A capability map with overlays. Supports investment decisions: what differentiates, what duplicates, where the cost is. It is the only artefact a business audience will engage with directly, which makes it the entry point for every funding conversation.

2. A context diagram per significant system. The system, its users, and everything it talks to. Almost never wrong, almost always the first thing a newcomer needs, and cheap to maintain.

3. Decision records, with the alternatives rejected and — the section usually missing — what would make this the wrong choice. The rejected options are the valuable half: without them the next person re-litigates every settled question and frequently re-makes an avoided mistake.

4. A technology lifecycle register. Version, supported-until date, adoption stage, upgrade owner. This is what turns obsolescence from a surprise discovered in an audit into a managed queue.

5. An application portfolio with lifecycle classification. Supports rationalisation, continuity prioritisation and ownership.

Why these and not the rest

Each has a named decision it supports and an owner who needs it. Each is small enough to be maintained by a process rather than by a project.

The artefacts that do not survive share the opposite properties: comprehensive, produced once, no named consumer, and stale within a quarter. A detailed enterprise data model, a full component inventory, a sequence diagram for every interaction — all accurate on the day written and misleading ever after.

The maintenance question, which decides everything

An artefact accurate on the day it was produced and wrong six months later is worse than none, because people act on it.

So tie updates to events that already happen — a deployment, a team change, a decommissioning, a decision — rather than to an annual refresh nobody funds. Anything requiring a dedicated maintenance effort will not be maintained.

Better still, derive rather than document where possible: generate the integration map from observed traffic, the technology inventory from deployment metadata, the ownership record from the repository. Derived artefacts cannot go stale.

What a strong answer adds

That the test for adding an artefact is whether someone is currently asking a question it would answer. Producing artefacts against hypothetical future questions is exactly how a practice spends its budget on documentation and is then correctly perceived as an overhead.