DoDAF - Department of Defense Architecture Framework (2003)

Theory Publication Information

Citation Information

Why Was the Model Created?

During the 1990s and early 2000s, the US Department of Defense faced significant capability gaps and modernization challenges. Military capabilities depended on diverse information systems, platforms, and networks that were not well-integrated or coordinated. Different military commands used different architecture approaches and had limited interoperability. The Pentagon needed common framework ensuring military capabilities were properly architected, integrated, and operationally effective. Acquisition decisions lacked structured approach to capability-based requirements and architecture.

DoDAF evolved from the earlier C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, Reconnaissance) Architecture Framework (v2.0, 18 December 1997) but needed more comprehensive architecture framework incorporating lessons learned. DoDAF Version 1.0 (2003; Deskbook 9 February 2004) established a mandatory architecture description framework for all DoD acquisitions and major capability development efforts. Version 1.5 followed in April 2007 with refinements to the view-product set and improved guidance (date reported in secondary sources; not verifiable from the Version 1.0 Deskbook). DoDAF provided a structured approach to describing military capabilities, analyzing capability gaps, and planning modernization. The framework shifted DoD acquisition focus from individual systems to integrated capabilities.

DoDAF became foundational to US military doctrine. Major defense modernization programs became required to develop DoDAF-compliant architecture descriptions. The framework enabled DoD to systematically assess joint capabilities, identify capability gaps, plan capability improvements, and manage complex interdependencies across platforms, networks, and systems. DoDAF 2.0 (2009, updated to 2.02 in 2010) further evolved the framework by formalizing the data-centric approach already advocated in the Version 1.0 Deskbook (see Figure 2.2-2) through the DoDAF Meta-model (DM2) and by restructuring the four view categories into eight viewpoints. (Post-v1.0 evolution details are reported in subsequent DoDAF releases; they are not verifiable from the Version 1.0 Deskbook.)

What Does the Model Measure?

DoDAF does not measure constructs in the psychometric sense. As an architecture framework, it provides structured methods for describing and analyzing:

• Capability requirements: What military capabilities are needed and how they relate to missions, operations, and organizational goals.
• Operational activities and information flows: What tasks, activities, and information exchanges are required to execute capabilities.
• Systems and services architecture: What systems, services, and interfaces are needed to support operational activities.
• Standards compliance: Whether technology choices conform to mandated technical standards and interoperability requirements.
• Interoperability: The degree to which systems, services, and data can be exchanged across organizational boundaries.
• Capability gaps: Differences between required capabilities and current capabilities, informing modernization and acquisition decisions.

Core Concepts and Definitions

DoDAF centers on several core concepts:

• Capability: The ability to accomplish a military mission, function, or objective. Capabilities span people, processes, technology, and information. Capability focus enables warfighter-centric architecture.
• Architecture Views: Structured descriptions of specific aspects of capability from particular stakeholder perspective. Views show architecture from different vantage points addressing different stakeholder concerns.
• Viewpoints: Sets of related views showing particular architecture concerns. Viewpoints organize views into coherent collections addressing specific stakeholder interests (e.g., all operational views).
• Operational Architecture: Description of tasks, activities, and information flows necessary to accomplish military capability. Operational architecture defines what must be done without specifying how.
• Systems Architecture: Description of systems, system interconnections, and interfaces required to realize operational capability. Systems architecture specifies what systems are needed and how they integrate.
• Services Architecture: Description of services (DoDAF 2.0 addition) describing service-oriented approach to capability realization. Services architecture enables modular, reusable services.
• Capability-Based Planning: Planning process focused on developing capabilities to accomplish military missions rather than platform-centric planning. Capability focus enables more flexible modernization strategies.

Preceding Models or Theories

DoDAF built upon and extended several prior approaches:

• TAFIM (Technical Architecture Framework for Information Management, DoD 1994): TAFIM provided foundation for TOGAF and influenced DoD architecture thinking. DoDAF incorporated some TAFIM principles but took different direction emphasizing capability.
• C4ISR Architecture Framework (1996/1997):DoD’s predecessor framework focusing on Command, Control, Communications, Computers, Intelligence, Surveillance, Reconnaissance architecture. DoDAF evolved from C4ISR framework.
• TOGAF (The Open Group Architecture Framework, 1995): Commercial enterprise architecture framework. DoDAF learned from TOGAF but adapted principles to military capability focus.
• Zachman Framework (Zachman, 1987): Enterprise architecture framework emphasizing multiple stakeholder perspectives. DoDAF incorporated perspective-based approach similar to Zachman.
• Systems Engineering Practices (IEEE, 1980s-1990s):Systems engineering discipline provided foundation for DoDAF’s systematic approach to capability development.
• Joint Operations Concepts (JOC) Evolution (1990s onwards): Joint warfare doctrine and operational concepts informed DoDAF capability focus. DoDAF translated capability concepts into architecture descriptions.

