TOGAF in the Real World: What the Exam Doesn’t Teach You

Passing the certification is the easy part. Here's what actually matters when you're using it on a live program.

I passed the TOGAF 9 certification on a Saturday morning. By Monday I was back at work, facing an architecture challenge that the study materials had not prepared me for at all.
Not because TOGAF was wrong. It wasn't. But there's a significant gap between understanding a framework in the abstract and knowing how to apply it when you're sitting across from a program sponsor who wants a delivery date, a procurement team asking which vendor to pick, and a security team flagging concerns about a design that was approved three months ago.

TOGAF teaches you the what. Real programs teach you the how. This article is about the how.

What TOGAF gets right
Before the caveats, credit where it's due.
The Architecture Development Method — the ADM — is genuinely useful as an organizing principle. The idea that architecture work moves through phases, from vision to business architecture to information systems to technology and then into implementation governance, gives you a mental model for sequencing your work and knowing what questions to answer first.
The emphasis on stakeholder management is underrated. Most architects coming up through technical ranks underestimate how much of the job is communication — translating technical complexity into language that business stakeholders can act on, and translating business intent into technical constraints that engineering teams can design against. TOGAF names this explicitly, even if the exam tests it superficially.
The concept of an Architecture Repository — a structured store of architectural decisions, principles, standards, and reference models — is exactly right. Organizations that maintain one make better decisions faster. Organizations that don't end up re-litigating the same ground repeatedly.

These are real insights. They hold up.

What the exam doesn't prepare you for

1. Nobody follows the ADM sequentially
   The ADM is presented as a cycle. In practice, it's more like a set of tools you reach for in whatever order the situation demands.
   You will rarely complete Phase A before starting Phase B. You will frequently be handed a partially complete architecture and asked to fill in the gaps. You will sometimes be brought in mid-program, after key technology decisions have already been made, and asked to produce architecture documentation that reflects reality while also identifying the risks that the earlier decisions introduced.
   The skill the exam doesn't test is knowing which phases and which outputs matter most for your specific context — and being willing to skip or compress the ones that don't.
   On a fast-moving agile program, spending three months producing a comprehensive Phase B Business Architecture document before anyone has written a line of code is a good way to become irrelevant. The program will move without you. The architecture that gets built will be the one the developers designed informally, not the one you documented formally.

   The practical lesson: use the ADM as a checklist of concerns to address, not a sequence of steps to follow. Ask yourself which phases have unresolved questions that carry real risk. Start there.

2. Architecture principles sound obvious until you try to enforce them
   TOGAF places significant emphasis on Architecture Principles — statements like "reuse before buy before build" or "data is an asset" that are meant to guide decision-making across the organization.
   Writing principles is easy. Getting anyone to actually use them is hard.
   The problem is that principles stated at the right level of abstraction to be broadly applicable are often too vague to be action-guiding in a specific situation. "Reuse before buy before build" sounds sensible. But when a team is evaluating whether to extend an existing integration platform that's already at capacity, or procure a new one, or build a lightweight custom solution — the principle doesn't tell them what to do. It just tells them what to consider first.
   Principles become useful when they're paired with worked examples — concrete decisions from real programs where the principle was applied, with an explanation of how it shaped the outcome. An architecture principle without an example is a slogan.

   The practical lesson: when you inherit or create architecture principles, immediately ask for or create illustrative examples. If a principle can't be applied to a real decision, it isn't ready.

3. The gap between architecture and delivery is where things go wrong
   TOGAF covers implementation governance — Phase G in the ADM — but it gets relatively little attention in exam preparation compared to the earlier phases. This is backwards.
   In practice, the most consequential architecture work happens after the design is approved. The design is a set of intentions. What gets built is determined by a hundred small decisions made during delivery — by developers interpreting requirements, by engineers choosing between two technically valid approaches, by teams under schedule pressure taking shortcuts that seem harmless in isolation.
   Without active architecture engagement during delivery, the gap between the intended design and the actual system widens steadily. By the time the program goes live, the architecture that exists may bear only a passing resemblance to the architecture that was approved.
   This isn't a failure of engineering. It's a failure of governance. Architecture review doesn't end when the design is signed off — it continues through delivery, in the form of regular touchpoints, ADR reviews, and a willingness to update the architecture when delivery reveals something the design didn't anticipate.

   The practical lesson: negotiate architecture involvement in delivery from the start of a program, not as an afterthought. The value of good architecture is only realized if the build reflects it.

