TOGAF with DoDAF and FEAF

45 min 6 outcomes 0 interactive diagrams 5 standards cited

Comparing TOGAF with the defence and federal enterprise-architecture approaches starts with context, not logos, because each framework was shaped by a different operating environment. Understanding that context is the single most important step in making any framework comparison honest.

By the end of this module you will be able to:

  • Explain why DoDAF, FEAF, and TOGAF cannot be compared honestly without understanding the operating context each was designed for
  • Describe the role of DoDAF and how the viewpoint structure serves defence coordination
  • Explain FEAF's reference-model logic and its role in cross-agency standardisation
  • Identify what a regulated utility can learn from these public-sector approaches without pretending it is a defence or federal agency
  • Apply the TOGAF Standard's own position on framework coexistence to real selection decisions
  • Avoid one-line comparisons that reduce framework choice to slogans

Three-column comparison. Zero context.

Framework comparison slides often line up DoDAF, FEAF, and TOGAF in a three-column table, add a few ticks and crosses, and declare one the winner for "agility" or "rigour." Those slides survive precisely because they are too vague to be wrong.

The moment you ask what operating context each framework was designed for, the ticks and crosses stop meaning very much. DoDAF was shaped by defence coordination and mission assurance requirements across large military organisations. FEAF was shaped by federal government planning and cross-agency standardisation needs. TOGAF was designed as a general standard for broad reuse across sectors.

Those are fundamentally different design constraints. Any comparison that ignores them compares artefact names rather than architectural purpose. An honest comparison starts from that context.

If a framework comparison slide uses ticks and crosses but never mentions the operating context each framework was designed for, how much can you trust it?

60.1 Start with context, not logos

TOGAF is a general enterprise-architecture standard intended for broad reuse across commercial, public-sector, and regulated environments. DoDAF and FEAF emerge from more specific public-sector settings. That single fact explains much of the difference in emphasis, artefact structure, and governance expectations.

When a framework is shaped by mission assurance, cross-agency planning, mandated, or reference-model coordination, its artefact structure will look different from a framework designed for wider enterprise reuse. That is not a quality difference. It is a design choice driven by the problem each framework was built to solve.

Why context determines comparison quality

A comparison that says "TOGAF is more flexible than DoDAF" is meaningless without asking: flexible for whom and in what operating environment? DoDAF's structure is deliberate. Its viewpoint catalogue, conformance expectations, and standardised products exist because defence coordination requires shared understanding across organisations that may never have worked together before.

Similarly, a comparison that says "FEAF is more prescriptive than TOGAF" misses the point that federal agencies need a common vocabulary for cross-agency planning and budget justification. The prescriptiveness serves a coordination function that a general enterprise method does not need to impose.

The right comparison question is not "which is better?" It is "what operating environment was each framework designed to serve, and what does that design choice mean for my enterprise?"

How TOGAF, ArchiMate, BIZBOK and Zachman divide the enterprise architecture work

No single framework covers every need, so practitioners run TOGAF as the method backbone, draw its artefacts in ArchiMate, deepen the business layer with BIZBOK and use Zachman as a completeness check across all six dimensions.

How TOGAF, ArchiMate, BIZBOK and Zachman divide the enterprise architecture work A comparison matrix of four enterprise architecture frameworks. Six dimensions run down a shared left column: scope, method, notation, governance, certification and how each complements TOGAF. TOGAF, ArchiMate, BIZBOK and Zachman are the four columns, so every dimension sits on one eye-line and the reader compares straight across each row. The TOGAF column is accent-tinted as the method backbone running the ADM cycle. ArchiMate is the notation, a formal visual language with 11 relationship types; BIZBOK deepens the business layer; Zachman is a 6x6 completeness taxonomy. Certifications and the ArchiMate count are shown verbatim. DimensionScopeMethodNotationGovernanceCertificationComplements TOGAFTOGAFEA method andgovernanceADM: PreliminaryPhase, Phases A to H,continuousRequirementsManagementNone prescribed;uses ArchiMate or UMLArchitecture Board,compliance reviews,waiversFoundation andPractitioner(Open Group)The method backbonethe others plug intoArchiMateEA modellinglanguageNone; used withinADM phasesFormal visuallanguage: layeredelements, 11relationship typesNone; makesarchitecture visibleFoundation andPractitioner(Open Group)Draws TOGAFartefacts in onenotationBIZBOKBusiness architecturebody of knowledgeCapability, valuestream andinformation mappingCapability maps,value streams,heat mapsBusiness architecturegovernance within EACertified BusinessArchitect (CBA)Fills Phase B withcapability depthZachmanDescriptive taxonomyand ontologyNone; aclassification scheme6x6 matrix ofinterrogatives vsperspectivesNone; acategorisation toolZachman CertifiedEnterprise Architect6x6 completenesscheck on ADMartefacts TOGAF: the method backbone the other three plug into Sources: The Open Group TOGAF and ArchiMate; BIZBOK Guide; Zachman International

