The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, , temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.
This Architecture Framework is especially suited to large systems with complex integration and interoperability challenges, and it is apparently unique in its employment of "operational views". These views offer overview and details aimed to specific stakeholders within their domain and in interaction with other domains in which the system will operate.(reference: Zachman Framework)
Overview The DoDAF provides a foundational framework for developing and representing architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures across organizational, joint, and multinational boundaries. It establishes data element definitions, rules, and relationships and a baseline set of products for consistent development of systems, integrated, or federated architectures. These architecture descriptions may include families of systems (FoS), systems of systems (SoS), and net-centric capabilities for interoperating and interacting in the non-combat environment.
DoD Components are expected to conform to DoDAF to the maximum extent possible in development of architectures within the department. Conformance ensures that reuse of information, architecture artifacts, models, and viewpoints can be shared with common understanding. All major U.S. DoD weapons and information technology system acquisitions are required to develop and document an enterprise architecture (EA) using the views prescribed in the DoDAF. While it is clearly aimed at military systems, DoDAF has broad applicability across the private, public and voluntary sectors around the world, and represents one of a large number of systems architecture frameworks. mandatory appendices for ICD, CDD, and CPD, e.g. pg E-A-5 "Mandatory: OV-1"
The purpose of DoDAF is to define concepts and models usable in DoD's six core processes: Joint Capabilities Integration and Development (JCIDS) Planning, Programming, Budgeting, and Execution (PPBE) Defense Acquisition System (DAS) Systems Engineering (SE) Operational Planning (OPLAN) Capability Portfolio Management (CPM) In addition, DoDAF 2.0's specific goals were to: Establish guidance for architecture content as a function of purpose – “fit for purpose” Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated with more precision.
History
The first version of the development DoDAF was developed in the 1990s under the name C4ISR Architecture Framework. In the same period the reference model TAFIM, which was initiated in 1986, was further developed. The first C4ISR Architecture Framework v1.0, released 7 June 1996, was created in response to the passage of the Clinger-Cohen Act. It addressed the 1995 Deputy Secretary of Defense directive that a DoD-wide effort be undertaken to define and develop a better means and process for ensuring that C4ISR capabilities were interoperable and met the needs of the warfighter. Continued development effort resulted in December 1997 in the second version, C4ISR Architecture Framework v2.0.
In August 2003 the DoDAF v1.0 was released, which restructured the C4ISR Framework v2.0 to offer guidance, product descriptions, and supplementary information in two volumes and a Desk Book. It broadened the applicability of architecture tenets and practices to all Mission Areas rather than just the C4ISR community. This document addressed usage, integrated architectures, DoD and Federal policies, value of architectures, architecture measures, DoD decision support processes, development techniques, analytical techniques, and the CADM v1.01, and moved towards a repository-based approach by placing emphasis on architecture data elements that comprise architecture products. In February 2004 the documentation of Version 1.0 was released with volume "I: Definitions and Guidelines", "II: Product Descriptions" and a "Deskbook". In April 2007 the Version 1.5 was released with a documentation of "Definitions and Guidelines", "Product Descriptions" and "Architecture Data Description". This period further developed the concepts and terms that have since been replaced with different approaches. For example, a Mission Needs Statement (MNS) was a U.S. Department of Defense type of document which identified capability needs for a program to satisfy by a combination of solutions (DOTMLPF) to resolve a mission deficiency or to enhance operational capability. This type of document has been superseded by the description of capability needs called an Initial Capabilities Document, as of CJCSI 3170.01E. The CJCSI 3170.01 and 6212.01 were superseded by the CJCSI 5123.01 Series.
This term was introduced as a fundamental step in CJCSI 3170.01B (Apr 2001), 6212.01D (Apr 2005), and the Interim Defense Acquisition Guidebook (Oct 2004).
On May 28, 2009, DoDAF v2.0 was approved by the Department of Defense.DoD CIO Memo Releasing DoDAF 2.0 The current version is DoDAF 2.02 DoDAF V2.0 is published on a public website.DoD CIO DoDAF Website
Other derivative frameworks based on DoDAF include the NATO Architecture Framework (NAF) and Ministry of Defence Architecture Framework. Like other EA approaches, for example The Open Group Architecture Framework (TOGAF), DoDAF is organized around a shared repository to hold work products. The repository is defined by the common database schema Core Architecture Data Model 2.0 and the DoD Architecture Registry System (DARS). A key feature of DoDAF is interoperability, which is organized as a series of levels, called Levels of Information System Interoperability (LISI). The developing system must not only meet its internal data needs but also those of the operational framework into which it is set.
Capabilities and mission
See the diagram for a depiction of the Capabilities Emphasis, as tied in with mission/course of action, threads, activities, and architectures.
The DoD has moved toward a focus on the delivery of capabilities, which are the reason for creating the system/service. The Capability Models describe capability taxonomy and capability evolution. A capability thread would equate to the specific activities, rules, and systems that are linked to that particular capability.
The concept of capability, as defined by its Meta-model Data Group allows one to answer questions such as: How does a particular capability or capabilities support the overall mission/vision? What outcomes are expected to be achieved by a particular capability or set of capabilities? What services are required to support a capability? What is the functional scope and organizational span of a capability or set of capabilities? What is our current set of capabilities that we are managing as part of a portfolio?
The Mission or Course of Action is described by a Concept of Operations (CONOPS), and is organized by Capabilities. Capabilities are described by Threads. Threads are described by Activities executed in serial or parallel. Activities are grouped into Mission Areas. Activities define operations for an Architecture. Architectures are organized by mission areas. Architectures provide proper resourcing of capabilities required by the Mission or Course of Action.
Version 1.5 views
The DoDAF V1.5 defines a set of products, a view model, that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through graphic, tabular, or textual means. These products are organized under four views: All view (AV) Operational view (OV) Systems view (SV) Technical standards view (TV) Each view depicts certain perspectives of an architecture as described below. Only a subset of the full DoDAF viewset is usually created for each system development. The figure represents the information that links the operational view, systems and services view, and technical standards view. The three views and their interrelationships – driven by common architecture data elements – provide the basis for deriving measures such as interoperability or performance, and for measuring the impact of the values of these metrics on operational mission and task effectiveness.
All view All view (AV) products provide overarching descriptions of the entire architecture and define the scope and context of the architecture. The DoDAF V1.5 AV products are defined as: AV-1 Overview and Summary Information Scope, purpose, intended users, environment depicted, analytical findings (if applicable) AV-2 Integrated Dictionary Definitions of all terms used in all products.
Operational view Operational View (OV) products provide descriptions of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. The OV provides textual and graphical representations of operational nodes and elements, assigned tasks and activities, and information flows between nodes. It defines the type of information exchanged, the frequency of exchanges, the tasks and activities supported by these exchanges and the nature of the exchanges. The DoDAF V1.5 OV products are defined as: OV-1 High Level Operational Concept Graphic High level graphical and textual description of operational concept (high level organizations, missions, geographic configuration, connectivity, etc.). OV-2 Operational Node Connectivity Description Operational nodes, activities performed at each node, and connectivities and information flow between nodes. OV-3 Operational Information Exchange Matrix Information exchanged between nodes and the relevant attributes of that exchange such as media, quality, quantity, and the level of interoperability required. OV-4 Organizational Relationships Chart Command, control, coordination, and other relationships among organizations. OV-5 Operational Activity Model Activities, relationships among activities, inputs and outputs. In addition, overlays can show cost, performing nodes, or other pertinent information. OV-6a Operational Rules Model One of the three products used to describe operational activity sequence and timing that identifies the business rules that constrain the operation. OV-6b Operational State Transition Description One of the three products used to describe operational activity sequence and timing that identifies responses of a business process to events. OV-6c Operational Event-Trace Description One of the three products used to describe operational activity sequence and timing that traces the actions in a scenario or critical sequence of events. OV-7 Logical Data Model Documentation of the data requirements and structural business process rules of the Operational View. (In DoDAF V1.5. This corresponds to DIV-2 in DoDAF V2.0.)
Systems and services view Systems and services view (SV) is a set of graphical and textual products that describe systems and services and interconnections providing for, or supporting, DoD functions. SV products focus on specific physical systems with specific physical (geographical) locations. The relationship between architecture data elements across the SV to the OV can be exemplified as systems are procured and fielded to support organizations and their operations. The DoDAF V1.5 SV products are: SV-1 Systems/Services Interface Description