Department of Defense Architecture Framework

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense, that provides structure for a specific stakeholder concern through viewpoints organized by various views.

DoDAF defines a set of views that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal or graphical means.

It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of "operational views" detailing the external customer's operating domain in which the developing system will operate.[2]

Contents

Overview

The Department of Defense Architecture Framework (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 NCE.[1]

All major U.S. Government Department of Defense (DoD) weapons and information technology system acquisitions are required to develop and document an 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.[3]

The purpose of DoDAF is to define concepts and models usable in DoD’s six core processes:
  1. Capabilities Integration and Development (JCIDS)
  2. Planning, Programming, Budgeting, and Execution (PPBE)
  3. Acquisition System (DAS)
  4. Systems Engineering (SE)
  5. Operations Planning
  6. Capabilities Portfolio Management (CPM)

[4]

In addition, DoDAF 2.0’s specific goals were to:
  1. Establish guidance for architecture content as a function of purpose – “fit for purpose”
  2. 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 to mathematical precision.

[4]

History

Note, where the diagram states TBD, the DoDAF V2.0 was promulgated on May 28, 2009. The first version of the development DoDAF was developed in the 1990s under the name C4ISR architectural Architecture Framework. C4ISR stand for The Command, Control, Communications, Computers, and Intelligence, Surveillance, and Reconnaissance. 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.[1]

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.[1]

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".[5]

On May 28, 2009 DoDAF v2.0 was approved by the Department of Defense.[6] DoDAF V2.0 is published on a public website.[7]

Other derivative frameworks based on DoDAF include the NATO Architecture Framework (NAF) and Ministry of Defence (United Kingdom) Architecture Framework (MODAF). 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 Core Architecture Data Model 2.0 (CADM -- essentially a common database schema) 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.

DoDAF V1.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:

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.[1]

All View (AV)

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:

Operational View (OV)

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:

Systems and Services View (SV)

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:

Technical Standards View (TV)

TV products define technical standards, implementation conventions, business rules and criteria that govern the architecture. The DoDAF V1.5 TV products are as follows:

DoDAF V2.0 Viewpoints

In DoDAF V2.0 architectural viewpoints are composed of data that has been organized to facilitate understanding. 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).

Note, System has changed in DoDAF V2.0 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.

Relationship of DoDAF V1.5 Views with DoDAF V2.0 Viewpoints

The first figure shows the overall evolution of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints.

The second figure shows the specific mapping of individual DoDAF V1.5 Views to the corresponding DoDAF V2.0 Viewpoints.

DoDAF V1.5 Support. The architectures for DoDAF V1.0 and DoDAF V1.5 may continue to be used. When appropriate (usually indicated by policy or by the decision-maker), DoDAF V1.0 and V1.5 architectures will need to update their architecture. When pre-DoDAF V2.0 architecture is compared with DoDAF V2.0 architecture, concept differences (such as Node) must be defined or explained for the newer architecture.

In regard to DoDAF V1.5 products, they have been transformed into parts of the DoDAF V2.0 models. In most cases, the DoDAF V2.0 Meta-model supports the DoDAF V1.5 data concepts, with one notable exception: Node. Node is a complex, logical concept that is represented with more concrete concepts. The table below indicates the mapping of DoDAF V1.5 products to DoDAF V2.0 models.

Creating an integrated architecture using DoDAF

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.

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 (seen in at least some DoDAF architecture efforts) of producing products with no customers.

The figure "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):

Representation

Representations for the DoDAF products may be drawn from many diagramming techniques including:

and other custom techniques depending on the product, tool used, and contractor/customer preferences. There is a UPDM (Unified Profile for DoDAF and MODAF) effort within the OMG to standardize the representation of DoDAF products when UML is used.

DoDAF generically describes in the representation of the artifacts to be generated, but allows considerable flexibility regarding the specific formats and modeling techniques. The DoDAF deskbook provides examples in using traditional systems engineering and data engineering techniques, and secondly, UML format. DoDAF proclaims latitude in work product format, without professing one diagramming technique over another.

In addition to graphical representation, there is typically a requirement to provide metadata to the Defense Information Technology Portfolio Repository (DITPR) or other architectural repositories.

Meta-Model

DoDAF has always had some form of Meta-Model underpinning the framework. The meta-model defines the types of modelling elements that can be used in each view and the relationships between them.

DoDAF versions 1.0 thru 1.5 used the CADM meta-model, which was defined in IDEF1X (then later in UML) with an XML Schema derived from the resulting relational database.

From version 2.0, DoDAF has adopted the IDEAS Group foundation ontology as the basis for its new meta-model. This new meta-model is called "DM2"; an acronym for "Defense Meta-Model".

Diagram of DoDAF V2.0 Meta Model DM2's Three Levels.

Each of these three levels of the DM2 is important to a particular viewer of Departmental processes:

  1. The conceptual level or Conceptual Data Model (CDM) defines the high-level data constructs from which Architectural Descriptions are created in non-technical terms, so that executives and managers at all levels can understand the data basis of Architectural Description. Represented in the DoDAF V2.0 DIV-1 Viewpoint.
  2. The Logical Data Model (LDM) adds technical information, such as attributes to the CDM and, when necessary, clarifies relationships into an unambiguous usage definition. Represented in the DoDAF V2.0 DIV-2 Viewpoint.
  3. The Physical Exchange Specification (PES) consists of the LDM with general data types specified and implementation attributes (e.g., source, date) added, and then generated as an XSD. Represented in the DoDAF V2.0 DIV-3 Viewpoint.[4]

