Enterprise Architecture Frameworks: What Each One Is Actually For

Key Takeaways

• TOGAF is a process (the Architecture Development Method); Zachman is a classification scheme for artifacts. They solve different problems and are commonly used together, not as alternatives.
• FEA and DoDAF were built for government accountability and mission assurance respectively; both have been adapted by private-sector organizations in regulated industries, but neither was designed for speed.
• BIZBOK, from the Business Architecture Guild, is the standard reference specifically for business capability modeling and value streams — it does not cover technology or data architecture.
• SABSA addresses security architecture through a risk-driven lens that general frameworks treat only superficially.
• The framework that fails fastest is the one adopted at full scale before a pilot proves it fits the organization's size and governance appetite.
• Combining frameworks works when governance is explicit about which framework governs which decision — combining them without that clarity produces conflicting guidance.

What Kind of Problem Each Framework Category Solves

Before comparing individual frameworks, it helps to separate them by what they're actually built to do.

Full-scope frameworks — TOGAF and FEA are the clearest examples — try to cover the entire span from business strategy down to technology implementation, with a defined process for getting from current state to target state. They're built for large, complex organizations where consistency across many teams and projects matters more than speed for any one team. Domain-specific frameworks go the other direction: they go deep on one slice — business architecture (BIZBOK), security (SABSA), defense systems (DoDAF) — and say almost nothing about the rest. Modeling languages like ArchiMate and BPMN aren't methods at all; they're notations for drawing what a method like TOGAF tells you to produce. Mistaking a modeling language for a framework, or a domain-specific framework for a full-scope one, is the most common framework-selection error — each solves a narrower problem than its reputation suggests.

• Full-scope frameworks: TOGAF, FEA — end-to-end process across business, data, application, technology
• Classification frameworks: Zachman — organizes artifacts by perspective and question, prescribes no process
• Domain-specific frameworks: BIZBOK (business), SABSA (security), DoDAF (defense)
• Modeling languages: ArchiMate, UML, BPMN — notation for diagrams, not a method on their own

TOGAF: A Process, Not Just a Standard

TOGAF's Architecture Development Method (ADM) is a defined sequence of phases for building and governing an enterprise architecture across four domains: Business, Data, Application, and Technology.

The Open Group maintains TOGAF and updates it periodically; its value is in the ADM's phase structure, which forces an architecture effort to move from a business case and vision, through baseline and target architectures for each domain, to an opportunities-and-migration plan and ongoing governance — rather than jumping straight to technology decisions. That structure, plus TOGAF's vendor-neutral stance, is why it's become the framework most large enterprises reference even when they don't follow it phase-by-phase. The same comprehensiveness is TOGAF's practical weakness. Run at full scale, the ADM's documentation and governance requirements are heavier than a mid-size IT organization can sustain, and teams that adopt it wholesale often produce architecture artifacts that satisfy the method without changing how decisions get made. The organizations that get value from TOGAF tend to run a subset of ADM phases relevant to their current problem — say, business and application architecture for a portfolio rationalization effort — rather than instantiating the full method on day one.

The Zachman Framework: Organizing Artifacts, Not Prescribing a Process

Zachman doesn't tell you how to build an architecture — it tells you how to classify what you've already built, or still need to.

The framework arranges architectural artifacts in a matrix: six rows representing perspectives (from Planner down to the working Enterprise itself) crossed with six columns representing fundamental questions — What, How, Where, Who, When, and Why. Each of the resulting cells represents a distinct kind of artifact — a data model answers "what" from the designer's perspective, differently than an inventory of business objects answers "what" from the planner's perspective. Because it's a classification scheme rather than a sequence of steps, Zachman doesn't compete directly with TOGAF — many practices use Zachman's matrix to check completeness (have we produced something for each relevant cell?) while following TOGAF's ADM to actually produce those artifacts. Its weakness is the flip side of its strength: the matrix tells you what kinds of artifacts should exist, not how urgently, in what order, or with what level of detail, which is why it's rarely used as a practice's only framework.

• Six perspectives, from Planner (scope) through to the working Enterprise itself
• Six questions per perspective: What, How, Where, Who, When, Why
• 36 cells, each representing a distinct class of artifact
• Technology-agnostic by design — the matrix hasn't needed revision as tools have changed

FEA and DoDAF: Frameworks Built for Government Accountability

The Federal Enterprise Architecture and the Department of Defense Architecture Framework were built to solve public-sector problems — cross-agency consistency and mission-critical interoperability, respectively.

