FEAF vs TOGAF vs Zachman (and friends): How Enterprise Architecture Methodologies Compare—and How to Combine Them

Enterprise Architecture (EA) methodologies have a reputation problem: they’re either seen as too heavy to ship anything, or too vague to change anything.

The truth is more useful:

• These frameworks aren’t competing “operating systems.”
• They’re different tools for different jobs—taxonomy, governance, modeling, compliance, delivery alignment.

This article compares FEAF, TOGAF, Zachman, and the most common “adjacent” standards (DoDAF/MODAF/NAF, ArchiMate, COBIT/ITIL, SAFe), and then proposes a pragmatic way to combine them.

Executive summary

• FEAF is best understood as a government EA reference model + taxonomy to standardize reporting and cross-agency alignment. It’s stronger on what to classify than how to transform.
• TOGAF is a method (ADM) plus governance concepts. It helps you run an architecture program, but it can become a paperwork factory without strong scoping.
• Zachman is a classification schema (a way to ensure coverage), not a step-by-step method. It’s great for completeness checks, weak for prioritization.
• The winning move is usually a hybrid: choose (1) a method for “how we work” (often TOGAF-lite), (2) a taxonomy for “what we report” (FEAF-like), and (3) a notation for “how we draw” (ArchiMate/C4), then embed it into delivery.

First: what problem are you solving?

A lot of EA pain comes from using a framework for the wrong purpose.

Here are the common EA problem-types:

1. Portfolio alignment: Which capabilities do we have, what are we funding, what gets cut?
2. Standardization: Can different teams talk about the same thing the same way?
3. Target-state design: Where are we heading, and what are the transition steps?
4. Governance: How do we keep solutions coherent without blocking delivery?
5. Compliance / regulated reporting: Can we defend decisions to auditors/regulators?
6. Interoperability: Especially across agencies / business units / vendors.

Different methodologies are optimized for different subsets of the above.

FEAF (Federal Enterprise Architecture Framework)

What it is (in practice)

FEAF is commonly used as a reference framework for US federal agencies to create consistent EA views and map architecture artifacts to shared reference models.

Think: “a shared language and filing system” for architecture across a large federated environment.

What it’s strong at

• Standardized classification of architecture artifacts (useful in big federations)
• Cross-org comparison and reporting
• Encouraging a capability + service view, not just systems

What it’s weak at

• It’s not a highly prescriptive “do this next” transformation method.
• If you treat it as the operating model for delivery, you can end up with compliance artifacts that don’t change real outcomes.

When FEAF is a good fit

• Public sector (or large regulated organizations) where consistent reporting matters
• Multi-agency, multi-division environments where taxonomy is the biggest gap

TOGAF

What it is (in practice)

TOGAF is best known for the Architecture Development Method (ADM): a phased approach (vision → business architecture → information systems → technology → opportunities/migration → implementation governance).

It also brings governance ideas: architecture principles, standards, building blocks, and architecture repositories.

What it’s strong at

• A repeatable method for running an EA practice
• A shared workflow for “architecture work” across business/data/app/tech
• Governance patterns (when done lightly)

What it’s weak at

• Without tight scope, TOGAF becomes “big design up front” with deliverables nobody uses.
• Many orgs copy the ADM phases but skip the hard parts: decisions, tradeoffs, and enforcement.

When TOGAF is a good fit

• You need a process to coordinate architecture across domains.
• You have multiple teams and want consistent “architecture engagement.”

Zachman Framework

What it is (in practice)

Zachman is a 2D schema for describing an enterprise:

• Columns: What / How / Where / Who / When / Why
• Rows: different stakeholder perspectives (executive → architect → engineer → etc.)

It’s a completeness lens.

What it’s strong at

• Preventing blind spots (“we modeled systems, but never modeled ownership and controls”)
• Teaching teams that architecture has multiple viewpoints

What it’s weak at

• It doesn’t tell you what to do next.
• It doesn’t prioritize.

When Zachman is a good fit

• As a quality checklist for EA coverage
• As a teaching tool for multi-view thinking

Defense / government architecture frameworks: DoDAF, MODAF, NAF

These frameworks are optimized for mission and operational interoperability, with standardized viewpoints and artifacts.

What they’re strong at

• Complex systems-of-systems
• Traceability across operational → system → technical views
• Interoperability contracts

