TOGAF vs Zachman: Which EA Framework Do You Need?

Q: What is the difference between TOGAF and Zachman?

They belong to different categories, which is why comparing them feature-by-feature misleads. The Zachman Framework is an ontology: a 6x6 classification grid whose columns ask the six primitive questions (what, how, where, who, when, why) and whose rows descend through perspectives from executive to running system, giving 36 cells into which any architectural artifact can be classified. It prescribes no process, no deliverables, no governance — John Zachman himself insists it is a schema, not a methodology. TOGAF is the opposite: a method-centric body of knowledge whose core, the Architecture Development Method, walks nine phases from capability setup through vision, business, data, application, and technology architectures, into migration planning, implementation governance, and change management, supported by an extensive catalog of deliverable templates and a governance model. In practice they compose rather than compete: organizations run something TOGAF-shaped (usually heavily slimmed) as their operating process and pull out the Zachman grid as a completeness checklist when they want to know what a plan has forgotten to describe. If your question is which certification to pursue, the market has answered — enterprise job descriptions name TOGAF. If your question is how to make architecture decisions well, the answer is a subset of either plus lighter tools (C4, arc42, ADRs) neither framework includes.

Q: Is TOGAF certification worth it in 2026?

As a credential, yes in specific markets; as a capability, no on its own. The credential case: large enterprises, consultancies, and public-sector procurement in many regions still filter architect roles on TOGAF certification, and the exam cost plus study time is modest against the salary bands it unlocks — for consultants who must walk into regulated clients, it functions as a license plate. The capability case is where honesty is owed: the certification teaches TOGAF's vocabulary, artifact names, and the ADM's phase structure; it does not teach the judgment that makes architects valuable — when to say no to a $2 million platform bet, how to time-box a target state before it becomes fiction, how to smell a distributed monolith in a diagram. We have met freshly certified architects who could name all nine ADM phases and could not review a system design, and uncertified engineers who ran excellent architecture functions. The practical guidance: pursue the certification when your market segment demands it on paper (enterprise employment, consulting, government tenders) and treat it as vocabulary acquisition; build actual capability through reps — writing ADRs, running design reviews, owning a portfolio — because no exam covers the only skill that matters, which is improving real decisions under real constraints.

Q: What is the TOGAF ADM and which phases actually matter?

The Architecture Development Method is TOGAF's core: a cycle of nine phases plus a central requirements-management function. Preliminary establishes the architecture capability itself; Phase A produces the architecture vision and stakeholder buy-in; Phases B, C, and D develop the business, information-systems (data and application), and technology architectures, each as current state, target state, and gap; Phase E consolidates gaps into candidate work packages; Phase F turns them into a migration roadmap; Phase G governs implementation against the architecture; Phase H manages change and feeds the next cycle. Which phases earn their keep in a right-sized practice: A through D compressed hard — a vision and gap analysis in two to six weeks per initiative, not two quarters — plus F, because a roadmap with sequencing and dependencies is the deliverable executives actually use. Phase G matters if embedded in delivery (architects in design reviews) and degenerates into theatre if implemented as a monthly review board. The Preliminary phase's honest content for most orgs is one page: who decides, who advises, where decisions get written down. What to skip: the full deliverable catalog (pick five artifacts, not forty) and any attempt to complete a full-enterprise current state before delivering value — initiative-scoped slices keep the work attached to decisions someone is actually making.

Q: What is the Zachman Framework actually used for?

Its highest-value modern use is the one it was designed for in 1987: a completeness check. The grid crosses six interrogatives (what, how, where, who, when, why) with perspectives descending from executive to operational, and any serious plan — a migration, a platform bet, a target architecture — can be audited against it in about an hour: walk the columns and ask which cells the plan silently assumes. The chronic findings are consistent across engagements: gorgeous data and application models (the what and how at architect level) with nothing credible in who (operating model, skills, on-call ownership), when (sequencing, cutover windows, coexistence periods), or why at the top row (the business motivation that survives contact with a CFO). Ten minutes per empty cell either fills it or names a risk. What Zachman is not usefully used for: as a work plan. Attempting to populate all 36 cells produces an artifact-manufacturing program with no natural end — we have seen repositories with hundreds of documents mapped to the grid and zero decisions traceable to any of them. The grid also carries no notion of iteration, delivery, or governance, so it cannot run an architecture function alone; it is a lens you pick up, apply to something that matters, and put down.

Q: Do startups and scale-ups need an enterprise architecture framework?