60.2 What makes DoDAF distinct

Viewpoint discipline

The official DoDAF site structures the framework around viewpoints and models, including All, Capability, Data and Information, Operational, Project, Services, Standards, and Systems viewpoints. Each viewpoint defines a set of architecture products (models) that serve a specific analytical purpose. This is not arbitrary structure. It reflects the defence requirement for shared understanding across large, dispersed organisations that need to coordinate on mission, capability, and systems without relying on informal communication.

Conformance expectations

The DoD CIO site states that DoD components are expected to conform to DoDAF to the maximum extent possible so architectures, models, and viewpoints can be shared with common understanding. This conformance expectation is stronger than anything TOGAF imposes. TOGAF expects tailoring. DoDAF expects conformance. That difference reflects their different operating contexts: a general enterprise standard versus a defence coordination requirement.

Mission and defence context

DoDAF is especially strong where shared mission views, standardised architecture products, and defence-oriented coordination are central requirements. The Operational Viewpoint, for example, provides architecture products that describe operational activities, nodes, and information exchanges in a way that maps directly to military planning and coordination needs. The Capability Viewpoint describes how capabilities are planned, delivered, and evolved across the defence enterprise.

What practitioners should understand about DoDAF viewpoints

  • All Viewpoint (AV). Provides overarching descriptions of the entire architecture, including scope, context, and summary information.
  • Capability Viewpoint (CV). Describes capability requirements, delivery timelines, and the relationship between capabilities and operational activities.
  • Data and Information Viewpoint (DIV). Describes the data assets, their relationships, and the rules governing data sharing across the enterprise.
  • Operational Viewpoint (OV). Describes the operational activities, nodes, connectivity, and information exchanges needed to accomplish missions.
  • Project Viewpoint (PV). Maps projects and programmes to capabilities and operational requirements.
  • Services Viewpoint (SvcV). Describes the services, their interfaces, and service-level requirements.
  • Standards Viewpoint (StdV). Identifies applicable standards and the rules for their use.
  • Systems Viewpoint (SV). Describes the systems, their composition, connectivity, and information flows.

60.3 What makes FEAF distinct

Business-based federal framing

The Common Approach to Federal Enterprise Architecture describes FEA as a business-based documentation and analysis framework with current views, future views, and a transition plan. This framing is significant because it positions enterprise architecture explicitly as a tool for government planning and investment justification rather than as a technical discipline.

Reference-model logic

FEAF v2 centres strongly on the Consolidated Reference Model (CRM) and linked reference models as a way to standardise categorisation, reuse, and cross-agency analysis. The reference models include:

  • Performance Reference Model (PRM). Provides a common framework for measuring the performance of federal investments.
  • Business Reference Model (BRM). Describes the federal government's lines of business and sub-functions to facilitate cross-agency analysis.
  • Data Reference Model (DRM). Provides a standard means of categorising data to enable information sharing and reuse.
  • Application Reference Model (ARM). Categorises the components of application systems to identify opportunities for reuse and sharing.
  • Infrastructure Reference Model (IRM). Categorises infrastructure elements to support cross-agency analysis of technology investments.
  • Security Reference Model (SRM). Provides a common vocabulary for security-related concerns across the federal enterprise.

