DODAF - DOD Architecture Framework Version 2.02 - DOD Deputy Chief Information Officer

DoDAF Viewpoints and Models

All Viewpoint

AV-2: Integrated Dictionary. The AV-2 presents all the metadata used in an architecture. An AV-2 presents all the data as a hierarchy, provides a text definition for each one and references the source of the element (e.g., DoDAF Meta-model, IDEAS, a published document or policy).

An AV-2 shows elements from the DoDAF Meta-model that have been described in the Architectural Description and new elements (i.e., not in the DM2) that have been introduced by the Architectural Description.

It is essential that organizations within the DoD use the same terms to refer to a thing. Because of the interrelationship among models and across architecture efforts, it is useful to define common terminology with common definitions (referred to as taxonomies) in the development of the models within the Architectural Description. These taxonomies can be used as building blocks for DoDAF-described Models and Fit-for-Purpose Views within the Architectural Description. The need for standard taxonomies derives from lessons learned from early DoD Architectural Description development issues as well as from federation pilots conducted within the Department. Federation of Architectural Descriptions were made much more difficult because of the use of different terminology to represent the same architectural data. Use of taxonomies to build models for the architecture has the following benefits over free-text labeling:

  • Provides consistency across populated views, based on DoDAF-described Models.
  • Provides consistency across Architectural Descriptions.
  • Facilitates Architectural Description development, validation, maintenance, and re-use.
  • Traces architectural data to authoritative data sources.

This is facilitated by the DM2. Architectural Descriptions can often introduce new terms - possibly because the architecture is covering new technology or business activities. The purpose of the AV-2 is to provide a means to explain the terms and abbreviations used in building the architecture and, as necessary, submit them for review and inclusion into authoritative vocabularies developed by COIs that are pertinent to the Architectural Description content.

In the creation of any Architectural Description, reuse of authoritative external taxonomy content, e.g., the FEA Reference Models, or the Joint Common System Function List, or any listed in Architecture Resources, are important to aligning the architectural content across many descriptions to increase their understandability, interoperability, Architecture Federation, and compliance. A discussion on the use of taxonomies in the development of the AV-2 and the architecture effort is below.

Detailed Description:

The AV-2 content can be organized by the following areas within the DM2 that can be used to expedite architecture development:

  • Capabilities: The taxonomy should minimally consist of names, descriptions, and conditions that may be applicable to performance measures.
  • Resource Flow. The taxonomy should minimally consist of names of information elements exchanged, descriptions, decomposition into constituent parts and subtypes, and mapping to system data elements exchanged.
  • Activities (Operational Activities or Tasks). The taxonomy should minimally consist of names, descriptions, and decomposition into the constituent parts that comprise an activity.
  • Activities (System or Service Functions). The taxonomy should minimally consist of names, descriptions, and decomposition into the constituent parts that comprise a system function.
  • Performance Parameters. The taxonomy should minimally consist of names, descriptions, units of measure, and conditions that may be applicable to performance parameters.
  • Performers: Performers can be persons, services, systems or organizations. The taxonomy should minimally consist of names, descriptions, breakdowns into constituent parts (e.g., a services comprising other services), and applicable categorizations. Each of the above types of performers is a candidate for a being a taxonomy.
  • Skills: The taxonomy should minimally consist of names, descriptions, units of measure, and conditions that may be applicable to performance parameters.
  • Standards: The taxonomy should minimally consist of categories of standards (e.g., DoD Information Technology Standards and Profile Registry [DISR]'s Service Areas).
  • Triggers/Events: The taxonomy minimally consists of names, descriptions, and breakdown into constituent parts of the event or trigger and categorization of types of events or triggers.

Not all architectural data in a given taxonomy is useful in every case of architectural development. However, given the ongoing evolutionary change in organizations, services, systems, and activities, the value of using established, validated taxonomic structures that can be expanded or contracted as needed becomes obvious. Moreover, the development of new models over time is greatly simplified as understanding of the taxonomies is increased. Standard taxonomies, like DISR Service Categories, become building blocks for more comprehensive, quality architectural DoDAF-described Models and Fit-for-Purpose Views. The DoD Extensible Markup Language Registry and Clearinghouse and the Net-Centric Implementation Document (NCID) are potential sources for taxonomies.

In some cases, a specific community may have its own operational vocabulary. This local operational vocabulary may use the same terms in radically different ways from other operational communities. (For example, the use of the term track refers to very different concepts in the carrier battle group community than in the mine-sweeper community. Yet both of these communities are Navy operational groups and may participate together in littoral warfare task forces.) In these cases, the internal community versions of the models and views within the Architectural Description should use the vocabulary of the local operational community to achieve community cooperation and buy-in. Data elements need to be uniquely identified and consistently used across all viewpoints, models and views within the Architectural Description. These populated views should include notes on any unique definitions used and provide a mapping to standard definitions, where possible.

<< AV-1: Overview and Summary Information