No — and adopting one early is actively harmful, because ceremony calibrated for 500-application estates suffocates a 5-application company. What a startup needs from day one costs almost nothing: architecture decision records for every significant choice (a 30-minute write-up of context, options, decision, and consequences — the difference between institutional memory and re-litigating the database choice annually), one C4 system-context diagram per product kept current because it is small enough to keep current, and a named owner for the growing list of systems and vendors. That is the whole stack until real forcing functions arrive. The signals that justify graduating toward heavier practice: the first serious compliance obligation (SOC 2, ISO 27001, sector regulation) which demands inventories and documented control over change; headcount past the point where any one person holds the system in their head (typically 50-plus engineers); M&A activity in either direction, where portfolio artifacts suddenly have due-diligence value; and multi-year platform bets whose reversal cost is existential. Even then, graduate incrementally — add a slim vision-gap-roadmap loop per major initiative and a portfolio with owners and lifecycle, not a framework adoption program. The failure mode we see in scale-ups is buying the enterprise costume before the enterprise problems: an EA wiki nobody reads at 60 engineers is a leading indicator of process theater to come.

Q: What are the modern alternatives to TOGAF and Zachman?

Not replacements for an architecture capability, but replacements for the communication and memory layers the big frameworks do badly. The C4 model gives four zoom levels for software diagrams — system context, containers, components, code — with the crucial property that it stops: engineers keep C4 diagrams current because the notation is small and the levels are few, where enterprise meta-models die of their own weight. arc42 provides a pragmatic twelve-section documentation template for when a system owes the world a fuller document (quality goals, constraints, decisions, risks), widely used in Europe and comfortable alongside C4. Architecture decision records capture the why of each significant choice in half a page while context is fresh; the ADR habit is the single highest-leverage practice on this list, because rationale is the artifact whose loss costs most. Around those, lightweight portfolio management (a maintained list of systems with owners, lifecycle stage, spend, and now models and agents) covers the enterprise-visibility need that made TOGAF attractive. What none of these provide is the process spine — vision, gap, roadmap, governance — which is why the pragmatic stack pairs them with a radically slimmed ADM loop rather than pretending diagrams and decision logs alone will steer a platform strategy. The selection rule: adopt the lightest tool that makes the next decision better, and resist any tool whose maintenance exceeds its decision value.

Q: How does AI change enterprise architecture?

It adds a class of first-order citizens the classical frameworks never imagined, and it raises the price of the museum-repository failure mode. Concretely, the architecture repository now must answer questions boards and auditors are already asking: which models and agents exist in production, what data does each touch (training and inference), who owns each one's behaviour and its failure modes, what its per-call and per-month costs are, and which business capabilities silently depend on a vendor's model deprecation schedule. That model-and-agent inventory belongs in the application portfolio with the same ownership and lifecycle metadata as any system — and it is already a standing request in SOC 2 scoping for AI workloads, so EA and compliance converge on the same artifact. Governance changes shape too: an agent that takes actions is an architectural component whose blast radius needs documenting the way an integration's would be, and policy (who may deploy what model against what data) needs enforcement points in the platform, not paragraphs in a review-board deck. Neither TOGAF nor Zachman has meaningfully absorbed this yet; the practical move is extending your portfolio schema now rather than waiting for framework editions to catch up. The organizations doing this well typically house the inventory with an AI center of excellence or platform team and treat EA as its consumer, which keeps the data live — the one property that makes any of it worth having.

Q: What makes an Architecture Review Board useful instead of theatre?

The distinguishing variable is where the board sits relative to the work. Theatre version: a monthly meeting, slide decks summarizing designs that delivery teams finished weeks ago, approval as ritual, and rejection so costly to the schedule that it never happens — the board reviews fiction and everyone attending knows it. Useful version: architects embedded in the design reviews where systems are actually shaped, with the board reserved for genuinely cross-cutting calls — platform bets, build-versus-buy above a spend threshold, exceptions to paved-road standards — decided against written criteria with written rationale (an ADR per decision, published). The operational details that keep it honest: decision latency measured and reported (a board that takes six weeks to say yes is a tax every project prices in and routes around); a default-permit posture where teams following paved roads never appear before the board at all, so its docket is exceptions, not everything; rotating practitioner membership so the reviewing and the building are done by overlapping humans; and a standing rule that any decision without a named owner and a revisit date is not a decision, it is a hope. The metric we ask boards to produce in audits is simple and usually devastating: list the decisions from the last quarter that changed an outcome, with evidence. Boards that can answer are worth their cost; boards that answer with attendance statistics are theatre with a calendar invite.