TOGAF with DoDAF and FEAF

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, mandatedviewpoints, 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?"

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.

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.

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 sequencingenterprise architecture across sectors. The ADM provides phases from preliminary framing through business, information systems, technology, opportunities and solutions, migration planning, implementation governance, 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 viewpoint 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 reference architectures through the Enterprise Continuum 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 Architecture Board structures,compliance reviews, architecture contracts, and repository 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 TOGAF Series Guide G198 addresses the question of how TOGAF relates to other architecture frameworks. This guide is relevant to the DoDAF and FEAF comparison because it provides The Open Group's own perspective on framework coexistence.

The key principle from G198 is that TOGAF does not claim to be the only valid enterprise-architecture approach. It acknowledges that enterprises may need to work with multiple frameworks and provides guidance on how TOGAF can coexist with, draw from, or interface with other approaches.

For practitioners, G198 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.

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 stakeholders, 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 artefact 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?

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 views 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, data domains, 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, transition planning, and governance. The ADM provides the end-to-end process backbone. The content metamodel structures therepository. 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.