How would you use an enterprise architecture framework without producing shelfware?

What is being tested

Whether you can extract the value from a framework without inheriting its ceremony.

The corrective question

For every proposed artefact: which decision does this inform, and who is making it?

If there is no answer, do not produce it. That single discipline removes most shelfware, because most shelfware exists to satisfy a process rather than to inform a choice.

Use the framework as a checklist, not a process

The development cycle's phases are a useful reminder of what an enterprise change must consider — data implications, governance, migration, security, operability. Walk through them and ask "have we thought about this?"

Produce an artefact only where the answer reveals a real gap and a real decision. Followed literally as a sequential process, the phases invite a document-per-phase interpretation that produces very large documents, long cycles, and a target architecture obsolete before implementation begins.

Apply it iteratively at a small scope

Run the cycle for one capability or one programme, not for the enterprise. A two-year enterprise-wide architecture programme will be overtaken by events, and its target will describe a world that no longer exists.

The artefacts actually worth maintaining

• A capability map with overlays — for investment decisions.
• A context diagram per significant system — almost never wrong, almost always useful.
• Decision records with the alternatives rejected and the conditions for revisiting.
• A technology lifecycle register — for obsolescence exposure.
• An application portfolio with lifecycle classification.

Five artefacts, each with a named decision it supports, each maintainable. Everything else should be justified by a specific question someone is asking now.

What the framework genuinely contributes

Vocabulary, so people who have not worked together share terms. Completeness, as a check. Legitimacy, which is a real benefit in organisations where an external reference carries weight.

What it does not provide is judgement. No framework tells you whether to split a service, which consistency model to choose, or whether a capability is worth building — and those are the decisions that matter.

The symptom of failure

Architects producing models while engineers make the architectural decisions without them. If that is happening, the practice has become a documentation function, and no amount of additional artefacts will fix it.

What a strong answer adds

That an architecture defended on the grounds that the framework prescribes it has stopped being an argument about the system. Frameworks are a source of considerations, never of authority.