Introduction to DoD Architecture Framework (DoDAF)

1
Beverly Hawks
2
Jonnathan Kim

What is this paper?

This paper, “Introduction to the DoD Architecture Framework (DoDAF)”, is an ultra-brief

overview of DoDAF. The intent is to provide potential users a quick overview of DoDAF and related
architecture products. DoDAF provide a framework to completely describe system specifications, design
processes, trade parameters, etc.

What is DoDAF?
Modern day warfighting operations involve complex sets of hardware, software, and users. In
describing the development and integration of such complex systems, it is necessary to provide a common
and consistent approach to describe the systems and processes. DoDAF provides guidance for describing
architectures for warfighting operations, business operations, and processes. [1] Utilizing this framework
provides a common approach for architecture description, development, presentation, and integration.

Before going further in describing this common approach, it is necessary to understand the term
“architecture” which is frequently used, and often misused. IEEE 610.12 defines architecture as the
organizational structure of a system and component. Based on this definition, the DoD Integrated
Architecture Panel defines architecture as the structure of components, their relationships, and the
principle and guidelines governing their design and evolution over time. IEEE STD 1471-2000 also states
“An architecture is the fundamental organization of a system embodied in its components, their
relationships to each other, and to the environment, and the principles guiding its design and evolution.”
From this definition, we can further expand the description of the architecture framework as a tool which
should describe a method for designing an information system in terms of a set of building blocks, and
for showing how the building blocks fit together. It should contain a set of tools and provide a common
vocabulary. It should also include a list of recommended standards and compliant products that can be used
to implement the building blocks.

Where is the beef?

How does DoDAF help us describe a system or a process? First of all, DoDAF defines the
perspectives from which a system is described. Figure 1 depicts three views. A system can be described
from the operational perspective. The product generated from the operational perspective is termed
Operations View. The OV describes the tasks, activities, operational elements, and information exchanges
required to accomplish a DoD mission. The System View (SV) describes an architecture in terms of
systems and interconnections to accomplish a DoD mission. The Technical View (TV) is a set of rules
and standards governing the arrangement, interaction, and interdependency. The TV provides a set of rules
and standards to promote efficiency and interoperability in TV-1 and to ensure that developers can
adequately plan for evolution in TV-2. The All View (AV) describes the overarching aspects of the
architecture that are pertinent to all the views but are not specific to a single view. The complete set of the
views is delineated in Table 1. As shown in the table, there are many products that constitute the DoDAF
views.

1 2
EPG, hawks@epg.army.mil . GaN Corporation, jkim@GaNcorp.com
 Activities Operationa
/ Operationa l
Tasks l Elements
View

Information
Flow

System Data Flow Standard Rule

s s s
System Technical
s Standards View
XY
X
Y
View Z

Y
X

Communication Convention
s s
Figure 1. DoDAF Views (Reference [1])

[Note: Reference [1] does not show the AV’s in Figure 1.]

Each view product is inter-related to other view products to provide a complete picture of a
system. For example, the SV-5 relates operational activities from the OV-5 to system functions from SV-4;
the SV-4 system functions are related to systems in the SV-1; thus bridging the operational and systems
views. The high-level operational concept should drive the OV; the OV in turn drives the SV to identify
shortfalls and systems requirements, and the SV requirements drive the TV to address a common set of
applicable standards. To be internally consistent and integrated, an architecture description must
provide explicit linkages among its various views. [1] It is important to note that it is possible use a
subset of these views to completely describe a system or a process. It is up to the architects to define a set
of appropriate views for the intended use of the architecture.

How do we generate the views?

Each view is generated with graphics, tables, or text to completely describe the specified objective
of the view. Reference [1] provides a general guideline of 5 steps for building architecture descriptions.
They are:

Step 1: Determine the intended use of the architecture description.

Step 2: Determine the architecture description’s scope, context, environment, and any other assumptions to
be considered.
Step 3: Determine what information the architecture description needs to capture based on the intended use.
Step 4: Determine products to be built.
Step 5: Gather the architecture data and build the requisite products.
 For each view, the architecture of interest is described from that perspective. OVs should provide
information about the operational node (who is responsible for the process) and information flow among the
operational nodes. The SVs identify what the systems are, how they are connected, and what they do. As
an example, the OVs can describe how organizations and people work together to accomplish a mission.
The SVs can describe what specific systems are utilized to accomplish the mission. The TVs describe a set
of specifications of the relevant technologies that are exiting (TV-1) and forecasted (TV-2).

These architectural products are graphical or textual representations of the data sets which define
various attributes of the architecture. Since a given data element will frequently occur in more than one
products, it is crucial to build a consistent set of data elements. For example, a data element table can
define data attributes such as types and characteristics.