Government-wide coordination

FEAF is designed for federal planning and coordination problems, not simply for architecture inside one isolated organisation. The reference models exist because federal agencies need to compare, consolidate, and coordinate investments across organisational boundaries. That is a fundamentally different problem from running enterprise architecture inside a single commercial organisation.

Maintenance context

It is important to be honest about FEAF's current status. The FEAF sources used in this module are official federal materials, but they are archival public-sector references rather than a fast-moving current commercial framework. That context matters when assessing how actively the framework is being maintained and evolved. FEAF remains a legitimate reference for the principles of reference-model-driven enterprise architecture, but practitioners should understand its maintenance context.

60.4 Where TOGAF differs

TOGAF occupies a different position in the framework landscape. Understanding that position requires comparing it against what DoDAF and FEAF each prioritise.

General-purpose enterprise method

TOGAF gives a general method for developing, governing, tailoring, and sequencing across sectors. The provides phases from preliminary framing through , , , opportunities and solutions, migration planning, implementation , and change management. This end-to-end method is more explicit and more broadly reusable than what either DoDAF or FEAF provides.

Tailoring as a core principle

TOGAF explicitly expects tailoring. The standard provides the full method but assumes that practitioners will adapt it to their enterprise context. DoDAF expects conformance. FEAF operates through mandated reference models. TOGAF operates through guided adaptation. This makes TOGAF more flexible but also means it depends more heavily on practitioner judgement to produce useful results.

What TOGAF does not impose

  • TOGAF does not require a defence-specific catalogue in the way DoDAF does. It provides viewpoint guidance but does not mandate a fixed set of architecture products.
  • TOGAF does not place the same central weight on federal reference models and cross-agency categorisation that FEAF does. It supports through the but does not require a mandated reference-model taxonomy.
  • TOGAF is therefore more reusable across sectors but also less opinionated about certain public-sector architecture structures that DoDAF and FEAF provide.

Governance and repository

TOGAF provides explicit governance guidance including structures, reviews, , and stewardship. DoDAF provides conformance expectations and product standards. FEAF provides reference-model coordination. Each approach to governance reflects the operating context the framework was designed to serve.

The same four architecture concerns across TOGAF, DODAF and FEAF

DODAF and FEAF answer the same four concerns as TOGAF but ship a different artefact for each, so mapping a concern across the row reuses work only once you declare which equivalence is exact and which is partial.

The same four architecture concerns across TOGAF, DODAF and FEAF A comparison grid grouped by concern. Three framework headers run across the top: TOGAF from the Open Group as the accent-tinted reference column, then DODAF and FEAF. Four row groups follow; each opens with a full-width concern strip, then three cells name the equivalent artefact. Stakeholders and context: stakeholder map, OV-1 and OV-2, BRM stakeholders. Capability: capability map, CV-2, BRM mission sectors. Application and interface: application portfolio, SV-1 and SV-3, ARM applications. Technology and standards: technology architecture, StdV-1 and StdV-2 (the standards profile and forecast), and the FEAF IRM, its infrastructure reference model. TOGAFOpen GroupDODAFUS DoDFEAFUS federal Stakeholders and contextWho matters, and the picture they shareStakeholder mapPhase A artefactOV-1, OV-2Operational contextBRM stakeholdersBusiness reference model CapabilityWhat the organisation must be able to doCapability mapPhase B artefactCV-2Capability taxonomyBRM mission sectorsFunctional taxonomy Application and interfaceWhat software exists and how it connectsApplication portfolioPhase C artefactSV-1, SV-3System interfacesARM applicationsApplication reference model Technology and standardsWhat it runs on and the rules it followsTechnology architecturePhase D artefactStdV-1, StdV-2Standards profileand forecastIRMInfrastructurereference model

60.5 The TOGAF Standard's position on framework coexistence

The TOGAF Standard addresses the question of how TOGAF relates to other architecture frameworks directly. The Introduction and Core Concepts volume of the 10th Edition includes a section called Using the TOGAF Standard with Other Frameworks, which gives The Open Group's own perspective on framework coexistence and is directly relevant to the DoDAF and FEAF comparison.

