• DODAF Home 
• Background 
• Architectural Development 
• Meta Model 
  • Conceptual 
  • Logical 
  • PES 
  • IDEAS Foundation Ontology 
• Viewpoints & Models
  • All Viewpoint 
  • Capability Viewpoint 
  • Data and Information Viewpoint 
  • Operational Viewpoint 
  • Project Viewpoint 
  • Services Viewpoint 
  • Standards Viewpoint 
  • Systems Viewpoint 
  • Models 
  • Model Categories
  • Levels of Architecture
  • Architecture Interrogatives 
  • Architecture Modeling Primitives
  • Mapping to DM2 
• Presentation Techniques
  • Composite Views 
  • Fusion Views 
  • Reference Models 
• DODAF-DM2 Configuration Management
• Related Links 
• Acronyms List and Glossary of Terms 
• Site Map 
• Archives

The Department of Defense Architecture Framework (DoDAF), Version 2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries. The DoDAF serves as one of the principal pillars supporting the DoD Chief Information Officer (CIO) in his responsibilities for development and maintenance of architectures required under the Clinger-Cohen Act. DoDAF is prescribed for the use and development of Architectural Descriptions in the Department. It also provides extensive guidance on the development of architectures supporting the adoption and execution of Net-centric services within the Department.

DoD managers, as process owners, specify the requirements and control the development of architectures within their areas of authority and responsibility. They select an architect and an architecture development team to create the architecture in accordance with the requirements they define.

DoD Components are expected to conform to the DoDAF when developing architectures within the Department. DoDAF Conformance ensures reuse of information and that architecture artifacts, models, and viewpoints can be shared with common understanding.

DoDAF V2.0 focuses on architectural "data", rather than on developing individual "products" as described in previous versions. In general, data can be collected, organized, and stored by a wide range of architecture tools developed by commercial sources. It is anticipated that these tools will adopt the DM2 PES for the exchange of architectural data.

DoDAF V2.0 provides a Data Capture Method for each data group of the DM2 to guide architects in collecting and organizing the necessary architectural data.

The DoDAF enables architectural content that is "Fit-for-Purpose" as an architectural description consistent with specific project or mission objectives. Because the techniques of architectural description can be applied at myriad levels of an enterprise, the purpose or use of an architectural description at each level will be different in content, structure, and level of detail. Tailoring the architectural description development to address specific, well-articulated, and understood purposes, will help ensure the necessary data is collected at the appropriate level of detail to support specific decisions or objectives.

Visualizing architectural data is accomplished through models (e.g., the products described in previous versions of DoDAF). Models can be documents, spreadsheets, dashboards, or other graphical representations and serve as a template for organizing and displaying data in a more easily understood format. When data is collected and presented as a "filled-in" model, the result is called a view. Organized collections of views (often representing processes, systems, services, standards, etc.) are referred to as viewpoints, and with appropriate definitions are collectively called the Architectural Description.

DoDAF V2.0 discusses DoDAF-described Models and Fit-for-Purpose Views:

• DoDAF-described Models (also referred to as Models) are created from the subset of data for a particular purpose. Once the DoDAF-described Models are populated with data, these "views" are useful as examples for presentation purposes, and can be used as described, modified, or tailored as needed.
• Fit-for-Purpose Views are user-defined views of a subset of architectural data created for some specific purpose (i.e., "Fit-for-Purpose"). While these views are not described or defined in DoDAF, they can be created, as needed, to ensure that presentation of architectural data is easily understood. This enables organizations to use their own established presentation preferences in their deliberations.

The models described in DoDAF, including those that are legacies from previous versions of the Framework, are provided as pre-defined examples that can be used when developing presentations of architectural data.

Specific DoDAF-described Models for a particular purpose are prescribed by process-owners. All the DoDAF-described Models do not have to be created. If an activity model is created, a necessary set of data for the activity model is required. Key process owners will decide what architectural data is required, generally through DoDAF-described Models or Fit-for-Purpose Views. However, other regulations and instructions from the DoD and the Chairman, Joint Chiefs of Staff (CJCS) have particular presentation view requirements.