Describe The Model

DoDAF provides mandatory architecture framework for US Department of Defense enabling capability-based architecture descriptions through systematic viewpoints, views, and data elements capturing military capability across operational, systems, services, and standards domains.

DoDAF 1.0 View Structure

DoDAF Version 1.0 (2003) organized architecture description into four view categories, each containing multiple products:

• All View (AV): Overarching products describing architecture overview, integrated dictionary, and documentation standards. AV products provide comprehensive context for all other views.
• Operational View (OV): Describes military tasks, activities, information flows, and organizational relationships needed to accomplish capability. OV products show operational concepts and required capabilities.
• Systems View (SV): Describes systems, system interconnections, system responsibilities, and system information exchanges. SV products show systems architecture and system integration.
• Technical Standards View (TV): Describes technical standards, policies, and compliance requirements governing architecture. TV products ensure interoperability and standards consistency.

DoDAF 2.0 Evolution

DoDAF 2.0 (2009) and 2.02 (2010) significantly evolved the framework, expanding from four view categories to eight viewpoints and formalizing the data-centric approach already advocated in the Version 1.0 Deskbook through a defined meta-model:

• Expanded to Eight Viewpoints: Added four new viewpoints: Capability Viewpoint (CV) for capability-based planning and assessment, Data and Information Viewpoint (DIV) for data standardization and information sharing, Project Viewpoint (PV) for implementation planning, and Services Viewpoint (SvcV) for service-oriented capability realization. The original TV became the Standards Viewpoint (StdV).
• Data-Centric Meta-Model Formalization: Formalized the data-centric architecture approach already described in the Version 1.0 Deskbook (see Figure 2.2-2, Data-Centric Build Sequence) by defining the DoDAF Meta-model (DM2) as a standardized data model. DM2 enables automated analysis and capability assessment across architectures.
• Meta-Model Foundation (DM2): Defined formal meta-model describing all architecture elements and relationships. DM2 enables consistent architecture description and automated processing.
• Fit-for-Purpose Guidance: Introduced principle that architectures should be developed only to the level of detail needed for the decision at hand, rather than requiring exhaustive documentation across all viewpoints.
• Analytical Capability: Data-centric approach enables automated capability gap analysis and trade-space analysis supporting better decision-making.

Key Architectural Domains

• Operational Architecture: Describes tasks, activities, organizations, information, and timelines needed to accomplish military operations and capability. Operational architecture answers what capabilities are needed.
• Systems Architecture: Describes systems, system interfaces, system interactions, and system data flows required to support operations. Systems architecture answers what systems and technologies are needed.
• Services Architecture: Describes services, service capabilities, service dependencies, and service interfaces enabling capability realization. Services architecture enables modular service-based integration.
• Capability Architecture: Describes military capabilities, capability dependencies, capability evolution, and capability roadmap. Capability architecture enables capability-based planning and assessment.
• Data and Information Architecture: Describes information entities, information definitions, information relationships, and information standards. Data architecture enables information sharing and interoperability.
• Standards Architecture: Describes technical standards, interface standards, data standards, and security standards governing capability realization. Standards architecture ensures interoperability and compliance.

Main Strengths

• Capability-centric focus: DoDAF emphasizes military capability enabling warfighter-centric architecture. Capability focus aligns architecture with military missions.
• Mandatory adoption: DoDAF is mandatory for DoD acquisitions and major capability efforts. Mandatory adoption ensures compliance and consistency across defense enterprise.
• Comprehensive viewpoint set: Multiple viewpoints address different stakeholder perspectives from operators to technologists. Comprehensive viewpoint coverage addresses diverse stakeholder interests.
• Integration focus: DoDAF emphasizes integration and interoperability across systems and capabilities. Integration focus improves joint operational effectiveness.
• Data-centric approach (DoDAF 2.0): Data-centric meta-model enables automated analysis and capability assessment. Data-centric approach enables sophisticated analytical capabilities.
• Proven effectiveness: DoDAF applied to major defense modernization programs. Proven track record demonstrates framework effectiveness at defense scale.

Main Weaknesses

