Enterprise Architecture Frameworks (TOGAF, Zachman)

An EA framework isn’t the architecture itself — it’s a shared method and vocabulary for doing architecture work consistently.

At a glance

• What it is: A shared method (TOGAF) or classification system (Zachman) for producing and organizing architecture artifacts.
• Why it matters: Without a shared framework, artifacts aren’t comparable across teams and knowledge doesn’t transfer when people move between projects.
• For developers: you’ll rarely run the ADM yourself, but recognizing its phase names — Business, Information Systems (Data/Application), Technology — helps you tell which phase a design review request is actually asking about.
• When to use it: Setting up or maturing an EA practice, or leading a transformation initiative.
• When not to use it: For a single small project where a lightweight, ad-hoc approach is faster and the overhead isn’t justified.
• Prerequisites: The Four Architecture Domains (BDAT).

Mental model

graph LR
    V[Architecture Vision] --> BA[Business Architecture]
    BA --> ISA["Information Systems Architecture<br/>(Data + Application)"]
    ISA --> TA[Technology Architecture]
    TA --> OPP[Opportunities & Solutions]
    OPP --> MP[Migration Planning]
    MP --> IG[Implementation Governance]
    IG --> ACM[Architecture Change Management]
    ACM --> V

TOGAF’s ADM (Architecture Development Method) is a repeating cycle through these phases. Zachman, by contrast, isn’t a cycle at all — it’s a matrix cross-referencing perspectives (what, how, where, who, when, why) against stakeholder viewpoints, used to check nothing was left undocumented. ArchiMate is a third, complementary standard: neither a process nor a checklist, it’s an open modeling notation — maintained by The Open Group alongside TOGAF — with dedicated symbols for Business, Application, and Technology layer elements and the relationships between them. TOGAF and Zachman say what to produce; ArchiMate gives architects a common visual language to actually draw it in.

Step-by-step walkthrough

1. Decide whether you need a process (guiding a transformation end to end) or a completeness check (making sure nothing about an architecture is undocumented).
2. Adopt TOGAF’s ADM as the primary method if you’re leading a change/transformation initiative.
3. Use the Zachman matrix as a complementary checklist alongside another method, or standalone for an audit.
4. Tailor phases — not every initiative needs every ADM phase in full depth.
5. Document consistently, using the same templates and vocabulary across architects, so artifacts and knowledge transfer between projects.

Worked example

A company migrating its core systems to the cloud:

• Vision: define the scope and business case for the migration.
• Business/Data/Application/Technology Architecture: work through each BDAT domain for the target state.
• Opportunities & Solutions / Migration Planning: identify workstreams and sequence them.
• Implementation Governance: track delivery against the architecture.
• Architecture Change Management: handle changes to the plan as the migration proceeds — feeding back into the next cycle.

Common use cases

Use case	Better fit	Why
Leading a transformation initiative end to end	TOGAF ADM	Its process-driven cycle guides each phase from vision to governance
Auditing whether an architecture is fully documented	Zachman	Its matrix checks every perspective against every stakeholder viewpoint
Both, on a mature EA practice	TOGAF as primary + Zachman as checklist	Common combination once a practice is established
Diagramming a target architecture for a design review	ArchiMate	Gives reviewers a standard notation they already recognize, instead of ad-hoc boxes and arrows

Advanced details

• Official phase names: Preliminary, then A (Architecture Vision), B (Business Architecture), C (Information Systems Architecture — Data + Application), D (Technology Architecture), E (Opportunities & Solutions), F (Migration Planning), G (Implementation Governance), H (Architecture Change Management) — with Requirements Management at the center, feeding every phase.
• ArchiMate layers: Business (processes, actors, services as the business sees them), Application (software components and services), and Technology (infrastructure) — deliberately mirroring TOGAF’s Business/Data+Application/Technology ADM phases, plus Motivation (drivers, goals, requirements) and Implementation & Migration extensions that map onto TOGAF’s later phases.
• Frameworks dictate the process and format, not the answer — two organizations using TOGAF can still reach very different target architectures.
• ADM phases are often tailored for agile delivery — run as lighter, faster passes rather than a single heavyweight cycle.
• Organizations frequently adopt one framework as primary and borrow artifacts or terminology from the other rather than treating them as mutually exclusive.

Quick reference

	TOGAF	Zachman	ArchiMate
Nature	A process (the ADM cycle)	A classification matrix	A modeling notation
Best for	Guiding a change/transformation initiative end to end	Ensuring completeness — checking nothing was missed	Drawing artifacts in a shared visual language
Typical use	Primary methodology for an EA practice	Complementary checklist alongside another method	Diagramming notation for TOGAF or Zachman artifacts

Troubleshooting

Symptom	Likely cause	Fix
Every architect documents things differently	No shared framework adopted	Standardize on TOGAF’s ADM templates and vocabulary
Confident an architecture is complete, but gaps keep surfacing later	No completeness check was applied	Run the artifact set through the Zachman matrix before sign-off

Check your understanding

• Why is TOGAF described as process-driven and Zachman as classification-driven?
• Why is ArchiMate described as neither a process nor a checklist, and how does that make it compatible with both TOGAF and Zachman?
• For a project you know, would you reach for TOGAF, Zachman, ArchiMate, or some combination — and why?

Related pages

Part of Introduction to Enterprise Architecture. See The Four Architecture Domains for the BDAT structure that TOGAF’s ADM walks through, Architecture Governance for how frameworks connect to review and decision rights, and the Glossary for term definitions.