TOGAF Pitfalls & Best Practices: EA Lessons from the Field

The Most Common Enterprise Architecture Pitfalls

The most common enterprise architecture pitfalls are the Ivory Tower syndrome (producing designs nobody uses), analysis paralysis (spending months modelling instead of delivering), and communication failure (producing technically correct documents in language stakeholders cannot understand). Recognising these patterns early is what separates architects who create lasting change from those who create impressive-looking repositories that collect dust.

Being an Enterprise Architect is one of the hardest jobs in technology. You are expected to be a visionary, a diplomat, and a deep-dive expert all at once. It’s no wonder that many architecture projects fail or lose momentum.

Over the years, we’ve seen the same mistakes repeated in almost every industry. In this final post of Module 4, we’ll look at the biggest pitfalls you need to avoid and the best practices that will ensure your architecture team delivers real value to the business.

Pitfall 1: The "Ivory Tower" Architect

This is the most common reason EA teams fail. The "Ivory Tower" architect is someone who spends all their time in a dark office, designing perfect models that have no connection to the real world. They don't talk to the developers, and they don't listen to the business owners.

The Fix: Be a "Boots on the Ground" Architect

Get out of your office. Sit with the delivery teams. Go to the business meetings. Your architecture only matters if people actually use it to build things. If your designs are too complex or too theoretical, the teams will simply ignore them and "do their own thing."

Pitfall 2: Analysis Paralysis

Architects love detail. But sometimes, they get stuck in a loop of trying to map everything perfectly before starting. They spend months in Phase B and C of the ADM, only to find that the market has already moved on.

The Fix: Apply the 80/20 Rule

You don’t need a 100% perfect model to make a good decision. Often, 80% of the value comes from 20% of the information. Focus on the most important "core" capabilities and get moving. You can always refine the details in the next iteration of the ADM.

Best Practice 1: Tailor the ADM to Fit Your Organization

TOGAF is not a "one size fits all" framework. The Open Group expects you to customize the ADM. If your company is a fast-moving startup, you don’t need all the formal deliverables. If you are a highly regulated bank, you need more rigor.

The Success Rule: "Just Enough" Architecture

Ask yourself: "What is the minimum amount of architecture we need to achieve our goals?" Anything more than that is a waste of time and money.

Best Practice 2: Focus on Outcomes, Not just Artifacts

Stakeholders don't care about your ArchiMate diagrams. They care about business outcomes: "Will this save us money?" "Will this reduce our time to market?" "Will this keep our data safe?"

The Success Rule: The "So What?" Test

Every diagram you draw and every document you write should pass the "So What?" test. If you can't explain to a non-technical manager why a specific piece of work is important, don't do it.

Best Practice 3: Communication is Your Greatest Tool

Architecture is 20% technical design and 80% communication. You are a salesperson for a future vision. You need to be able to tell a compelling story that makes people want to follow your architecture.

The Success Rule: Translate Your Language

Talk to the CFO about "risk and ROI." Talk to the Developers about "scalability and technical debt." Tailor your message to the audience you are talking to.

Pitfall 3: Treating TOGAF as a Rigid Recipe

TOGAF is a framework, not a prescription. Many architects fail by applying every phase, every deliverable, and every technique in full detail regardless of project context. A fast-moving startup does not need the same governance overhead as a regulated bank.

The Fix: Apply "Just Enough Architecture"

The Open Group explicitly expects organizations to tailor the TOGAF ADM to fit their context. In the Preliminary Phase, explicitly decide which phases, deliverables, and governance checkpoints apply to your organisation’s size, risk profile, and pace. Document what you are leaving out and why. Justified omission is not non-compliance — it is professional judgement.

Pitfall 4: Neglecting Phase G and H

Most EA teams pour energy into design phases (B through D) and produce excellent target architectures. Then they hand the architecture to project teams and move on to the next engagement. Six months later, they discover the implementation bears little resemblance to the design.

The Fix: Stay Engaged Through Delivery

Phase G Implementation Governance exists for exactly this reason. Even light-touch governance — a single compliance review at design sign-off and one at build completion — catches the most common deviations before they become expensive to fix. Schedule these reviews into every project from Phase A onwards, so they are expected rather than contested.

Best Practice 4: Build the Architecture Repository Before You Need It

Organizations that wait until they have a large portfolio of architecture work to set up their Architecture Repository are making the equivalent of trying to file years of paperwork in a single afternoon. The result is a disorganised mess.

The Success Rule: Start Small, Start Now