• Complexity and documentation burden: DoDAF requires extensive architecture documentation across multiple viewpoints. Documentation burden increases time and cost for architecture development.
• Learning curve: DoDAF complexity requires significant training for DoD personnel and contractors. Learning curve creates adoption challenges.
• Tool immaturity: DoDAF tooling for architecture development and analysis evolved slowly. Tool limitations constrain efficient architecture development.
• Viewpoint consistency challenges: Maintaining consistency across multiple views and viewpoints proved difficult. Viewpoint consistency remains challenging even with meta-model.
• Technology evolution pacing: Technology changes faster than DoDAF standards can be updated. Architecture standards may become dated relative to technology advances.
• Agile tension: DoDAF structured approach can conflict with agile development practices. Reconciling DoDAF with agile methods remains challenging.
• Implementation variation: DoDAF implementation maturity varies across DoD organizations and programs. Implementation variation limits consistency across defense enterprise.

Key Contributions

• Advanced capability-centric architecture approach: DoDAF 2.0 (2009) formalized a capability-centric architecture approach in the defense domain, complementing parallel capability-based planning initiatives already underway in DoD policy during the 2000s.
• Mandated architecture discipline across defense: Mandatory DoDAF adoption for acquisitions and major programs established architecture discipline across defense enterprise. Mandatory adoption demonstrated executive commitment to architecture discipline.
• Created comprehensive viewpoint framework: DoDAF viewpoint structure addressed needs of diverse stakeholders from operators to system engineers. Viewpoint approach became standard in architecture discipline.
• Enabled capability-based planning: DoDAF architecture descriptions enabled capability-based planning approach. Capability-based planning improved defense modernization strategy and resource allocation.
• Advanced data-centric architecture (DoDAF 2.0): DoDAF 2.0 emphasized a data-centric architecture description approach (via the DoDAF Meta Model, or DM2) intended to enable automated analysis and fit-for-purpose architecture data.
• Enabled integration and interoperability: DoDAF emphasized systems integration and interoperability. Integration focus improved joint operational effectiveness across services.
• Foundation for defense acquisition reform: DoDAF architecture descriptions became requirement for major acquisition programs. Architecture requirement improved acquisition decision-making and risk management.
• Influenced federal and international architecture frameworks: DoDAF principles influenced other government agencies and international military partners. DoDAF approach became global defense architecture standard.

Internal Validity

DoDAF is a prescriptive architecture framework and product specification rather than an empirical theory, so construct-validity testing does not apply in the psychometric sense. Considerations typically raised about its internal consistency include:

• Logically coherent approach: The argument that capability-based architecture improves military effectiveness is logically sound. Capability focus aligns architecture with military missions.
• Comprehensive coverage: Framework comprehensively addresses capabilities from operational through technology implementation. Comprehensive approach addresses multiple interconnected concerns.
• Stakeholder perspective integration: Multiple viewpoints address different stakeholder perspectives. Perspective integration improves acceptance and addresses diverse concerns.
• Systems thinking foundation: DoDAF emphasis on systems integration and interoperability reflects established systems engineering principles. Systems approach improves overall capability effectiveness.
• Data-centric rigor (DoDAF 2.0): Formal meta-model and data-centric approach provide rigor for architecture description and analysis. Formal approach improves consistency and analytical capability.
• Broad operational deployment: DoDAF has been applied across major defense programs. Attribution of specific program outcomes to the framework itself (versus other factors such as acquisition reform and program management) is generally not established in published evaluations.

External Validity

External validity considerations concern generalizability of DoDAF beyond military context:

• Limited civilian adoption: DoDAF primarily used in defense domain. Limited civilian application due to military-specific terminology and concepts.
• Military-specific orientation: DoDAF concepts (operations, capability, mission) reflect military domain. Military focus limits applicability to commercial or civilian contexts.
• Scalability challenges: DoDAF works well for large complex defense programs. Applicability to smaller organizations and projects unclear.
• Agile method integration challenges: DoDAF structured approach conflicts with agile methods. Integration with agile practices requires significant adaptation.
• International variations: Different military organizations (different countries, NATO allies) use different architecture frameworks. International standardization on DoDAF limited.
• Technology evolution pacing: Technology changes faster than DoDAF standards can be updated. Reference architectures and standards may become outdated.
• Government adoption variation: Federal civilian agencies use FEAF (Federal Enterprise Architecture Framework) rather than DoDAF. Civilian government adoption inconsistent.

Relevance to Technology Adoption

DoDAF addresses technology adoption by establishing that technology decisions should support military capabilities and operational requirements rather than being driven by technology vendors. DoDAF requires organizations to develop operational architecture describing required capabilities, systems architecture describing systems needed to support capability, and assess technologies against capability requirements. This enables capability-driven technology adoption rather than vendor-driven acquisition.

Barriers to Capability-Driven Technology Adoption Identified

