Overview of DODAF and TOGAF

Defense system architects operate in an environment where interoperability, security, and mission assurance are non-negotiable. To manage the complexity of modern defense systems, they rely on architectural frameworks that provide structure, repeatability, and clarity. Two of the most widely referenced frameworks are the Department of Defense Architecture Framework (DODAF) and The Open Group Architecture Framework (TOGAF). While both offer pathways to coherent system design, they serve fundamentally different purposes and originate from different contexts.

DODAF is a framework developed by the U.S. Department of Defense specifically for modeling and documenting defense-related architectures. It was built to support acquisition, system-of-systems engineering, and operational planning across military branches. TOGAF, in contrast, is a general-purpose enterprise architecture framework maintained by The Open Group. It focuses on aligning business goals with IT capabilities and is used across industries such as finance, healthcare, manufacturing, and increasingly in government and defense.

Historical Context and Purpose

DODAF evolved from earlier military architecture efforts like the C4ISR Architecture Framework, formalized in the 1990s to help the DoD manage the growing complexity of networked systems. Its primary purpose is to ensure that defense systems are designed with interoperability, data sharing, and operational effectiveness in mind. DODAF is mandated for many DoD acquisition programs and is heavily relied upon by contractors and system integrators working on U.S. defense projects.

TOGAF was first released by The Open Group in 1995, drawing on earlier work from the U.S. Department of Defense’s Technical Architecture Framework for Information Management (TAFIM). Rather than being tied to a single domain, TOGAF was designed as a vendor-neutral, industry-agnostic framework that any organization could adopt to improve enterprise architecture practices. It has since become one of the most widely adopted enterprise architecture frameworks globally, with certified practitioners in both the public and private sectors.

Core Concepts of DODAF

DODAF organizes architectural data into a set of views and models. The framework defines eight viewpoints: All Viewpoint (AV), Capability Viewpoint (CV), Data and Information Viewpoint (DIV), Operational Viewpoint (OV), Project Viewpoint (PV), Services Viewpoint (SvcV), Standards Viewpoint (StdV), and Systems Viewpoint (SV). Each viewpoint contains specific models that describe aspects such as operational activities, system interfaces, data exchanges, and standards compliance. The emphasis is on providing multiple perspectives that together offer a comprehensive picture of a defense capability.

Key to DODAF is the concept of a DoDAF-described Model (DDM). Architects select which models to produce based on the questions they need to answer—for example, "What systems support this mission thread?" or "How does data flow between these sensor platforms?" The framework is modular: you use only the views relevant to your analysis, not all of them. This allows teams to tailor their effort to the scope of the project while maintaining a common language for communication across stakeholders.

Core Concepts of TOGAF

TOGAF is built around the Architecture Development Method (ADM), a step-by-step process for creating and managing enterprise architectures. The ADM consists of phases: Preliminary Phase, Architecture Vision, Business Architecture, Information Systems Architectures (Data and Application), Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, Architecture Change Management, and Requirements Management. Each phase produces specific deliverables, such as architecture principles, capability assessments, and roadmaps.

Unlike DODAF, which focuses on views (what to model), TOGAF focuses on process (how to build and govern the architecture). TOGAF also includes the Enterprise Continuum, a classification model for architectural assets, and the Architecture Content Framework, which defines artifacts like catalogs, matrices, and diagrams. TOGAF is designed to be iterative and adaptable, allowing organizations to scale the approach to their maturity level.

Comparative Analysis of DODAF and TOGAF

Understanding where these frameworks differ—and where they complement each other—is essential for any defense system architect. Below we examine the key dimensions of difference.

Scope and Focus

The most fundamental difference lies in scope. DODAF is domain-specific—it targets defense and national security systems. Its models are designed to capture operational concepts (like mission threads), system interfaces, and technical standards relevant to military environments. DODAF explicitly addresses concepts such as interoperability levels, security classification, and system-of-systems interactions in contested environments.

TOGAF is domain-agnostic. It provides a generic framework for enterprise architecture that can be applied to any organization—retail, banking, healthcare, or government. In a defense context, TOGAF can be used to align the enterprise IT strategy with defense business goals, manage the transition from legacy systems, or plan a shared services environment. However, TOGAF’s generic nature means it does not include built-in support for military-specific constructs like kill chains, command hierarchies, or platform-specific security requirements.