The key principle is that TOGAF does not claim to be the only valid enterprise-architecture approach. The standard states that its deliverables may be replaced or extended by a more specific set defined in any other framework the architect considers relevant, and it expects tailoring to integrate the methods and frameworks an enterprise already uses.

For practitioners, this position provides a more mature starting point than the typical "pick one" comparison. It recognises that framework selection is a design decision shaped by enterprise context, regulatory requirements, and existing organisational commitments rather than an absolute quality ranking.

60.6 What a regulated utility can borrow

A UK energy distributor is not a defence command and not a US federal agency. But it does operate in a regulated environment with multiple , external interfaces, mandated reporting obligations, and a need for clearer taxonomy and evidence. That means some ideas from DoDAF and FEAF are transferable, provided they are borrowed with understanding rather than copied mechanically.

From DoDAF: viewpoint discipline

The principle of structured viewpoints is transferable to any environment where different stakeholders need different perspectives on the same architecture. A regulated utility needs operational views, technology views, regulatory compliance views, and investment views. The discipline of defining these viewpoints explicitly, rather than producing ad hoc diagrams, comes directly from DoDAF-style thinking.

What should not be copied is the specific DoDAF viewpoint catalogue. The Operational Viewpoint products are designed for military operations. The Systems Viewpoint products assume defence systems integration patterns. The discipline is transferable. The specific catalogue is not.

From FEAF: reference-model thinking

The principle of standardised categorisation for reuse and consistency is transferable to any environment where multiple parties need a shared vocabulary. A regulated utility that works with the regulator, system operators, other network companies, and government bodies benefits from having a common taxonomy for business functions, data categories, and technology infrastructure.

What should not be copied is the specific FEAF reference-model content. The Business Reference Model describes US federal lines of business. The Data Reference Model categorises federal data. The principle of reference-model coordination is transferable. The specific federal categorisation is not.

Practical borrowing principles

  1. Borrow DoDAF-style viewpoint discipline when a single narrative is not enough for all stakeholders.
  2. Borrow FEAF-style reference-model thinking when taxonomy and cross-organisation consistency matter more than bespoke local language.
  3. Keep TOGAF as the core method if the enterprise still needs a broader architecture-development and governance backbone.
  4. Do not imitate defence or federal patterns mechanically if the enterprise context does not justify them.
  5. Test every borrowed concept against the question: does this serve a real coordination or quality need in my enterprise, or am I cargo-culting another sector's structure?

Common misconception

“DoDAF or FEAF should be adopted wholesale by a UK energy distributor.”

The worst outcome is cargo-cult borrowing: copying artefact names and structures from a defence or federal framework without understanding why those structures exist in their native context. Borrow the discipline selectively; do not inherit the context. A regulated utility benefits from viewpoint discipline and reference-model thinking, not from defence-specific products or federal categorisation schemes.

Which framework owns each sector and mandate-weight quadrant

Sector and mandate weight pick the framework. DoD policy drives DODAF for heavy public mandates; elsewhere the right choice matches the method to the authority behind it.

Which framework owns each sector and mandate-weight quadrant A two-by-two matrix of framework tailoring on two blue axis rails: a vertical Sector rail, private to public, and a horizontal Mandate weight rail, light to heavy. Each quadrant names the framework that fits, with a green marker for its strength and an amber marker for its cost. Private plus light is TOGAF tailored down, a practical subset or no framework. Private plus heavy is the full TOGAF ADM plus a regulator overlay. Public plus light is the FEAF reference models for civil agencies. Public plus heavy, the one accent-tinted quadrant, is DODAF: DoD policy mandates conformance, processes such as JCIDS fix the view sets, and DODAF 2.02 itself stays fit-for-purpose. Sector: private to public Mandate weight: light to heavy Public, light mandate FEAF reference models Shared models for civil agencies Lighter compliance, less rigour Public, heavy mandate DODAF Fit-for-purpose defence views DoD processes fix view sets Private, light mandate TOGAF tailored down Practical subset, or no framework Little assurance to show Private, heavy mandate TOGAF, full ADM Full method plus regulator overlay Heavier governance effort What makes the framework fitWhat it costs