• Capability ambiguity: Military capabilities poorly defined or inconsistently understood. Ambiguous capability definitions lead to misaligned technology acquisitions.
• Legacy system dependencies: Existing systems and programs constrain technology adoption choices. Legacy constraints limit modernization options.
• Service parochialism: Different military services emphasize different capabilities and technologies. Service-specific interests conflict with joint capability perspective.
• Industrial base constraints: Vendor capabilities and supply base may constrain technology choices. Vendor ecosystem limitations restrict technology options.
• Governance gaps: Acquisition decisions may bypass capability-based governance processes. Governance gaps allow non-compliant acquisitions.
• Interoperability challenges: Technology acquisitions may lack interoperability with existing systems and capabilities. Interoperability failures reduce overall capability effectiveness.
• Rapid technology change: Technology evolution outpaces acquisition timelines. Technology changes between requirement definition and deployment.

Leadership Actions the Framework Prescribes

• Define military capabilities clearly: Establish clear definition of military capabilities, capability requirements, and capability performance measures. Clear capability definitions enable technology-independent requirement statements.
• Develop operational architecture: Create operational architecture describing tasks, activities, and information flows needed to accomplish capability. Operational architecture establishes capability-based requirements.
• Assess technology against requirements: Evaluate technology options against capability requirements and operational architecture. Requirements-based assessment ensures technology supports capability.
• Plan systems integration: Develop systems architecture describing systems needed and system integration approach. Integration planning ensures systems work together supporting capability.
• Establish interoperability standards: Define technical standards ensuring systems interoperate and support information sharing. Standards ensure capability effectiveness across systems.
• Coordinate across services: Establish governance ensuring technology acquisitions support joint capabilities. Governance coordination improves joint effectiveness.
• Monitor capability realization: Continuously assess whether implemented technology systems achieve required capabilities. Monitoring enables course correction and capability assurance.
• Plan capability evolution: Develop capability roadmap showing how capabilities will evolve over time. Roadmap planning enables orderly modernization and technology insertion.

Following Models or Theories

DoDAF has evolved through multiple versions and is commonly discussed alongside related architecture frameworks and capability-planning approaches:

• DoDAF Evolution (2003-2010+): DoDAF evolved from Version 1.0 (2003) through Version 2.02 (2010) with enhanced capability focus and data-centric approach. Evolution demonstrates framework maturity and continuous improvement.
• Federal Enterprise Architecture Framework (FEAF): Civilian federal government developed FEAF based on enterprise architecture principles. FEAF adapted architecture discipline to civilian government context.
• NATO Architecture Framework (NAF): NATO allies developed architecture framework based on DoDAF principles. NAF v3 (2007) aligned with DoDAF viewpoints; NAF v4 (2018) adopted a model-based approach aligned with the NATO C3 Taxonomy. NAF enabled international military interoperability across 28+ member nations.
• Capability-Based Planning (CBP, 2004 onwards): DoD adopted capability-based planning as strategic planning approach enabled by DoDAF architectures. CBP revolutionized defense planning from platform-centric to capability-centric.
• Net-Centric Warfare Architecture (NCW): DoD emphasized network-centric operations and information sharing. DoDAF architectures enabled net-centric warfare implementation.
• Joint Capability Integration and Development System (JCIDS): DoD requirements process evolved to emphasize capability-based requirements informed by DoDAF architectures. JCIDS and DoDAF became complementary processes.
• Service-Oriented Architecture (SOA) in Defense: DoDAF services viewpoint enabled service-oriented architecture approaches. SOA provided alternative to traditional system-centric integration.

References

1. U.S. Department of Defense. (2003). DoD architecture framework version 1.0. U.S. Department of Defense, Office of the Chief Information Officer.

Further Reading

1. U.S. Department of Defense. (2010). DoD architecture framework version 2.02. U.S. Department of Defense, Office of the Chief Information Officer.
2. U.S. Department of Defense. (1997). C4ISR architecture framework version 2.0. U.S. Department of Defense.
3. U.S. Department of Defense. (1994). Technical architecture framework for information management (TAFIM), version 2.0. U.S. Government Publishing Office.
4. Alberts, D. S., & Hayes, R. E. (2007). Understanding command and control. CCRP Publication.
5. Morris, E., Levine, L., Meyers, C., Place, P., & Plakosh, D. (2004). System of systems interoperability (SOSI). Software Engineering Institute.
6. U.S. Department of Defense. (2004). Capability-based planning guidance. U.S. Department of Defense.
7. NATO. (2018). NATO architecture framework version 4. NATO Consultation, Command and Control Board, Architecture Capability Team.
8. Schekkerman, J. (2003). How to survive in the jungle of enterprise architecture frameworks. Trafford Publishing.
9. Liles, R. P., & Goodman, S. E. (2004). IT leadership as a strategic tool for command and control transformation. Naval War College Review, 57(3), 95-111.

Series Navigation