For defense system architects, this means that DODAF is typically used for system-level architecture (e.g., a new missile system, a C2 node), while TOGAF is used for enterprise-level architecture (e.g., the DoD’s IT infrastructure, logistics information systems). Many large defense programs use both: DODAF for the system-level modeling and TOGAF for the enterprise architecture governance and transformation planning.

Framework Structure

DODAF’s structure is view-based. The architect selects from a defined set of viewpoints and populates specific models (e.g., OV-1 Operational Concept Graphic, SV-1 Systems Interface Description). The outputs are static representations of the architecture at a point in time. DODAF version 2.02, the current standard, organizes models into a taxonomy that groups them by purpose: to describe the operational context, the systems and services, the data and information, and the technical standards.

TOGAF’s structure is process-based. The ADM guides the architect through a series of phases, each with defined objectives, steps, inputs, and outputs. The process is cyclical, allowing continuous iteration and refinement. TOGAF emphasizes architectural governance—how decisions are made, who approves them, and how changes are managed over time. The ADM is the heart of TOGAF; without it, the framework loses its procedural rigor.

This structural difference has practical implications. With DODAF, you can produce a set of models relatively quickly for a specific system, but you must be careful about maintaining consistency across models. With TOGAF, you invest upfront in architecture governance and stakeholder alignment, but the resulting architecture is more likely to be implemented and sustained because it has buy-in and a migration plan.

Methodology and Flexibility

DODAF is often described as prescriptive in its modeling requirements but flexible in how you use it. The framework does not prescribe a development process—it only specifies what models to produce and how they relate. You can use your own project management methodology (e.g., Agile, Waterfall) with DODAF. However, the models themselves are detailed and can be time-consuming to maintain, especially if the system changes frequently.

TOGAF is process-prescriptive but product-flexible. The ADM tells you the steps to follow, but the artifacts you create can be tailored to your organization’s needs. TOGAF allows you to omit phases, combine them, or iterate as required. This flexibility makes TOGAF suitable for organizations that are still maturing their architecture practice. The trade-off is that without strict guidance on what to produce, the quality and consistency of the architecture can vary.

For defense architects, the choice often comes down to the regulatory environment. If the project is a DoD acquisition and must comply with the Defense Acquisition Guidebook or JCIDS (Joint Capabilities Integration and Development System), DODAF models are often required deliverable items. In contrast, if the project involves enterprise-wide IT transformation—such as moving to a cloud-based logistics platform—TOGAF provides a better fit because of its emphasis on business capability planning and migration.

Governance and Compliance

DODAF is tightly integrated with DoD governance processes. Contractors are often required to produce DODAF models for system design reviews, and the DoD uses DODAF views to assess interoperability and data-sharing compliance. The framework also ties into the DoD’s reference architectures, such as the Joint Common Database (JCDB) and the DoD Information Enterprise Architecture (DoD IEA). This means that DODAF is not just a modeling tool—it is a compliance mechanism.

TOGAF’s governance is organization-centric. The framework recommends establishing an Architecture Board, but it does not mandate compliance with external regulations. In defense contexts, TOGAF can be used to comply with organizational standards like NIST SP 800-53 or the DoD’s CMMC (Cybersecurity Maturity Model Certification), but the mapping is not built into the framework. Architects must manually integrate these requirements into the ADM phases.

Application in Defense Projects

To see how these frameworks work in practice, consider two typical defense scenarios.

When to Use DODAF

Imagine you are the lead architect for a new tactical data link system that connects aircraft, ground stations, and ships. The system must meet specific interoperability standards (e.g., Link 16, JREAP) and be integrated with existing C2 systems. Your deliverable includes a System Architecture Description (System View 1) and Operational Activity Models (Operational View 5). DODAF is the natural choice because it provides the exact views needed to document system interfaces, data flows, and security constraints. The DoD customer will expect DODAF artifacts as part of the Systems Engineering Technical Review (SETR) process. Using TOGAF here would be possible but would require heavy customization to produce the same level of detail.

For a deeper understanding of DODAF’s model taxonomy, the official DoD guidance is available at DoD CIO DODAF page.

When to Use TOGAF