What they’re weak at

• They can be overkill for commercial product delivery unless you truly need the rigor.

ArchiMate (not a methodology)

ArchiMate is a modeling language/notation.

That’s important: it answers “how do we draw/model consistently?” not “how do we run the program?”

A common failure mode is expecting ArchiMate to fix governance by itself. It won’t.

The “other majors” you’ll meet in the real world

• COBIT: governance/control objectives; great for audit alignment and IT controls.
• ITIL: service management operating model; helpful for operational maturity.
• SAFe / Agile-at-scale: delivery alignment; useful when architecture must live inside product trains.
• Gartner: more of a practice guidance + maturity model style; widely referenced in exec conversations.

These often shape EA outcomes more than FEAF/TOGAF/Zachman because they directly impact how teams are funded and measured.

A practical comparison (what each gives you)

If you simplify the landscape:

• Taxonomy / reference models: FEAF, Zachman (in different ways)
• Method / lifecycle: TOGAF (ADM)
• Viewpoints for complex interoperability: DoDAF/MODAF/NAF
• Notation: ArchiMate (and sometimes UML/C4)
• Governance/controls: COBIT (and parts of ITIL)
• Delivery integration: SAFe (or your product operating model)

How to combine them without creating a bureaucracy

Here’s the pattern that works in practice:

Step 1) Pick one “how we work” method (TOGAF-lite)

Adopt the idea of ADM, but aggressively scope it:

• Treat architecture as a service with defined entry/exit criteria.
• Produce decisions and guardrails, not giant documents.

Minimum artifacts:

• Architecture principles (short)
• Standards/guardrails (living)
• A few key views per initiative (context, major components, data flows, security boundaries)

Step 2) Use FEAF-like reference models for reporting, not for delivery

If you need cross-org alignment:

• Map initiatives to capabilities and services.
• Use a stable taxonomy so portfolio conversations are coherent.

But keep it decoupled from day-to-day engineering.

Step 3) Use Zachman as a coverage checklist

At design review time, ask:

• Did we cover what/how/where/who/when/why at the level needed?
• Are we missing ownership, timing, controls, or intent?

This prevents surprises without turning into bureaucracy.

Step 4) Choose a diagram language teams will actually use

• If your org is already invested in ArchiMate, use it.
• If not, use a lighter standard (e.g., C4 for software architecture) and keep the “EA” linkage via metadata (capabilities, owners, risk class).

Consistency beats perfection.

Step 5) Make governance real (controls + incentives)

The framework doesn’t enforce anything. Your operating model does.

Practical governance:

• Define “non-negotiables” (identity, logging, data classification, approved patterns)
• Make compliance easy (templates, paved paths)
• Review architecture at the right time (before you’ve built too much, after you’ve learned enough)

Step 6) Close the loop with delivery

EA only works when it changes delivery outcomes:

• architecture decisions are captured (ADR-style)
• standards are referenced in PRDs/epics
• platforms provide paved paths
• metrics exist (lead time, incident rate, security exceptions)

A recommended “stack” for KMS ITC-style consulting work

If I had to pick a default consulting playbook:

• Method: TOGAF principles + a slimmed ADM (“TOGAF-lite”)
• Reporting taxonomy: FEAF-like capability + service map
• Coverage check: Zachman questions in design review
• Modeling notation: C4 for software + a small set of cross-cutting diagrams (data flows, trust boundaries)
• Controls: COBIT-lite mapped to security and operational requirements

That gives you repeatability without forcing clients into a single heavyweight framework.

Risks and tradeoffs

• Too much taxonomy can stall delivery. Keep classification as metadata.
• Too much method can create architecture theater. Keep deliverables tied to decisions.
• Too much modeling can turn diagrams into an end in themselves. Prefer diagrams that answer a question.

Sources / further reading

• FEAF overview and reference models (search: “Federal Enterprise Architecture Framework reference models”)
• TOGAF ADM overview (The Open Group)
• Zachman framework overview
• ArchiMate specification (The Open Group)
• DoDAF viewpoints (for systems-of-systems)

If you’re deciding what to adopt this year, the best next step is to map your biggest pain (portfolio alignment, governance, interoperability, or delivery speed) to the framework components above—then pilot a lightweight version on one initiative.