London Grid Distribution

London Grid Distribution is not a defence command and not a US federal agency, but it does operate in a regulated environment with multiple stakeholders, external interfaces, and a need for clearer taxonomy and evidence. That means London can borrow from DoDAF and FEAF selectively.

Viewpoint discipline for London

London already produces architecture for different audiences: regulatory compliance views for Ofgem, technology architecture views for infrastructure decisions, business architecture views for capability planning, and investment views for capital allocation. DoDAF-style viewpoint discipline would make this more explicit by defining each viewpoint formally, specifying its purpose, audience, and required content.

Reference-model thinking for London

London operates in an ecosystem where common vocabulary matters: regulatory submissions, data publication obligations under the Energy Digitalisation Framework, coordination with the National Energy System Operator (NESO), and alignment with other distribution network operators. FEAF-style reference-model thinking would help London maintain consistent categorisation of business functions, , and technology components across these external interfaces.

What London still needs most

What London still needs most, though, is TOGAF's more generally reusable method for architecture development, , and governance. The provides the end-to-end process backbone. The structures the. The governance framework defines decision rights, compliance reviews, and exception handling. Those capabilities are what hold the London architecture together as an operating practice.

  • London benefits from the borrowed strengths of DoDAF (viewpoint discipline) and FEAF (reference-model thinking) without pretending to inherit their native context.
  • The right comparison question is not who wins. It is what each framework was designed to optimise and what London can borrow with understanding.
Check your understanding

An architecture team proposes adopting DoDAF viewpoints wholesale for a UK energy distributor. What is the most important concern?

What is the most honest way to summarise the three-way comparison between TOGAF, DoDAF, and FEAF?

A colleague claims FEAF's reference-model approach has no value outside the US federal government. How would you respond?

The TOGAF Standard's Introduction and Core Concepts volume addresses using TOGAF with other frameworks. What is its most important practical contribution to this comparison?

Core distinctions

  • DoDAF, FEAF, and TOGAF were shaped by different operating contexts. Honest comparison starts with that context, not with ticks and crosses.
  • DoDAF is strong on viewpoint discipline and formal sharing expectations in defence settings. The discipline of structured viewpoints is transferable; the specific catalogue is not.
  • FEAF emphasises business-based federal planning, current and future views, transition planning, and reference models. The principle of reference-model coordination is transferable; the specific federal content is not.
  • TOGAF remains the more generally reusable enterprise method, especially outside those specific public-sector contexts, because it provides an end-to-end development method with explicit tailoring, governance, and migration guidance.
  • The TOGAF Standard's Introduction and Core Concepts volume gives The Open Group's own perspective on framework coexistence, supporting a mature approach to working with multiple frameworks.
  • For the London case, borrowing viewpoint discipline and reference-model thinking strengthens the architecture practice without requiring wholesale adoption of defence or federal structures.

Standards and sources cited in this module

  1. DoD Architecture Framework

    Official DoDAF landing page from the DoD CIO

    Primary reference for DoDAF viewpoints and conformance expectations.

  2. Federal Enterprise Architecture resources

    Official archived federal enterprise architecture landing page

    Primary reference for FEA scope and reference-model structure.

  3. Common Approach to Federal Enterprise Architecture

    Official archived PDF

    Describes FEA as a business-based documentation and analysis framework.

  4. Federal Enterprise Architecture Framework Version 2

    Official archived FEA v2 PDF

    Centres on the Consolidated Reference Model and linked reference models.

  5. The TOGAF Standard, 10th Edition

    Introduction and Core Concepts, Section 3.15: Using the TOGAF Standard with Other Frameworks

    The core standard compared in this module, and the source of The Open Group's position on framework coexistence.

You now understand why DoDAF, FEAF, and TOGAF differ and what a regulated utility can borrow selectively from each. The next comparison is with Zachman, where the question shifts from operating context to conceptual level: schema versus method. That is Module 61.

Back to Module 59Next: TOGAF with Zachman

Module 60 of 72 · Comparison and Capstone