EA Frameworks

Definition

Several frameworks exist, each emphasising something different:

• TOGAF — a development method and content framework. The most widely adopted; strongest as a checklist.
• Zachman — a classification matrix of perspectives (planner, owner, designer, builder) against questions (what, how, where, who, when, why). Not a method; a way of checking that a viewpoint has not been overlooked.
• Sector-specific frameworks — used in government and defence, heavier and mandated in their contexts.
• Lightweight and in-house approaches — architecture decision records, capability maps, C4 diagrams, a small set of principles. What most organisations actually use successfully.

What frameworks contribute

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

What they do not provide

Judgement. No framework tells you whether to split a service, which consistency model to choose, or whether the capability is worth building. Those are the decisions that matter, and they are made with evidence and reasoning rather than with a method.

The common failure

Adopting a framework wholesale, producing every artefact it describes, and measuring the practice by artefact completion. The practice consumes its budget on documentation and is then correctly perceived as an overhead by the engineering organisation.

The symptom is easy to detect: architects producing models, and engineers making the actual architectural decisions without them.

The pragmatic position

Take the viewpoints and the completeness checklist from the frameworks. Produce the small number of artefacts that inform real decisions:

• A capability map with overlays, for investment decisions.
• A context diagram per significant system.
• Decision records with the alternatives rejected and the conditions for revisiting.
• A technology lifecycle register.
• An application portfolio with lifecycle classification.

That set is maintainable, and each item has a named decision it supports. Everything else should be justified by a specific question someone is asking.

Failure scenarios

• The framework as the goal, measured in artefacts.
• Models nobody uses, maintained by nobody.
• Architects separated from delivery, so the models describe an organisation that no longer exists.
• Framework language used to win arguments rather than reasoning.

Interview question

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