4. Stakeholder management is the hardest part of the job
   TOGAF acknowledges stakeholder management. The exam tests your knowledge of stakeholder maps and communication plans. Neither of these prepares you for the actual experience of trying to align a room full of people with different organizational incentives, different risk tolerances, and different definitions of the word "done."
   The technical aspects of architecture — designing systems, evaluating trade-offs, producing documentation — are learnable from books and experience. The human aspects are harder.
   How do you handle a senior stakeholder who has already publicly committed to a technology choice before the architecture review has been completed? How do you maintain the integrity of an architectural recommendation when a program sponsor is pushing back because the recommendation adds six weeks to the schedule? How do you give honest, unfavourable feedback to a team that has invested months in a design that has a fundamental flaw?
   These situations don't appear in the study materials. They appear every few months in real programs.

   The practical lesson: invest in your communication skills as deliberately as your technical skills. Learn how to frame architectural concerns in terms of business risk rather than technical correctness. Understand what each stakeholder cares about most, and shape your message accordingly. The right answer, poorly communicated, loses to the wrong answer, confidently delivered.

5. The deliverables are a means, not an end
   TOGAF defines a rich set of architectural deliverables — baseline and target architecture descriptions, gap analyses, roadmaps, architecture contracts. In the wrong hands, this becomes a documentation exercise that consumes enormous effort and produces artifacts that nobody reads.
   The question that TOGAF doesn't ask often enough is: who is this deliverable for, and what decision does it enable?
   An architecture document that doesn't help someone make a better decision is overhead. It might satisfy a governance requirement on paper, but it's not doing useful work. The best architecture documentation is the minimum necessary to align stakeholders, guide delivery, and preserve institutional memory — no more.

   The practical lesson: for every deliverable you're asked to produce, ask what decision it enables or what risk it mitigates. If you can't answer that question, the deliverable probably needs to be scoped down or rethought.

What TOGAF actually gives you
None of the above is an argument against TOGAF. It's an argument for using it as a practitioner rather than as a theorist.
TOGAF gives you a common language — a shared vocabulary for talking about architecture concerns across organizations and programs. When you say "we're in Phase C" or "this needs to go through the ARB" or "we need a solution architecture document before we can proceed," people who know the framework understand what you mean. That shared language has real value.
It gives you a checklist of concerns that matter in most programs. Even if you don't follow the ADM sequentially, running through its phases as a mental checklist helps you identify what hasn't been addressed. Have we defined the business architecture? Have we identified the risks in the technology choices? Have we thought about the migration path from the current state?
And it gives you credibility — not because the certification proves competence, but because it signals that you've engaged seriously with the discipline of architecture as a practice, not just as a technical skill.

The exam is the beginning of the education, not the end of it.

The things that actually make you good at this
After the certification, the skills that matter most are the ones TOGAF touches on but doesn't teach deeply:
Judgment — knowing which architectural concerns are worth fighting for and which are acceptable trade-offs given the program's constraints. This comes from experience, reflection, and the intellectual honesty to notice when you were wrong.
Communication — the ability to make complex trade-offs legible to non-technical stakeholders, and to make business priorities legible to technical teams. The architect who can do this fluently is worth several who cannot.
Governance discipline — the habit of documenting decisions when they're made, tracking conditions to closure, and maintaining the institutional memory that prevents the same mistakes from being made twice.
Pragmatism — the willingness to produce the right architecture for the constraints that actually exist, rather than the ideal architecture for the constraints you wish existed.

None of these appear on the exam. All of them show up in the work, every day.

I write about enterprise architecture for practitioners — the parts that actually matter on live programs, not just in certification prep. Follow me on Medium if that's useful to you.
For architects building or formalizing their practice, I've put together a set of templates covering ADRs, ARB governance, and architecture decision tracking — the artifacts that make the governance discipline easier to sustain.

[Enterprise Architecture Starter Kit — available on Gumroad]

About the Author
Salim Reja is a Solution Architect with over a decade of experience in enterprise architecture, cloud governance, and large-scale technology programs in regulated industries. He holds certifications including Azure Solutions Architect Expert, Cybersecurity Architect Expert, Azure Security Engineer Associate, TOGAF® 9 Certified, Professional Scrum Master (PSM I), Azure AI Fundamentals, and Leadership Essentials from Schulich Executive Education.
He writes about enterprise architecture for practitioners - the parts that matter on real programs, not just in theory, the decisions, trade‑offs, and delivery realities that shape real programs.
Architecture Resources
Enterprise Architecture Starter Kit
Azure Landing Zone Design Kit