The notation and format to generate the views can vary depending on applications and users.
However, for objective oriented (OO) applications, the Unified Modeling Language (UML) is often used as
the standard method of representation. Reference [2] describes how UML is used to document OVs and SVs
in detail.

When the DoDAF architecture products are being developed, it is crucial to retain the information
that describes the scope and complexities of the architectural data and data relationship for visualizing and
understanding. There are standard formats and automated tools available to document the views. The All-
DoD Core Architecture Data Model (CADM) was developed as the DoD standard architecture data model
for Framework based architecture data elements. For development of the products, DoDAF does not specify
or advocate a methodology or a notation, but DoDAF provides guidance for the products to contain the
required instances of data elements and relationships.

What have we done?

We at EPG have developed architecture products, per DoDAF guidance, consisting of graphical
and textual items providing an architecture description of characteristics pertinent to our Test Tool Kit for
C4I testing. Our architecture flows into the ATEC testing architecture to complete test and evaluation
requirements.

Where do I get more information?

There are two main volumes of DoD Architecture Framework Version 1.0. These volumes are
available on the web www.defenselink.mil/nii/doc/. Also, there are many publications and classes available
to learn about DoDAF.

References:
[1] DoD AF Vol 1, Definitions and Guidelines, 9 February 2004.
[2] DoD AF Vol 2, Production Description, 9 February 2004.
Framework Applicable
Product View Framework Product Name General Description
AV-1 All Views Overview and Summary Scope, purpose, intended users, environment depicted,
Information analytical findings
AV-2 All Views Integrated Dictionary Architecture data repository with definitions of all terms used in
all products
OV-1 Operational High-Level Operational High-level graphical/ textual description of operational concept
Concept Graphic
OV-2 Operational Operational Node Connectivity Operational nodes, connectivity and information exchange
Description needlines between nodes
OV-3 Operational Operational Information Information exchanged between nodes and the relevant
Exchange Matrix attributes of that exchange
OV-4 Operational Organizational Relationships Organizational, role, or other relationships among organizations
Chart
OV-5 Operational Operational Activity Model Capabilities, Operational Activities, relationships among
activities, inputs and outputs. Overlays can show cost,
performing nodes, or other pertinent information
OV-6a Operational Operational Rules Model One of the three products used to describe operational activity—
identifies business rules that constrain operation
OV-6b Operational Operational State Transition One of three products used to describe operational activity—
Description identifies business process responses to events
OV-6c Operational Operational Event-Trace One of three products used to describe operational activity—
Description traces actions in a scenario or sequence of events
OV-7 Operational Logical Data Model Documentation of the system data requirements and structural
business process rules of the Operational View.
SV-1 Systems Systems Interface Description Identification of systems nodes, systems, and system items and
their interconnections, within and between nodes
SV-2 Systems Systems Communications Systems nodes, systems, and system items, and their related
Description communications lay-downs
SV-3 Systems Systems-Systems Matrix Relationships among systems in a given architecture; can be
designed to show relationships of interest, e.g., system-type
interfaces, planned vs. existing interfaces, etc.
SV-4 Systems Systems Functionality Functions performed by systems and the system data flows
Description among system functions
SV-5 Systems Operational Activity to Mapping of systems back to capabilities or of system functions
Systems Function Traceability back to operational activities
Matrix
SV-6 Systems Systems Data Exchange Provides details of system data elements being exchanged
Matrix between systems and the attributes of that exchange
SV-7 Systems Systems Performance Performance characteristics of systems view elements, for the
Parameters Matrix appropriate timeframe(s)
SV-8 Systems Systems Evolution Description Planned incremental steps toward migrating a suite of systems
to a more efficient suite, or toward evolving a current system to
a future implementation
SV-9 Systems Systems Technology Forecast Emerging technologies and software/hardware products that are
expected to be available in a given set of timeframes, and that
will affect future development of the architecture
SV-10a Systems Systems Rules Model One of three products used to describe systems functionality—
identifies constraints that are imposed on systems functionality
due to some aspect of systems design or implementation
SV-10b Systems Systems State Transition One of three products used to describe systems functionality—
Description identifies responses of a system to events
SV-10c Systems Systems Event-Trace One of three products used to describe systems functionality—
Description identifies system-specific refinements of critical sequences of
events described in the operational view
SV-11 Systems Physical Schema Physical implementation of the Logical Data Model entities, e.g.,
message formats, file structures, physical schema
TV-1 Technical Technical Standards Profile Listing of standards that apply to systems view elements in a
given architecture
TV-2 Technical Technical Standards Forecast Description of emerging standards and potential impact on
current systems view elements, within a set of timeframes

Table 1. DoD AF Products

 APPENDIX 1

Electronic Proving Ground DoDAF Products