Now consider a different project: the Defense Logistics Agency wants to modernize its supply chain management system, consolidating multiple legacy ERP instances into a single cloud-based platform. This is an enterprise transformation effort involving business process reengineering, application rationalization, and data migration. The primary challenge is not modeling system interfaces but aligning business strategy with technology investments, managing organizational change, and creating a phased migration plan. TOGAF’s ADM is ideal here because it provides a structured way to develop the target architecture, assess current capabilities, and plan the transition. The architect can use TOGAF’s Business Architecture phase to map logistics processes, the Information Systems Architecture phase to define data models, and the Migration Planning phase to sequence the deployment. DODAF could supplement the effort by providing high-level operational views, but it would not offer the same governance and planning process.

More information on TOGAF and its ADM can be found at The Open Group TOGAF page.

Hybrid Approaches

Many defense organizations use both frameworks in concert. A typical pattern is to use TOGAF for the enterprise architecture practice—establishing the architecture board, managing the repository, and conducting capability-based planning—and then use DODAF for specific system-level modeling within that enterprise context. This hybrid approach is recommended by the DoD’s Chief Information Officer guidance. Some organizations also adopt the UPDM (UML Profile for DODAF and MODAF), which provides a standardized notation for DODAF models using UML/SysML, making it easier to integrate with TOGAF’s artifact set.

Another emerging trend is the use of Archimate, a modeling language aligned with TOGAF, to represent DODAF-like views. The Open Group’s ArchiMate standard includes a defense extension that allows architects to create operational and system views similar to DODAF’s. This opens the possibility of a unified modeling environment that supports both frameworks.

Decision Framework for Defense Architects

Choosing between DODAF and TOGAF (or combining them) depends on several factors:

  • Nature of the project: System-level (DODAF) vs. enterprise-level (TOGAF). If the project focuses on a specific defense system with clear interface requirements, DODAF is usually mandated or preferred. If the project involves business transformation, IT consolidation, or strategic planning, TOGAF is more appropriate.
  • Regulatory constraints: If the project must comply with DoD Directive 8200.1 or the Defense Acquisition University (DAU) curriculum, DODAF artifacts are often required. TOGAF can support compliance but is not the required framework.
  • Team maturity: Teams experienced with modeling languages and DoD acquisition processes will be more comfortable with DODAF. Teams new to architecture or working in a multi-industry environment may find TOGAF’s step-by-step approach easier to adopt.
  • Tooling: DODAF modeling often requires specialized tools like IBM Rational System Architect or No Magic MagicDraw with UPDM plugin. TOGAF can be supported by more generic enterprise architecture tools like Sparx Enterprise Architect or BiZZdesign. Tool selection may influence the choice.
  • Long-term sustainment: DODAF models can become outdated quickly if not maintained. TOGAF’s Architecture Change Management phase specifically addresses how to keep the architecture current. For systems with long lifecycles (e.g., combat platforms operating for 30+ years), TOGAF’s governance processes may be more valuable.

For a practical guide on integrating these frameworks, the MITRE Corporation publishes a helpful comparison that discusses how to harmonize DODAF with other frameworks like TOGAF and FEAF. See MITRE’s paper on bridging enterprise and system architectures.

Additional Considerations

Beyond the two main frameworks, defense architects should be aware of international equivalents such as the UK Ministry of Defence Architecture Framework (MODAF) and NATO Architecture Framework (NAF). These share many concepts with DODAF but have their own specific viewpoints. If your project involves coalition partners, you may need to ensure interoperability at the model level—DODAF and MODAF have been harmonized through the UPDM standard. TOGAF is also used internationally, and its openness can facilitate collaboration with non-defense agencies.

Finally, do not overlook the importance of training and certification. The Open Group offers TOGAF certification for individuals and organizations. The DoD provides training on DODAF through the Defense Acquisition University. Investing in certified architects can reduce risk in complex programs.

Conclusion

Both DODAF and TOGAF are powerful tools in the defense architect’s toolbox. DODAF excels at capturing the technical and operational details of defense systems, ensuring they meet military-specific requirements. TOGAF excels at guiding enterprise transformation, providing a proven process for aligning business and IT strategies. For defense system architects, the decision is not about which framework is better, but which one best fits the specific problem at hand. In many cases, the answer is both. By understanding their differences and how to combine them, architects can build architectures that are both rigorous and adaptable, meeting the demands of today’s complex defense environment.

For further reading, the Open Group provides a white paper on using TOGAF with government frameworks at TOGAF and Government Architecture Frameworks, and the DoD Architecture Framework site remains the definitive source for DODAF guidance. Architects should also consult their program office’s specific requirements before selecting a framework.