The architect and stakeholders select views to ensure that the Architectural Descriptions will support current and future states of the process or activity under review. Selecting Architecture Viewpoints carefully ensures that the views adequately frame concerns, e.g., by explaining the requirements and proposed solutions, in ways that enhance audience understanding.

DoDAF also serves as the principal guide for development of integrated architectures as defined in DoD Instruction 4630.8, which defines an integrated architecture as "An architecture consisting of multiples views or perspectives facilitating integration and promoting interoperability across capabilities and among integrated architectures". The term integrated means that data required in more than one instance in architectural views is commonly understood across those views.

The DM2 provides information needed to collect, organize, and store data in a way easily understood.

The DM2 replaces the Core Architecture Data Model (CADM) which supported previous versions of the DoDAF. DM2 is a data construct that facilitates reader understanding of the use of data within an architecture document. CADM can continue to be used in support of architectures created in previous versions of DoDAF. NOTE: DoDAF V2.0 does NOT prescribe a Physical Data Model (PDM), leaving that task to software developers who will implement the principles and practices of DoDAF in their own software offerings.

DoDAF V2.0 is a marked change from earlier versions of Command, Control, Communications, Computers, and Intelligence Surveillance Reconnaissance Architecture Framework (C4ISR AF) or DoDAF, in that architects now have the freedom to create enterprise architectures to meet the demands of their customers. The core of DoDAF V2.0 is a data-centric approach where the creation of architectures to support decision-making is secondary to the collection, storage, and maintenance of data needed to make efficient and effective decisions. The architect and stakeholders select views to ensure that architectures will explain current and future states of the process or activity under review. Selecting architectural views carefully ensures that they adequately explain the requirement and proposed solution in ways that will enhance audience understanding.

DoDAF V2.0 also provides, but does not require, a particular methodology in architecture development. It provides guidance and suggestions on how to ensure that other proposed methods can be adapted as needed to meet the DoD requirements for data collection and storage. Similarly, the views presented in DoDAF are examples, intended to serve as a possible visualization of a particular view. DoDAF V2.0 also continues providing support for views (i.e., 'products' developed in previous versions of the Framework). These views do not require any particular graphical design by toolset vendors.

Authority: Law and Policy DoDAF Supports

Federal law and policies have expressed the need for architectures in support of business decisions.

Six Core Processes DoDAF Supports

Organizations within the DoD may define local change management processes, supportable by Architectural Descriptions, while adhering to defined decision support processes mandated by the Department, including JCIDS, the DAS, SE, PPBE, Net-centric Integration, and PfM. These key support processes are designed to provide uniform, mandated, processes in critical decision-making areas, supplemented by individual agency operations, defined by Architectural Descriptions tailored to support those decisions-making requirements.

Joint Capability Integration and Development System

The primary objective of the JCIDS process is to ensure warfighters receive the capabilities required to execute their assigned missions successfully. JCIDS defines a collaborative process that utilizes joint concepts and integrated Architectural Descriptions to identify prioritized capability gaps and integrated joint Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities (DOTMLPF) and policy approaches (materiel and non-materiel) to resolve those gaps. JCIDS implements an integrated, collaborative process to guide development of new capabilities through changes in joint DOTMLPF and policy.

JCIDS process owners have written policy to support architecture requirements (i.e., specific product sets required in specific documents, such as the Information Support Plan, Capability Development Document, and Capability Production Document) that permits components and lower echelon commands to invoke the JCIDS process for requirements at all levels.

Defense Acquisition System

The DAS exists to manage the nation’s investments in technologies, programs, and product support necessary to achieve the National Security Strategy and support employment and maintenance of the United States Armed Forces. The DAS uses Joint Concepts, integrated architectures, and DOTMLPF analysis in an integrated, collaborative process to ensure that desired capabilities are supported by affordable systems and other resources.

DoD Directive 5000.1 provides the policies and principles that govern the DAS. In turn, DoD Instruction 5000.2, Operation of the DAS establishes the management framework for translating mission needs and technology opportunities, based on approved mission needs and requirements, into stable, affordable, and well-managed acquisition programs that include weapon systems and automated information systems (AISs). The Defense Acquisition Management Framework provides an event-based process where acquisition programs advance through a series of milestones associated with significant program phases.

