TOGAF occupies a strange position: simultaneously the world's most-recognised enterprise architecture credential and the industry's favourite punching bag. Both reputations are earned. After certifying and then spending years watching organisations apply, misapply and ignore it, here's my working verdict.

1. The case against, fairly stated

The critics aren't wrong about the symptoms: nine-phase ADM cycles that outlive the strategies they were meant to serve; deliverable factories producing artifacts nobody reads; architecture review boards that function as innovation toll gates; and a certification exam that tests recall of the framework rather than judgement in using it. Where EA fails, it usually fails like this — process worship without decision-making authority or business connection.

2. What TOGAF actually gets right

Underneath the ceremony, the framework encodes a handful of ideas that I use weekly and that nothing else in my certification stack teaches:

  • Capability before component. Technology exists to serve business capabilities. Sounds obvious; is violated by almost every vendor-led buying decision I've ever reviewed.
  • Baseline and target, explicitly. You cannot govern change if nobody has written down where you are and where you're going. Half of "our IT is a mess" reduces to the absence of these two pictures.
  • Gap → roadmap → governance. The discipline of deriving projects from architectural gaps — instead of collecting projects and hoping architecture emerges — is the difference between a portfolio and a pile.
  • Principles as tie-breakers. A short set of agreed principles ("buy before build", "one identity platform") settles ninety arguments before they start.

3. What to ignore (even the Open Group quietly does)

Treat TOGAF as a library, not a liturgy. Run the ADM as a mindset — understand context, envision, plan, govern, iterate — not as nine sequential gates. Produce the three artifacts people actually use (capability map, current/target platform picture, decision log with principles) and skip the catalogue of forty deliverables. And never let the architecture function own approval without also owning enablement; a review board that only says no is a queue, not a practice.

4. Why the AI era makes this more relevant, not less

The strongest argument for EA discipline right now is sitting in every boardroom: an urgent mandate to "adopt AI" colliding with estates that were never mapped. I keep watching the same failure: pilots multiply, each buying its own model access, vector store and integration glue; nothing reaches production because nobody can answer which business capability is this transforming, what data does it touch, and who governs the risk? — which are, precisely, architecture questions.

AI adoption is an enterprise-architecture problem wearing a data-science costume: capability targeting (where does intelligence change the operating model?), data architecture (can we lawfully and technically feed it?), integration standards (MCP and API strategy instead of point wiring), and risk governance (my CRISC lens again — model risk is enterprise risk). Organisations with even lightweight EA are shipping AI into production; organisations without it are shipping decks.

5. So — certify or not?

  1. If you're an architect or heading there: yes. Not for the badge — for the shared vocabulary with every large organisation's existing EA function, and for the forced tour of business-first thinking. Budget as much time practising on your own organisation as memorising the framework.
  2. If you're a senior engineer sceptical of EA: the certification will annoy you and improve you in equal measure. You'll exit better at the meetings where budgets are decided.
  3. If your organisation "did TOGAF" and hates it: the problem is likely the liturgy, not the library. Strip it to capability map + target picture + principles + decision log, staple it to the AI roadmap everyone wants, and watch the function earn its seat back.

Frameworks age; the questions they encode don't. As long as businesses buy technology faster than they understand it, someone in the room needs the architecture view — certified or otherwise, I'd rather it be someone who's studied it.