FEA organizes federal agency architecture through reference models covering performance, business, service components, technical standards, and data — built to let oversight bodies compare architecture and spending across agencies that would otherwise use incompatible terminology. DoDAF takes a narrower, more technical focus: it's built for describing complex, mission-critical systems where interoperability and security constraints are non-negotiable, and it's correspondingly heavier and more formal than most commercial contexts need. Both frameworks have been adapted outside government, mostly by large organizations in regulated industries that already have to produce compliance-oriented documentation and found FEA's reference-model structure useful for that purpose. Neither was designed with speed in mind, and adopting either without stripping down the reporting requirements to what a commercial governance function actually needs tends to import bureaucracy without importing the accountability it was built to create.

BIZBOK and SABSA: Filling the Gaps General Frameworks Leave Open

Neither TOGAF nor Zachman goes deep on business capability modeling or security architecture as a first-class discipline — BIZBOK and SABSA exist to cover exactly that.

BIZBOK, the Business Architecture Body of Knowledge maintained by the Business Architecture Guild, is the standard reference for business capability mapping, value stream analysis, and connecting strategy to execution in business terms rather than IT terms. It's the framework most business architects reach for specifically because TOGAF's business architecture phase is comparatively thin — a few pages of guidance next to the depth TOGAF gives application and technology architecture. SABSA (Sherwood Applied Business Security Architecture) does the same thing for security: a risk-driven method that ties security controls back to business attributes and risk appetite, rather than treating security as a technology layer bolted on at the end. Industry-specific frameworks — the Purdue Enterprise Reference Architecture for manufacturing and process control, or the enhanced Telecom Operations Map for telecom operators — serve the same purpose at an even narrower scope: pre-built models for a specific industry's recurring architecture problems.

• BIZBOK: capability modeling, value streams, strategy-to-execution mapping
• SABSA: risk-driven security architecture, tied to business attributes
• PERA: manufacturing and process control reference models
• eTOM: telecom operations and business process reference models

Choosing and Combining Frameworks Without the Guesswork

Framework selection works better as a function of organizational context than as a search for the single best option.

Size and complexity are the first filter: a large enterprise with a diverse application portfolio and multiple business units has more to gain from TOGAF or FEA's structure than a fifty-person company, where a lightweight, capability-focused approach (borrowing from BIZBOK without the full comprehensive-framework overhead) usually fits better. Industry context is the second filter — regulated industries need the governance and compliance rigor comprehensive frameworks provide; product and technology companies more often need a framework that doesn't slow down iteration. Combining frameworks is standard practice, not a compromise: TOGAF for the overall method with ArchiMate for modeling and visualization is one common pairing; Zachman's classification alongside TOGAF's process is another; SABSA layered onto a general framework where security risk is a first-order concern is a third. What makes a combination work is explicit governance about which framework governs which decision — without that, teams get conflicting guidance from two frameworks that were never designed to defer to each other.

• TOGAF + ArchiMate: process plus a shared modeling notation
• Zachman + TOGAF: artifact classification plus a build process
• TOGAF + SABSA: general architecture with security treated as first-order, not bolted on
• BIZBOK + TOGAF: business capability depth plus technical implementation guidance

Frequently Asked Questions

Q: Is TOGAF still the industry standard in 2026? A: It remains the most widely referenced comprehensive framework, largely because of The Open Group's ongoing maintenance and its vendor-neutral positioning, but most practices use it selectively rather than end-to-end. Q: Do I need Zachman if I'm already using TOGAF? A: Not necessarily. Zachman is most useful as a completeness check — a way to confirm no perspective or question has been skipped — and some practices apply that thinking informally without adopting the full matrix as a separate deliverable. Q: Is BIZBOK a replacement for TOGAF's business architecture phase? A: For organizations that need deep business capability and value stream work, BIZBOK provides guidance TOGAF's business architecture phase doesn't go into. Many practices use both: TOGAF for the overall method, BIZBOK for the business architecture content within it. Q: Can a small company skip frameworks entirely? A: The formal frameworks scale down poorly, but the underlying discipline — a current-state view, a target state, a sequenced plan, some documented standards — is worth doing at any size, even without a named framework attached. Q: How do I know if a framework is being followed correctly versus just referenced? A: Check whether the framework's artifacts are cited in actual decisions — a project scoping document, a technology selection, a governance review. A framework that only appears in a slide about "our EA approach" isn't being followed; it's being cited.

Pro Tips

• Pilot any comprehensive framework on one initiative using only the phases that initiative needs, before deciding whether to scale it across the practice.
• Use Zachman's questions (What, How, Where, Who, When, Why) as a completeness checklist even if you never build the full matrix as a formal deliverable.
• When combining frameworks, write down explicitly which framework governs which type of decision — that's what prevents architects from getting conflicting guidance from two methods at once.
• Match framework weight to governance appetite, not to organization size alone — a large but fast-moving company may need less process rigor than its headcount suggests.