Actions

Difference between revisions of "Department of Defense Architecture Framework (DoDAF)"

Line 43: Line 43:
  
 
'''Creating an integrated architecture using DoDAF (ee Figure 3)'''<ref>Creating an integrated architecture using DoDAF [https://en.wikipedia.org/wiki/Department_of_Defense_Architecture_Framework Wikipedia]</ref><br />
 
'''Creating an integrated architecture using DoDAF (ee Figure 3)'''<ref>Creating an integrated architecture using DoDAF [https://en.wikipedia.org/wiki/Department_of_Defense_Architecture_Framework Wikipedia]</ref><br />
The DODAF 2.0 Architects Guide repeated DOD Instruction 4630.8 definition of an integrated architecture as An architecture consisting of multiple views facilitating integration and promoting interoperability across capabilities and among integrated architectures. For the purposes of architecture development, the term integrated means that data required in more than one of the architectural models is commonly defined and understood across those models. Integrated architectures are a property or design principle for architectures at all levels: Capability,Component, Solution, and Enterprise (in the context of the DoD [[Enterprise Architecture\Enterprise Architecture (EA)]] being a federation of architectures). In simpler terms, integration is seen in the connection from items common among architecture products, where items shown in one architecture product (such as sites used or systems interfaced or services provided) should have the identical number, name, and meaning appear in related architecture product views. There are many different approaches for creating an integrated architecture using DoDAF and for determining which products are required. The approach depends on the requirements and the expected results; i.e., what the resulting architecture will be used for. As one example, the DoDAF v1.0 listed the following products as the "minimum set of products required to satisfy the definition of an OV, SV and TV." One note: while the DoDAF does not list the OV-1 artifact as a core product, its development is strongly encouraged. The sequence of the artifacts listed below gives a suggested order in which the artifacts could be developed. The actual sequence of view generation and their potential customization is a function of the application domain and the specific needs of the effort.
+
The DODAF 2.0 Architects Guide repeated DOD Instruction 4630.8 definition of an integrated architecture as An architecture consisting of multiple views facilitating integration and promoting interoperability across capabilities and among integrated architectures. For the purposes of architecture development, the term integrated means that data required in more than one of the architectural models is commonly defined and understood across those models. Integrated architectures are a property or design principle for architectures at all levels: Capability,Component, Solution, and Enterprise (in the context of the DoD [[Enterprise Architecture|Enterprise Architecture (EA)]] being a federation of architectures). In simpler terms, integration is seen in the connection from items common among architecture products, where items shown in one architecture product (such as sites used or systems interfaced or services provided) should have the identical number, name, and meaning appear in related architecture product views. There are many different approaches for creating an integrated architecture using DoDAF and for determining which products are required. The approach depends on the requirements and the expected results; i.e., what the resulting architecture will be used for. As one example, the DoDAF v1.0 listed the following products as the "minimum set of products required to satisfy the definition of an OV, SV and TV." One note: while the DoDAF does not list the OV-1 artifact as a core product, its development is strongly encouraged. The sequence of the artifacts listed below gives a suggested order in which the artifacts could be developed. The actual sequence of view generation and their potential customization is a function of the application domain and the specific needs of the effort.
 
AV-1 : Overview and Summary Information
 
AV-1 : Overview and Summary Information
 
AV-2 : Integrated Dictionary
 
AV-2 : Integrated Dictionary

Revision as of 21:13, 10 December 2019

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, pictorial, temporal, graphical, probabilistic, or alternative conceptual means.[1]


DoD Architecture Framework v1.5
Department of Defense Architecture Framework (DoDAF)
Figure 1. source: Military Wikia


DoDAF Design Process[2]
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. There are 6 steps that make up the DoDAF Design Process. These steps are:

  • Step 1: Determine Intended Use of Architecture
  • Step 2: Determine Scope of Architecture
  • Step 3: Determine Data Required to Support Architecture Development
  • Step 4: Collect, Organize, Correlate, and Store Architectural Data
  • Step 5: Conduct Analyses in Support of Architecture Objectives
  • Step 6: Document Results in Accordance with Decision-Maker Needs


DoDAF Terminologies and Concepts[3]
There are several key terminologies used in DoDAF V2.0, which are essential to understanding the framework:

  • Models: Visualizing architectural data is accomplished through models (e.g., the ‘products’ described in previous versions of DoDAF). Models (Which can be documents, spreadsheets, dashboards, or other graphical representations) serve as a template for organizing and displaying data in a more easily understood format.
  • Views: When data is collected and presented in a model format, the result is called a view'
  • Viewpoints: Organized collections of views (often representing processes, systems, services, standards, etc.) are referred to as viewpoints.


DoDAF Architecture Framework Version 2.0
DoDaF Concepts
Figure 2. source: Military Wikia


DoDAF Viewpoints[4]
The documented results of the DoDAF process are organizes into the following Viewpoints (aka Architecture Types):

  • All Viewpoint (AV): describes the overarching aspects of architecture context that relate to all viewpoints.
  • Capability Viewpoint (CV): articulates the capability requirements, the delivery timing, and the deployed capability.
  • Data and Information Viewpoint (DIV): articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services.
  • Operational Viewpoint (OV): includes the operational scenarios, activities, and requirements that support capabilities.
  • Project Viewpoint (PV): describes the relationships between operational and capability requirements and the various projects being implemented.
  • Services Viewpoint (SvcV): is the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.
  • Standards Viewpoint (StdV): articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services.
  • Systems Viewpoint (SV): for Legacy support, is the design for solutions articulating the systems, their composition, inter connectivity, and context providing for or supporting operational and capability functions.


Creating an integrated architecture using DoDAF (ee Figure 3)[5]
The DODAF 2.0 Architects Guide repeated DOD Instruction 4630.8 definition of an integrated architecture as An architecture consisting of multiple views facilitating integration and promoting interoperability across capabilities and among integrated architectures. For the purposes of architecture development, the term integrated means that data required in more than one of the architectural models is commonly defined and understood across those models. Integrated architectures are a property or design principle for architectures at all levels: Capability,Component, Solution, and Enterprise (in the context of the DoD Enterprise Architecture (EA) being a federation of architectures). In simpler terms, integration is seen in the connection from items common among architecture products, where items shown in one architecture product (such as sites used or systems interfaced or services provided) should have the identical number, name, and meaning appear in related architecture product views. There are many different approaches for creating an integrated architecture using DoDAF and for determining which products are required. The approach depends on the requirements and the expected results; i.e., what the resulting architecture will be used for. As one example, the DoDAF v1.0 listed the following products as the "minimum set of products required to satisfy the definition of an OV, SV and TV." One note: while the DoDAF does not list the OV-1 artifact as a core product, its development is strongly encouraged. The sequence of the artifacts listed below gives a suggested order in which the artifacts could be developed. The actual sequence of view generation and their potential customization is a function of the application domain and the specific needs of the effort. AV-1 : Overview and Summary Information AV-2 : Integrated Dictionary OV-1 : High Level Operational Concept Graphic OV-5 : Operational Activity Model OV-2 : Operational Node Connectivity Description OV-3 : Operational Informational Exchange Matrix SV-1 : System Interface Description TV-1 : Technical Standards Profile


Illustration of the integrated architecture
Integrated Architecture
Figure 3. source: Wikipedia


One concern about the DoDAF is how well these products meet actual stakeholder concerns for any given system of interest. One can view DoDAF products, or at least the 3 views, as ANSI/IEEE 1471-2000 or ISO/IEC 42010 viewpoints. But to build an architecture description that corresponds to ANSI/IEEE 1471-2000 or ISO/IEC 42010, it is necessary to clearly identify the stakeholders and their concerns that map to each selected DoDAF product. Otherwise there is the risk of producing products with no customers. Figure 4, "DoDAF V1.5 Products Matrix" shows how the DoD Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01E specifies which DoDAF V1.5 products are required for each type of analysis, in the context of the Net-Ready Key Performance Parameter (NR-KPP):

  • Initial Capabilities Document (ICD). Documents the need for a materiel solution to a specific capability gap derived from an initial analysis of alternatives executed by the operational user and, as required, an independent analysis of alternatives. It defines the capability gap in terms of the functional area, the relevant range of military operations, desired effects, and time.
  • Capability Development Document (CDD). A document that captures the information necessary to develop a proposed program(s), normally using an evolutionary acquisition strategy. The CDD outlines an affordable increment of militarily useful, logistically supportable and technically mature capability.
  • Capability Production Document (CPD). A document that addresses the production elements specific to a single increment of an acquisition program.
  • Information Support Plan (ISP). The identification and documentation of information needs, infrastructure support, IT and NSS interface requirements and dependencies focusing on net-centric, interoperability, supportability and sufficiency concerns (DODI 4630.8).
  • Tailored Information Support Plan (TISP). The purpose of the TISP process is to provide a dynamic and efficient vehicle for certain programs (ACAT II and below) to produce requirements necessary for I&S Certification. Select program managers may request to tailor the content of their ISP (ref ss). For programs not designated OSD special interest by ASD (NII)/DOD CIO, the component will make final decision on details of the tailored plan subject to minimums specified in the TISP procedures linked from the CJCSI 6212 resource page and any special needs identified by the J-6 for the I&S certification process.


DoDAF V1.5 Products Matrix
DoDaF Product Matrix
Figure 4. source: Wikipedia


See Also

Enterprise Architecture
Enterprise Architecture Framework
Business Systems Planning (BSP) Enterprise Architecture Management (EAM)
Enterprise Architecture Value Framework (EAVF)
Federal Enterprise Architecture Framework (FEA)
Zachman Framework
The Open Group Architecture Framework (TOGAF)
Adaptive Enterprise Framework (AEF)
Technical Architecture Framework for Information Management (TAFIM)


References

  1. Defining Department of Defense Architecture Framework Wikipedia
  2. DoDAF Design Process AcqNotes
  3. DoDAF Terminologies and Concepts CSU East Bay
  4. DoDAF Viewpoints AcqNotes
  5. Creating an integrated architecture using DoDAF Wikipedia


Further Reading

  • The Open Group Architecture Framework (TOGAF) and the US Department of Defense Architecture Framework (DoDAF) The Open Group
  • Using the Department of Defense Architecture Framework to Develop Security Requirements SANS Institute