TOGAF in Practice

Definition

A framework comprising an architecture development method (a cycle from vision through business, data, application and technology architecture to implementation governance), a content framework, and a capability model.

What is genuinely useful

• The vocabulary. Shared terms for architectural artefacts across an industry, so a new architect arrives with a working language.
• The completeness checklist. The method's phases are a reminder of what an enterprise change needs to consider — data implications, governance, migration, and so on. Useful precisely as a checklist.
• The gap analysis frame. Baseline architecture, target architecture, and the gap between them, is a sound way to structure a change programme.
• The idea of iteration. The cycle is meant to be repeated at different scopes, which is more pragmatic than the framework's reputation suggests.

Where it does harm

Followed literally as a sequential process, it produces very large documents, long cycles and a target architecture that is obsolete before implementation begins. The phases invite a document-per-phase interpretation that is not required by the framework and is common in practice.

As a source of authority. An architecture defended on the grounds that the framework prescribes it has stopped being an argument about the system.

As a compliance exercise. Artefacts produced to satisfy a governance process rather than to inform a decision consume the practice's entire budget.

How to use it well

As a checklist, not a process. For each phase, ask "have we considered this?" and produce an artefact only where the answer reveals a real gap and a real decision.

Iteratively and at a small scope. Apply the cycle to one capability or one programme, not to the enterprise.

With a bias toward decisions over documents. The corrective question for any artefact: which decision does this inform, and who is making it? If there is no answer, do not produce it.

The general point about frameworks

Frameworks encode accumulated experience, which is genuinely valuable, and they are drawn for a general case that differs from yours in the specifics that matter. The same tension applies to reference architectures and to well-architected guidance: adopt the considerations, decide each element explicitly, and record why when you exclude one.

Failure scenarios

• A two-year architecture programme producing documents and no delivered change.
• Artefacts as deliverables, disconnected from decisions.
• The framework as authority in technical arguments.
• A target architecture that assumed a world that has since changed.

Interview question

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