The USD (AT&L) leads the development of integrated plans or roadmaps using integrated architectures as its base. DoD organizations use these roadmaps to conduct capability assessments, guide systems development, and define the associated investment plans as the basis for aligning resources and as an input to the Defense Planning Guidance (DPG), Program Objective Memorandum (POM) development, and Program and Budget Reviews.

Systems Engineering

DoD Acquisition policy directs all programs responding to a capabilities or requirements document, regardless of acquisition category, to apply a robust SE approach that balances total system performance and total cost with the family-of-systems, and system-of-systems context. Programs develop a Systems Engineering Plan (SEP) for Milestone Decision Authority (MDA) that describes the program’s overall technical approach, including activities, resources, measures (metrics), and applicable performance incentives.

SE processes are applied to allow an orderly progression from one level of development to the next detailed level using controlled baselines. These processes are used for the system, subsystems, and system components as well as for the supporting or enabling systems used for the production, operation, training, support, and disposal of that system. Execution of technical management processes and activities, such as trade studies or risk management activities may point to specific requirements, interfaces, or design solutions as non-optimal and suggest change to increase system-wide performance, achieve cost savings, or meet scheduling deadlines.

Architecture supports SE by providing a structured approach to document design and development decisions based on established requirements.

Planning, Programming, Budgeting, and Execution

The PPBE process allocates resources within the DoD and establishes a framework and process for decision-making on future programs. PPBE is a systematic process that guides DoD’s strategy development, identification of needs for military capabilities, program planning, resource estimation, and allocation, acquisition, and other decision processes. JCIDS is a key supporting process for PPBE, providing prioritization and affordability advice.

DoDAF V2.0 supports the PPBE process by identifying the touch points between architecture and the PPBE process, identifying the data to be captured within an Architectural Description, facilitating informed decision-making, and identifying ways of presenting data to various stakeholders/roles in the PPBE decision process.

Portfolio Management

DoD policy requires that IT investments be managed as portfolios to ensure IT investments support the Department’s vision, mission, and goals; ensure efficient and effective delivery of capabilities to the Warfighter; and maximize return on investment within the enterprise. Each portfolio may be managed using the architectural plans, risk management techniques, capability goals and objectives, and performance measures. Capability architecting is done primarily to support the definition of capability requirements. PfM uses the Architectural Description to analyze decisions on fielding or analysis of a needed capability.

Architectural support to PfM tends to focus on the investment decision itself (although not exclusively), and assists in justifying investments, evaluating the risk, and providing a capability gap analysis.

Operations

In most cases, an enterprise will capture its routine or repeatable business and mission operations as architectural content. However, when the basic structure of an activity is very stable and the activity repeated often, such as military operations planning or project definition and management, the enterprise may choose to include that structure as part of the Architectural Description itself. In this case, the architecture repository may be enhanced to include templates, checklists, and other artifacts commonly used to support the activity.

The JCIDS, PPBE, and DAS processes establish a knowledge-based approach, which requires program managers to attain the right knowledge at critical junctures to make informed program decisions throughout the acquisition process. The DoD IT PfM process continues to evolve that approach with emphasis on individual systems and/or services designed to improve overall mission capability. Consistent with OMB Capital Planning and Investment Control (CPIC) guidance, the DoD uses four continuous integrated activities to manage its portfolios – analysis, selection, control, and evaluation. The overall process is iterative, with results being fed back into the system to guide future decisions.

DM2 Support for the Six Core Processes DoDAF Supports

The DoDAF V2.0 Meta-model Groups support the viewpoints and DoD Key Processes of JCIDS, DAS, PPBE, System Engineering, Operations, and Portfolio Management (IT and Capability). The table below indicates a non-inclusive mapping of DoDAF Meta-model Groups to the DoDAF Viewpoints and DoD Key Processes. The support for the Key Processes is for the information requirements that were presented at the workshops for the key processes and, as such, do not reflect all of the information requirements that a key process could need.

DoDAF Meta-model Groups Mapping to Viewpoints and DoD Key Processes

What is New in DoDAF V2.0

The major changes for DoDAF V2.0 are:

• The major emphasis on architecture development has changed from a product-centric process to a data-centric process designed to provide decision-making data organized as information for the manager.
• Products have been replaced by views that represent specific types of presentation for architectural data and derived information. With the focus on data, DoDAF V2.0 does not have products but has DoDAF-described Models. Rather than the Operational Viewpoint-5 (OV-5) Operational Activity Model Product, there is the Activity Model with the same supporting data. This is shifting the focus of the architecture effort onto the data early in the Architecture Development Process.
• Architecture views are, in turn, organized into viewpoints, which provide a broad understanding of the purpose, objectives, component parts, and capabilities represented by the individual architectural views.
• The three major viewpoints of architecture described in previous version (e.g., Operational, Technical, and System) have been changed to more specific viewpoints that relate to the collection of architecture-related data which can be organized as useful information for the manager in decision-making. To support customer requirement and re-organization needs:

• All the models of data—conceptual, logical, or physical—have been placed into the Data and Information Viewpoint.
• The Technical Standards Viewpoint has been updated to the Standards Viewpoint and can describe business, commercial, and doctrinal standards, in addition to technical standards.
• The Operational Viewpoint now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships.
• Due to the emphasis within the Department on Capability PfM and feedback from the Acquisition community, the Capability Viewpoint and Project Viewpoint have been added.

• System has changed from DoDAF V1.5. System is not just computer hardware and computer software. System is now defined in the general sense of an assemblage of components - machine, human - that perform activities (since they are subtypes of Performer) and are interacting or interdependent. This could be anything, i.e., anything from small pieces of equipment that have interacting or interdependent elements, to Family of Systems (FoS) and System of Systems (SoS). Note that Systems are made up of Materiel (e.g., equipment, aircraft, and vessels) and Personnel Types.
• The Department initiatives for Architecture Federation and Tiered Responsibility have been incorporated into Version 2.0.
• Requirements for sharing of data and derived information in a Federated environment are described.
• Specific types of architecture within the Department have been identified and described (e.g., Department-level [which includes Department, Capability & Component architectures] and Solution Architectures).
• The DoD Enterprise Architecture is described.
• Linkages to the Federal Enterprise Architecture are defined and described.
• Architecture constructs originally described in the UK Ministry of Defence Architecture Framework (MODAF), the NATO Architecture Framework (NAF), and the Open Group Architecture Framework (TOGAF) are adopted for use within DoDAF.
• A DoDAF Meta-model (DM2), containing a Conceptual Data Model (CDM), a Logical Data Model (LDM), and a Physical Exchange Specification (PES) has been created.
• Approaches to SOA development are described and discussed.
• The basis of the Architecture Development Process is now the Data Meta-model Groups, described in the LDM.
• To align with ISO Standards, where appropriate, the terminology has changed from Views to Viewpoint (e.g., the Operational View is now the Operational Viewpoint).
• DoDAF can capture the security markings and is described in the PES.
• In DoDAF V1.5 and previous versions, Nodes are logical concepts that caused issues in the exchange and discussion of architectures. In one architecture that was reviewed, Operational Nodes mapped to System, Organization, Person Type, Facility, Materiel, and Installation. Within the same architecture, System Node maps to System, Materiel, Organization, and Location. The overlap Organizational and System nodes (System, Organization, Material) illustrates the complexity of trying to define Nodes. The concrete concepts of Node (including Activities, System, Organization, Person Type, Facility, Location, Materiel, and Installation) were incorporated into the DoDAF Meta-model. Since Nodes are logical concepts that could be used to represent the more concrete concepts of activities, systems, organizations, personnel types, facilities, locations, materiels, and installations or combinations of those things, DoDAF V2.0 focuses on those concrete concepts. There will not be a mapping of Node to the DoDAF V2.0 Meta-model Groups, concepts, classes, or associations. For the architect, there are some changes in architecture development:

• When appropriate, DoDAF V1.0 and V1.5 architectures that use the Node concept will need to update the architecture to express the concrete concepts in place of the abstract concept that Node represents. When pre-DoDAF V2.0 architecture is compared with DoDAF V2.0 architecture, the concrete concepts that Node represents must be defined for the newer architecture.
• DoDAF V2.0 architectures will need to express the concrete concepts (activities, systems, organizations, personnel types, facilities, locations, materiels, and installations, etc.).