In the Preliminary Phase, set up the basic structure of the Architecture Repository — even if it is initially a structured folder in SharePoint or Confluence. Establish the naming conventions, the metadata fields, and the governance of who can publish to it. Every architecture asset produced goes in immediately. The Repository becomes more valuable with every engagement it supports.

Best Practice 5: Use Real-World Examples to Build Credibility

Abstract architecture concepts are hard for business stakeholders to evaluate. They cannot tell if a Phase B Business Capability Map is good or just complex-looking. But they can immediately tell if a diagram accurately reflects how their department works.

The Success Rule: Ground Everything in Reality

Validate every model, diagram, and deliverable with the people who live and breathe the area you are modelling. A 30-minute workshop with a business process owner is worth more than three hours of solo modelling. When stakeholders see their own processes and constraints accurately captured, they trust the architecture — and that trust is what makes them follow it.

Summary

The difference between a successful architect and a frustrated one is often not technical skill, but the ability to stay practical, communicative, and value-focused. Avoid the Ivory Tower, don’t get stuck in analysis, and remember that your job is to enable the enterprise to succeed.

The best practices that consistently work in the field:

Tailor the ADM to your organisation’s context rather than applying it rigidly
Focus on business outcomes, not artifact production
Communicate in the language of your audience, not architecture jargon
Stay engaged through Phase G implementation governance, not just design phases
Build the Architecture Repository early and maintain it continuously

This concludes Module 4: Career & Modern EA. We are now ready to enter the final stages of our journey. In Module 5, we’ll move to the ultimate goal for many: TOGAF Certification Mastery — Levels and Exam Strategy.

This post is part of the TOGAF 9.2 Masterclass series. Don’t forget to check out our previous post on TOGAF Real-World Case Studies. For more on the governance approach that prevents these pitfalls, see Architecture Principles and Governance and Phase G and H: Governance and Change Management.

Additional TOGAF Pitfalls to Avoid

Treating governance as the end goal rather than the means Architecture governance exists to ensure that delivery programmes produce outcomes aligned with strategic intent — not to generate compliance documentation. An Architecture Board that measures its success by the volume of reviews completed rather than the quality of architectural outcomes has lost sight of its purpose. Governance should be proportionate: lighter touch for low-risk, commodity implementations; deeper engagement for strategic, cross-organisational decisions.

Producing architecture without stakeholder engagement Architectures developed in isolation and then presented to stakeholders as a fait accompli rarely gain the adoption they deserve. Architecture work requires continuous stakeholder engagement throughout each ADM phase — not a single review at the end. The Stakeholder Map and Communication Plan produced in Phase A should drive structured engagement throughout Phases B, C, and D.

Confusing the current state with the problem The Baseline Architecture documents what exists today. It is not an argument for keeping what exists. Some architects spend disproportionate effort on baseline documentation to the point that the Target Architecture receives insufficient attention. The Baseline is a starting point for Gap Analysis — produce it to the level of detail needed to identify gaps, not to the level of an asset inventory.

Authoritative external references:

TOGAF Standard, 10th Edition — the primary reference for ADM best practices
Open Group TOGAF certification — exam preparation for practitioners

Frequently Asked Questions

What are the most common reasons TOGAF implementations fail in organisations? The most cited failure modes are: lack of executive sponsorship (the architecture function has no mandate to influence investment decisions); over-engineering (producing full ADM deliverable sets for initiatives that do not warrant them); disconnection from delivery (architectures that are never consulted once produced); and governance without value (review processes that slow delivery without improving outcomes). The TOGAF standard's Architecture Governance section addresses each of these directly.

How should TOGAF be tailored for a small organisation? Small organisations should apply the Preliminary Phase guidance on tailoring the ADM explicitly. The key adjustments are: reduce the deliverable set to the minimum needed for governance and communication; combine roles (one person may be the architect, the Architecture Board chair, and the solution designer); shorten phase cycles from months to weeks; and focus governance on decisions with significant strategic or financial impact, not every technical choice. TOGAF is designed to scale — the Preliminary Phase exists precisely to right-size the framework for the context.

Is TOGAF applicable outside of large enterprise IT environments? Yes, but with tailoring. The ADM's core logic — understand the current state, define a target state, identify gaps, plan the transition — applies to any organisation making structured technology investments. Government agencies, mid-size businesses, and non-profits have applied TOGAF successfully by stripping the framework to its essential ADM cycle and a lightweight Architecture Repository. The TOGAF standard explicitly supports this via the Preliminary Phase scoping and tailoring guidance in the official documentation.