The purposes of the DM2 are:

  1. Establish and define the constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes
  2. Specify the semantics and format for federated EA data exchange between:architecture development and analysis tools and architecture databases across the DoD Enterprise Architecture (EA) Community of Interest (COI) and with other authoritative data sources
  3. Support discovery and understandability of EA data:
    1. Discovery of EA data using DM2 categories of information
    2. Understandability of EA data using DM2’s precise semantics augmented with linguistic traceability (aliases)
  4. Provide a basis for semantic precision in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.[4]

The DM2 defines architectural data elements and enables the integration and federation of Architectural Descriptions. It establishes a basis for semantic (i.e., understanding) consistency within and across Architectural Descriptions. In this manner, the DM2 supports the exchange and reuse of architectural information among JCAs, Components, and Federal and Coalition partners, thus facilitating the understanding and implementation of interoperability of processes and systems. As the DM2 matures to meet the ongoing data requirements of process owners, decision makers, architects, and new technologies, it will to a resource that more completely supports the requirements for architectural data, published in a consistently understandable way, and will enable greater ease for discovering, sharing, and reusing architectural data across organizational boundaries.[4]

To facilitate the use of information at the data layer, the DoDAF describes a set of models for visualizing data through graphic, tabular, or textual means. These views relate to stakeholder requirements for producing an Architectural Description.[4]

Relationship to other architecture frameworks

The UPDM (Unified Profile for DoDAF and MODAF) is an OMG initiative to standardize UML and SysML usage for USA and UK defense architecture frameworks. In addition, the multi-national IDEAS Group, which is supported by Australia, Canada, Sweden, UK, USA, with NATO observers, has launched an initiative to develop a formal ontology for enterprise architectures.

See also

Commercial Products Support

Several commercial products have support for DODAF, including the following.

References

  1. ^ a b c d e f g h DoD (2007) DoD Architecture Framework Version 1.5. 23 April 2007
  2. ^ (reference: Zachman Framework)
  3. ^ "Architecture Framework FAQ". http://architectureframework.com/faq/. Retrieved 2007-08-07. 
  4. ^ a b c d e f "DoDAF Meta Model (DM2)". http://cio-nii.defense.gov/sites/dodaf20/DM2.html. 
  5. ^ DoDAF 1.5 is presented in three volumes and a deskbook:
    • DoDAF 1.5 Volume 1 - Provides definitions, guidelines, background material.
    • DoDAF 1.5 Volume 2 - Describes each architecture product.
    • DoDAF 1.5 Volume 3 - Provides the architecture data description.
    • DoDAF 1.0 Deskbook - Provides supplementary "how to" information relating to architectures. The DODAF architecture documents were updated on April 23, 2007 to version 1.5. Currently the Deskbook, which is from February 9, 2004, has not been updated. This link is only to the Final Draft version August 30, 2003 - not the Feb 9, '04 version
  6. ^ http://cio-nii.defense.gov/docs/DoDAF%20V2%20-%20Promulgation%20Memo.pdf
  7. ^ http://cio-nii.defense.gov/sites/dodaf20/
  8. ^ Diagram of DoDAF V2.0 Viewpoints
  9. ^ Evolution of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints
  10. ^ Mapping of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints
  11. ^ DoDAF V1.5 Products Matrix

Further reading

DoDAF V2.0 Resources

Management, Privacy Impact Assessments, the inventory of MC/ME/MS systems, and the registry for systems under DoDI 5000.2. The Systems metadata from the Architecture can be used to populate DITPR with new or updated information. DITPR can also populate the architecture’s Systems metadata, particularly on systems that interface with systems described in the architecture, but are not part of the scope of the architecture.

systems/service functionality supporting joint capability. The JCSFL is provided for mapping functions to supported activities and the systems or services that host them. Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6212.01E prescribes the JCSFL for use in developing a common vocabulary for architecture development. Use the taxonomy to align or extend system functions within the architecture being developed

documents that are necessary for Milestone Decisions have architecture information. As the architecture development progresses, the collected architecture information can be extracted and reported in the required documents.

reference data tables and related metadata information The Resource Flows and Physical Schemas from the Architecture can be used to populate the Metadata Registry.

concurrence and standardization for an integrated architecture. They comprise the lexicon for the three views of the architecture framework, the operational (OV), system (SV) and technical standards (TV) views. The use of the critical taxonomies is a step to ensuring integration of systems within a system of systems and alignment of information technology (IT) functionality to mission and operational needs. The data contained in each element of the Architecture list shall be used for overall architecture framework development, programmatic research, development, and acquisition activities, and related integration and interoperability and capability assessments. It will be updated through review periods to support DoN Program Objective Memorandum (POM) efforts and to reflect changes mandated by DoD, technology improvements, and other factors.

metadata from the Architecture effort can be used to populate the Service Registry in the process of developing the solution.

common reference system for joint force commanders, combat support agencies, operational planners, combat developers, and trainers to communicate mission requirements. It is the basic language for development of a joint mission essential task list (JMETL) or agency mission essential task list (AMETL) that identifies required capabilities for mission success. Use the taxonomy to align or extend operational activities within the architecture being developed.

External links