TOGAF is everywhere. On résumés, in job postings, in RFPs. It’s an excellent framework. It has also become, in some organizations, an alibi for slowness and complexity. This post is for those who want to extract its value without enduring its weight.

What TOGAF really brings

Three things, each enough to justify mastering it.

A shared vocabulary. When the data architect, the application architect, and the technical architect all talk about “capabilities”, “building blocks” and “target state”, they can finally understand each other. Trivial to say, huge to live.

An iterative method (the ADM). The Architecture Development Method cycle isn’t a waterfall — it’s explicitly iterative. You can step out of phase E (Opportunities & Solutions) to go back to B (Business Architecture) if you discover something. That’s what makes it a framework, not a rigid process.

A structuring meta-model. TOGAF’s Content Framework describes how to articulate architecture concepts together. Once you’ve internalized it, you stop reinventing the wheel on every project.

The three classic traps

Trap 1: doing the full ADM on every engagement. The TOGAF cycle’s eight phases (from Preliminary to Architecture Change Management) take 12 to 18 months in a large organization. Run it in full on every project and you’re dead. The best practice: pick an Architecture Development Iteration fit to the scope.

Trap 2: producing every artifact in the Content Framework. TOGAF lists dozens. Most are useless in your specific context. Pick the ones that drive a real decision. Drop the rest without guilt.

Trap 3: confusing certification with competence. A TOGAF-certified person who’s never run a transformation is less useful than an experienced architect without the badge. Certification is a starting point, not an endgame.

Our pragmatic method

At TechWizard, we use TOGAF as a toolkit, not as a doctrine. Here’s how:

1. Framing. We identify the architecture scope that actually matters — often 20% of the IS generates 80% of the risk. No need for an exhaustive map before acting.

2. Short iterations. We structure engagements in 6 to 12-week cycles with verifiable deliverables. No 18-month tunnel programs.

3. Minimal artifacts. For each project, we produce 5 to 8 artifacts at most — those that drive architecture board decisions. Everything else lives in EA-Wizard, available on demand.

4. Adapting to local frameworks. In Morocco, France, Côte d’Ivoire, regulatory constraints differ (Bank Al-Maghrib, ACPR, BCEAO). We adapt TOGAF phases to these reference frames instead of ignoring them.

When TOGAF isn’t enough

TOGAF is weak on three modern topics: AI, composable architectures, data mesh. That’s not a flaw — it was designed in another era. For these topics, we complement with other frameworks (DAMA-DMBOK for data, cloud-native patterns for composability, and our own method for augmented AI).

In summary

TOGAF is an excellent vocabulary and a robust iterative method. It’s also a framework that punishes dogmatism. Use it to structure your thinking, not to replace it.

A good architect knows TOGAF. A great architect knows when to step away from it.