DoDAF v2.02 CHG 1 Vol I Final 2015-01-19

DRAFT
wreath
stars
Text
DoD Architecture Framework

Version 2.02, Change 1
Volume I: Overview and Concepts
Manager’s Guide
31 January 2015
DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

DRAFT
This page left intentionally blank

DoDAF v2.02, Chg 1 DRAFT 31 January 2015
Change 1 Description
DoDAF has had three incremental updates since the main release of DoDAF 2.0. Release 2.02,
Chg 1 is primarily a result of the hard work and efforts of the Components in making
refinements to existing content or from adding content provided by the architecture community
on experimental techniques for organizing, sharing, and understanding the data in architectural
descriptions. The United States Marine Corps (USMC) provided the predominant change
through their revisions to the model descriptions in Volume II. Volume IV, from the Defense
Chief Management Office (DCMO), provides new techniques and discussions for using DoDAF
in conjunction with OWL and semantic web. Content location changes from Version 2.02 now
keep information about specific topics in one place.
The DoDAF version 2.02, with its accompanying meta model, the DoDAF Meta Model (DM2),
was baselined in October 2010. Improvements and corrections have been collected from the
DoD EA community. These were logged and tracked by the DoDAF - DM2 Work Group (WG)
secretariats following the processes and procedures documented in DoDAF - DM2 Configuration
Management Plan. These were prioritized and adjudicated by the DoDAF - DM2 WG in a
consensual manner though weekly DoDAF - DM2 WG meetings. WG actionees implemented
the changes as per WG adjudication and reported back to the WG for WG review of the
implementation.
There were 69 DoDAF-DM2 Action Items / Change Requests resolved by version 2.02, Chg 1.
These are shown in detail in the table in Appendix C. Listed below is a summary of the changes
for this release:
• Updated the definition of DoDAF Conformance to four levels – Conceptual, Logical,
Physical, and Semantic. v2.02 was tantamount to Physical only. (CR 620
• Technical editing of the DoDAF model (view) descriptions (“TECHEDITS”) in response
to, 1) comments submitted by Marine Corps on undefined terms, inconsistencies, and
false statements, 2) SPAWAR markup of 100’s of undefined terms in the DoDAF model
descriptions. WG concluded after initial batch that a TECHEDIT team needed to re-write
the model descriptions using defined terms and to be consistent with DM2. (CR’s 28,
428, 621, 625, 663, 665, 666, 667, 668, 669, 670, 671, 672)
• DM2 diagram per DoDAF model (CR 316)
• Normative parts of document separated from informative parts (CR 636
• Description of Rules and Desired Effect. Their Descriptions are produced by rule and
goal-setting authorities. They are consumed by Activities (aka Controls in IDEF0).
Distinguished that Guidance influences Activity from Rules that control Activity.
Activities that conform to Rules are subtypes of the Rule. (CR 383a/615, 537, 539a, 610,
617)
DoDAF v2.02, Chg 1 DRAFT 31 January 2015
• Information resource flow and associations were simplified into flatter type structure so it
would be logically correct and consistent with other Resource Flows. (CR 642/652)
• Capability made a subtype of Property so that it is the set of Tasks performed under
Conditions that meet certain performance standards (Measures). Also refined the Desired
Effect of a Capability to be a Resource (state) that is desired by some
PerformerCapableOfResponsibility. This makes Capability comparison and
dependencies more direct as property intersections and Resource (state) overlaps. (CR
406/604, 453, 538, 598, 603, 605)
• Added SoA Joint Action concept and distinguished business services from enabling
services (CR 597)
• Refined rules for superclass association usage (CR 503, 618)
• Continued work on refinement of meaning of Services. ( CR 151
• Relationship between Context and Condition clarified. (CR 91)
• Resources in LocationTypes and ResourceTypes in Locations clarified (CR 643)
• Several Data Dictionary and Alias corrections, e.g., Ways. (CR 414, 449/520, 549, 630)
• Several IDEAS Foundation corrections. (CR 295, 408, 439, 464, 484, 494, 497, 517,
541, 544, 548, 573, 595, 600, 606, 607, 609, 612, 619, 647)
• Several minor PES corrections (CR 405, 566a, 622, 641, 649)
• DoDAF website and FAQ improvements (CR 593, 402)
DoDAF v2.02, Chg 1 31 January 2015
Executive Summary
The Department of Defense Architecture Framework (DoDAF) is the overarching,
comprehensive framework and conceptual model for architectural descriptions developed within
the DoD. This framework helps Department of Defense (DoD) managers at all levels make
effective decisions by ensuring the sharing of consistent and common information across the
Department, Joint Capability Areas (JCAs), missions, components, and programs. The DoDAF
helps the DoD Chief Information Officer (CIO) develop and maintain architectures required by
the Clinger-Cohen Act. It also fulfills guidance from the Office of Management and Budget
(OMB) and other Departmental directives and instructions.
The DoDAF supports DoD’s core decision-making processes, including the Joint Capabilities
Integration and Development System (JCIDS), the Defense Acquisition System (DAS), Systems
Engineering (SE), the Planning, Programming, Budgeting, and Execution (PPBE) Process,
Capabilities Portfolio Management (CPM), and Operations (OPS).
DoD Components should conform to the DoDAF when they develop architectures within the
Department.
The DoDAF allows architectural artifacts to be fit-for-purpose, that is, to be defined and
described consistently with specific project or mission decision-making needs. Because
architectural descriptions are employed at many levels, contexts, and purposes within the DoD,
they vary in content, structure, and level of detail. Basing the architectural description
development on well-articulated and understood purposes will ensure that the necessary data
collection occurs at the appropriate level of detail to support specific decisions.
The DoDAF focuses on architectural data rather than architecture artifacts. It identifies, defines,
and specifies the information needed to describe something in architectural terms within DoD.
There is a wide range of architecture tools developed by commercial sources that can collect,
organize, and store architecture data. The focus on data supports the production of fit-for-
purpose models tailored for multiple uses. It also supports analysis and simulation of
architectural description content produced across Components to support DoD’s core decision
making processes. Consequently, tools should use the DoDAF Meta Model (DM2)
specifications to exchange architectural data.
Models visualize architecture data. A model, displayed as diagrams, narrative text, matrices,
tables, dashboards, or other representations, serves as a template for organizing and displaying
data in a format appropriate for a decision-maker. Viewpoints are thematic collections of
models. A viewpoint focuses on data within the scope of some concern, such as capabilities,
systems, or standards. A set of viewpoints, accompanied by useful definitions of the terms they
use, is an architectural description.
The DoDAF specification comprises four volumes.
• Volume I, the manager’s volume, provides general information and guidance for
development, use, and management of DoD architectures. This volume explains the role
of architecture within core DoD processes and key DoD architecture concepts are
identified and defined.
• Volume II, the architect’s volume: 1) defines architectural viewpoints and models, and 2)
specifies the DM2 at a conceptual and logical level, through an elaboration of the key
concepts. Models depict a subset of architectural data within a viewpoint. Once
populated with data, models associated with the viewpoint can present these data. The
DoDAF specifies over 50 standard models within eight viewpoints. The DM2 supports
creating additional custom, fit for purpose, models to present architectural data within or
across viewpoints for specific stakeholders and their specific needs.
• Volume III, the developer’s volume, discusses the ontological foundation for DM2 and
specifies the physical level format for the exchange of DoDAF-compliant architectural
data. This volume is for developers of architectural description analytics, tools,
databases, repositories, and simulations.
• Volume IV, the DoDAF Journal, publishes descriptions of other best practices, lessons
learned, and reference documents that supplement the information contained in the three
volumes of the DoDAF, including a discussion of the DoDAF OWL exchange
specification. This volume provides information only and is not part of DoDAF
conformance.
Table of Contents
1 Introduction 1-1
1.1 Vision for the DoDAF 1-1
1.2 Purpose 1-1
1.3 Scope 1-3
2 DoDAF Volume Organization and Intended Audience 2-1

2.1 Volume I — Introduction, Overview, and Concepts 2-1
2.2 Volume II — Architectural Data and Models 2-1
2.3 Volume III — DoDAF Meta Model Ontology Foundation and Physical
Exchange Specification 2-1
2.4 Volume IV — DoDAF Journal 2-2
3 What DoD Managers and Executives Need to Know About DoDAF 3-1
3.1 Developing Architectures 3-2
3.2 Maintaining and Managing Architectures 3-3
3.3 Using Architectures 3-4
3.4 DoDAF Conformance 3-4
4 DoDAF Structure 4-1

4.1 Architectural Data 4-1
4.1.1 The DoDAF Conceptual Data Model (CDM) 4-2
4.2 Architecture Viewpoints and DoDAF-described Models 4-6
4.2.1 All Viewpoint 4-6
4.2.2 Capability Viewpoint 4-7
4.2.3 Data and Information Viewpoint 4-7
4.2.4 Operational Viewpoint 4-7
4.2.5 Project Viewpoint 4-7
4.2.6 Services Viewpoint 4-7
4.2.7 Standards Viewpoint 4-7
4.2.8 Systems Viewpoint 4-8
4.2.9 Standard Models 4-8
DRAFT i
Appendix A Acronyms & Abbreviations A-1
Appendix B Glossary of Conceptual Level Terms B-1
Appendix C Record of Changes for Change 1 C-1
ii
List of Figures
Figure 3-1. Architecture Manager Roles .......................................................................... 3-2

Figure 4-1. DoDAF Meta Model at the Conceptual Level ......................................... 4-2
Figure 4-2. Overview of DM2 Ontologic Foundation.................................................. 4-5
Figure 4-3. Architecture Viewpoints in the DoDAF ..................................................... 4-6
List of Tables
Table 4-1. DoDAF Standard Models ................................................................................ 4-9
DRAFT iii
1 INTRODUCTION
The Department of Defense Architecture Framework (DoDAF) is the overarching,
comprehensive framework and conceptual model for architectural descriptions developed within
the DoD. The DoDAF is the structure for organizing architecture concepts, principles,
assumptions, and terminology about operations and solutions into meaningful and consistent
patterns to satisfy specific DoD purposes. The DoDAF offers guidance, principles, and direction
on communicating business and mission needs and capabilities to managers, architects, analysts,
and developers who are responsible for developing and building the necessary systems, services,
applications, and infrastructure to meet stakeholder needs and to manage their expectations.
This framework helps DoD managers at all levels make effective decisions by sharing
information across the Department, Joint Capability Areas (JCAs), missions, components, and
programs. The DoDAF focuses on the collection, presentation, and sharing of architectural data
as information required by DoD decision makers, rather than on developing individual models.
Architects may use the standard models described in this Volume I and specified in Volume II to
obtain and visualize architecture data. However, the framework also allows architects to build
other, fit-for-purpose (FFP) products for an architectural description.
1.1 Vision for the DoDAF
The vision for use of the DoDAF is to:

• Provide architecture concepts to guide development of architectures throughout the
Department in support of decision processes for departmental programs, military
components, and capability areas. This guidance is consistent with federal enterprise
architecture guidance provided by OMB.
• Focus on architectural data as information required for making critical decisions and de-
emphasize individual or independent architecture models. Allow architects to visualize
architectural information using both standard models and fit-for-purpose models that are
consistent with the culture and preferences of an organization while being consistent
descriptions for consumption and use by the entire Department.
1.2 Purpose
The purposes of DoDAF are as follows.

a. DoDAF supports the Department of Defense Chief Information Officer (DoD CIO)
efforts to develop and maintain architectures as required by the Clinger-Cohen Act.
From a compliance perspective, federal law and policy (i.e., Clinger-Cohen Act, OMB
Circular A-130) require architectures to support investment decisions. The Office of
Management and Budget (OMB) annually evaluates agency efforts to improve the
quality and usefulness of information technology investments requested by agencies
1-1
through well-organized strategic decisions relating to investments and Portfolio

Management. This process evaluates the use of enterprise architectures as the principal
means of meeting mission requirements, while achieving savings and cost avoidance
goals. Each agency is required to adopt an existing architecture framework or to create
one for that purpose. The DoDAF is the designated architecture framework for DoD
architecture development.
b. DoDAF supports DoD’s core decision-making processes, including the Joint
Capabilities Integration and Development System (JCIDS), the Defense Acquisition
System (DAS), Systems Engineering (SE), the Planning, Programming, Budgeting, and
Execution (PPBE) Process, Capabilities Portfolio Management (CPM), and Operations
(OPS). These key processes produce far-reaching change across all Military
Departments, Agencies, the Joint Staff, and other Departmental functions.
c. The framework is consistent with, and supports DoD policy directives that require
programs and components to (a) ensure that their architectures meet stated objectives
and departmental requirements, and, (b) provide the information necessary to support
defined decisions at higher tiers. These policies also require consistency across
horizontal architecture boundaries within a tier. The guidance and information contained
in these volumes also ensures that, when followed, architecture development is
consistent with OMB guidance on enterprise architecture.
d. This version of the DoDAF supports the Departmental preference for federated
architecture development in a tiered environment. To enable federation and support
tiered responsibility and accountability, the framework provides data structures for
comparing appropriate touch-points for consistency across architecture boundaries. Use
of these data structures ensures that higher tiers have access to data from lower tiers in a
form that supports their decision needs.
e. Architecture frameworks support change in organizations through building and using
architectures that:
• Enhance decision making processes by leveraging knowledge in existing
architectures and opportunities for reusing existing information assets.
• Respond to stakeholder, customer, and client needs for effective and efficient
processes, systems, services, and resource allocation.
• Provide mechanisms to manage configuration of the current state of the enterprise
and to maintain validity of the expected performance.
• Analyze designs for future states of the enterprise.
• Establish baseline architectures for solutions under development.
1-2
f. From a practical perspective, an organization that pursues complex ends with

sophisticated people, systems, services, and technologies needs comparably complex
architectures to evaluate and compare investments. Such an organization also uses
architectures to build new systems, deploy new technologies, offer new services, and
guide change to the organization itself.
g. The DoDAF also helps architects develop SOA-based architectural descriptions that
define solutions specifically in terms of services for discovery and use in executing
departmental or joint functions and requirements.
h. The DoDAF establishes a common vocabulary for architecture development and for the
exchange of architecture information.
1.3 Scope
Guidance provided by the DoDAF applies to all architectures developed, maintained, and used
within the DoD. The DoDAF is also the basis for tiered architecture federation, shared
architecture information, and a federated enterprise architecture describing the Department.
1-3
2 DODAF VOLUME ORGANIZATION AND INTENDED AUDIENCE

The DoDAF has four volumes.
2.1 Volume I — Introduction, Overview, and Concepts
Primary audience: executives, project directors, and managers.

Volume I introduces DoD architecture concepts and provides general guidance for development,
use, and management of DoD architectures. This volume explains the role of architecture within
core DoD processes. Volume I identifies and defines key DoD architecture concepts.
Volume I contains the following resources:
• An overview and vision for DoDAF.
• An overview of the framework.
• Defining fit-for-purpose architectures.
• Introduction to the DoDAF Meta Model and identification and definition of key DoD
architecture concepts.
2.2 Volume II — Architectural Data and Models
Primary audience: architects, program managers, portfolio managers, systems engineers,

capability analysts and testers, and other technically oriented architecture users
Architects, modelers, and technical designers need to know what sorts of things can be modeled
and the sorts of relationships among those things. Volume II describes the DoDAF meta-model,
meta-model data groups, DoDAF viewpoints, and standard DoDAF models. The DoDAF meta-
model specifies the sorts of things that can be modeled and the relationships among those things.
Appendices to Volume II contain the DoDAF Glossary and references.
2.3 Volume III — DoDAF Meta Model Ontology Foundation and Physical Exchange
Specification
Primary audience: developers of architectural description analytics, tools, databases,

repositories, and simulations
Volume III discusses the ontological foundation for DM2 and specifies the physical level format
for the exchange of DoDAF-compliant architectural data. These technical tools provide different
ways to exchange architectural information among stakeholders.
2-1
2.4 Volume IV — DoDAF Journal
Volume IV is the informative volume of the DoDAF. Volume IV includes descriptions of best
practices, lessons learned, reference documents, and other information that supplements the three
normative volumes of the DoDAF.
2-2
3 WHAT DOD MANAGERS AND EXECUTIVES NEED TO KNOW

ABOUT DODAF
Architecture development is a management tool that supports the decision-making process. A
process owner, an executive responsible for a specific process or program, has the direct
responsibility for ensuring that a particular process or program works efficiently, complies with
legal and Departmental requirements, and serves the purpose for its creation. Legislation such as
the Clinger-Cohen Act and implementing directives such as OMB Directive A-130 require
periodic review and evaluation of the maturity and effectiveness of programs and processes.
These requirements call for information architectures to support requests to fund those projects
and processes.
A manager or executive may delegate the responsibility for creation of the architecture to a
qualified architect working with an architecture development team. However, that delegation of
authority does not alter the continuing responsibility of the executive or manager. As described
throughout this volume, the decision-maker needs to be actively involved in the architecture
development process and support architectural description development. They must also approve
the architectural description for use and reference by the Department. Active involvement means
that the decision-maker:
• Identifies the purpose and scope for the architecture.
• Transmits to the architect and development team the scope and purpose of the
architecture effort, along with those goals and objectives that support the need.
• In conjunction with the architect, identifies the general data categories needed for
architecture development, and assists in data collection and validation.
• Determines desired views and presentation methods for the completed architecture.
• Meets frequently with the architect and development team to ensure that the development
effort is on target (i.e., is fit-for-purpose) and provides new direction, as required to
ensure that the development effort meets established requirements.
Working with the architect and team, the decision-maker has a critical role in ensuring that the
architecture not only supports the creation of executable requirements that will achieve the
desired outcome, but also that senior executives and managers can view the solution in an
understandable and logical manner.
3-1
Figure 3-1. Architecture Manager Roles
3.1 Developing Architectures
Careful scoping and organization by managers of the architecture development effort focuses on
areas of change indicated by policy or contract in support of the stated goals and objectives. A
data-centric,
centric, rather than product
product-centric,
centric, architecture framework ensures concordance across
architectural models. Concordance means that data in one model is the same as in another model
when talking about the same exact thing, such as an activity. This enables the federation of all
pertinent architecture information, and provides data describing the same thing being the same in
all models in an architectural description (also known as full referential integrity), simplifies and
supports a wide variety off analysis tasks. Logical consistency of the data thus becomes a critical
‘property’ of architectures of all types as described more fully below. The objective of achieving
concordance across the architectural view must be included in architecture planning and
development actions.
The DoDAF describes three major types of architectures that contribute to the DoD enterprise
architecture, Mission Area architectures, enterprise
enterprise-level
level reference architectures, and Component
enterprise architectures. A fourth type
type,, solution architectures trace back to the other three types
but are not included in the DoD enterprise architecture. Each of these architectures serves a
specific purpose:
3-2
• An enterprise architecture is a strategic information asset of an organization. This asset

defines the mission of the organization, the behaviors and information necessary to
perform the mission, the resources necessary to perform the mission, and the processes
for transforming the organization and its resources to satisfy changing mission needs. An
enterprise architecture includes a baseline architecture representing the current
organization, a target architecture representing the future organization, and a plan for
moving from the present into the future.
• Enterprise level reference architectures are an authoritative source of information
about a specific subject area that guides and constrains the instantiations of multiple
architectures and solutions. It has 5 elements:
• Strategic Purpose – Identifies goals and objectives of the Reference Architecture
and describes the specific purpose of and the problem(s) addressed by the
Reference Architecture.
• Principles – Sufficient high-level foundational statements of rules, culture, and
values that drive technical positions and patterns.
• Technical Positions– Technical guidance and standards, based on specified
principles to follow and implement as part of the solution.
• Patterns (Templates) – Generalized architecture representations (viewpoints,
graphical/textual models, diagrams, etc.) that show relationships between
elements and artifacts specified by the technical positions.
• Vocabulary – Acronyms, terms, and definitions that are used in the Reference
Architecture and relevant to architectures and solutions guided and constrained by
the Reference Architecture.
• Component enterprise architectures are the description of mission-specific services
and capabilities within the Component. It portrays relationships among all elements
of a DoD Component.
• Solution architectures describe a system or other asset that an organization uses to
carry out its mission. Although not part of the DoD enterprise architecture, solution
managers use these architectures to create, update, revise, or remove resources that
are called for by the organization’s enterprise architecture. Solution architectures are
the most common type of architecture developed in the Department.
3.2 Maintaining and Managing Architectures
Embedding architecture development process in routine planning and decision-making

institutionalizes the practices of architecture and the maintenance of architectural data, models,
and viewpoints. Tiered accountability provides the means to maintain and manage architectures
3-3
within the Department. Tiered accountability is the distribution of authority and responsibility
for development, maintenance, configuration management, and reporting of architectures,
architecture policy, tools, and related architecture artifacts to all three distinct tiers within the
DoD. The DoDAF supports three tiers: Department, Mission Area (MA), and Component (i.e.,
enterprise and program or project-level solutions development). These tiers support the federated
approach for architecture development and maintenance.
3.3 Using Architectures
Architecture supports major DoD decision-making processes, including JCIDS, DAS, PPBE, SE,
and PfM processes. Architecture also supports business process reengineering, organizational
development, research and development, operations support, and service-oriented solutions.
Architectural data gives decision makers data they need to make informed decisions in those
processes.
3.4 DoDAF Conformance
The Department of Defense expects DoD architectural descriptions to conform to the DoDAF to
the maximum extent possible. Conformance ensures that reuse and sharing of information,
architecture artifacts, models, and viewpoints is possible through a shared understanding of the
underlying data. Both classified and unclassified architectural descriptions are to conform to the
DoDAF.
There are four assessment level for DoDAF conformance. Higher levels of conformance build
upon lower levels of conformance.
Level 1 — Conceptual conformance
• The architectural description uses normative DoDAF terms as defined in the DoDAF
Glossary to identify concepts. The architectural description uses these normative DoDAF
terms to describe the architecture. The AV-2 model, which is the glossary of the
architectural description, appropriately defines additional terms used to describe the
architecture. The AV-2 model complies with the DoDAF Glossary Style Manual
guidance for writing definitions.
• DoDAF standard models within the architectural description satisfy the specifications
given in Volume II.
• Stakeholders who use DoDAF fit-for-purpose models, validate them within the
architectural description.
Level 2 — Logical conformance
• The architectural description demonstrates conceptual conformance.
3-4
• The AV-2 model within the architectural description complies with the DoDAF Glossary
Style Manual guidance for constructing glossary entries and producing a glossary.
• The architectural description uses types, relationships, and properties defined by the
DoDAF meta-model to describe the architecture. The architectural description correctly
introduces and defines additional concepts, relationships, and properties used to describe
the architecture as subtypes of DoDAF meta-model concepts, relationships, and
properties.
Level 3 — Physical conformance
• The architectural description demonstrates logical conformance.
• The architectural data expressed by the architectural description is correctly produced and
consumed using a specified format to exchange architectural data. A successful DM2
PES exchange satisfies this requirement; alternatively, architecture efforts within
recognized Business Capability Lifecycle (BCL) programs may satisfy this criterion by
successful DM2 OWL-DL exchanges.
Level 4 — Semantic conformance.
• The architectural description demonstrates physical conformance.
• The architectural description correctly uses and expresses the ontological semantics of
the DoDAF meta-model.
3-5
4 DODAF STRUCTURE
The DoDAF’s focus is on data, viewpoints, and models. This approach responds to departmental
processes, such as business transformation, JCIDS, and other major functions with significant
impact throughout the Department that have developed requirements for multiple, custom
models. They use information based on authoritative data, beyond the operational, systems, and
technical views of previous versions of DoDAF. The standard models are templates for
identifying and collecting specific data within the data groups discussed in Volume II. Users
define fit-for-purpose models to explain specific data to specific audiences.
4.1 Architectural Data
Architectural data provides efficient and flexible use and reuse of architectural descriptions for
decision makers and process owners. The DoDAF metadata model (DM2) specifies a minimal
set of architectural data required to support the core DoD decision-making processes. The DM2
has several levels, each of which is important to a particular viewer of departmental processes.
The DoDAF conceptual data model (CDM) presents concepts shared by all DoDAF-compliant
architectural descriptions. The CDM is defined in this Volume I, in this paragraph and in the
Glossary in Appendix B.
The DoDAF logical data model (LDM) adds technical information and, when necessary, clarifies
relationships into an unambiguous usage definition. Volume II discusses the LDM in detail.
DoDAF data exchange comes in two forms, the Physical Exchange Specification (PES) and the
DM2-OWL specification. Volume III discusses the PES and Volume IV discusses DM2-OWL.
Data, organized as information, is the critical element of architecture development. The DoDAF
provides the DM2 CDM, LDM, and the PES and OWL exchange specifications for data
managers, tool vendors, and others to help:
• Establish areas of discourse and a shared vocabulary.
• Support data overlap analysis.
• Define and encourage the use of shared information.
• Provide a target for architectural data integration.
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 MAs, Components, and federal and coalition partners;
this helps the Department understand and build processes and systems that work well together,
particularly in the sharing of information (interoperability).
4-1
4.1.1 The DoDAF Conceptual Data Model (CDM)
The
he DoDAF conceptual data model (CDM) presents concepts shared by all DoDAF-compliant
DoDAF
architectural descriptions. Key concepts of the CDM are illustrated in Figure 4-1.
4 This diagram
may be read in a straightforward way as simple sentences, with the subject and object in the
ovals and the predicate on the lines, as follows:
Figure 4-1. DoDAF Meta Model at the Conceptual Level

• An activity consumes and produces resources. An interesting activity always produces an
interesting resource. In general, an interesting activity also consumes interesting
resources. However, consumed resources ar aree not necessarily architecturally interesting.
• An activity is performed by some performer.
• A performer is a sort of resource that performs an activity.
4-2
• An activity can produce a resource that performs another activity. Some activities, such
as projects, are interesting just in that they produce performers that can realize
capabilities.
• An activity is constrained by some guidance. Guidance forestalls random behavior.
Proceeding by trial and error is not a best practice in anything we do.
• A rule is a sort of guidance.
• A standard is a sort of rule, and thus a standard is a sort of guidance.
• An agreement is a sort of rule, and thus an agreement is a sort of guidance.
• An activity is performed under some condition. Conditions affect the way a performer
can carry out an activity, and conditions are seldom perfect in the real world.
• An activity is performed at some location. Locations are important for activities because
they entail possible conditions.
• A resource exists at some location. Locations are important for resources because we
cannot rely upon resources whose locations are unknown or unknowable.
• A geopolitical place is a sort of location.
• Materiel is a sort of resource. The DoDAF notion of materiel encompasses anything a
performer uses to get a job done.
• A system is a sort of performer, and thus a system is a sort of resource.
• A service is a sort of performer, and thus a service is a sort of resource.
• An organization is a sort of performer, and thus an organization is a sort of resource.
• A person in a role is a sort of performer, and thus such a person is a resource.
• A performer can be a complex of systems, services, organizations, and persons in roles.
• A person in a role may be a part of a system.
• A person in a role may be a part of a service.
• A person in a role may be a part of an organization.
• Materiel may be a part of a performer.
• Information describes something. Specifically, information describes activities, guidance,
conditions, resources, locations, and capabilities.
• Information is a sort of resource.
4-3
• Data is a sort of information, and thus data is a sort of resource. Data that is not used to
describe activities, guidance, conditions, resources, locations, or capabilities is not
architecturally interesting.
Further, the DoDAF conceptual data model inherits from the IDEAS ontology so that:
• Everything of architectural interest has four dimensions, that is, they exist in space and
time. All the pieces and parts of a described architecture must be founded upon things
that are real in the world.
• Everything of architectural interest has parts. In particular, everything has both temporal
parts and spatial parts. This is the basis for asserting the identity of a whole as its parts
change over time.
• Everything of architectural interest is a sort of something. Indeed, any given thing can be
a sort of many different things at the same time and over time.
• Everything of architectural interest has measures. Something that exists in space and time
can be observed. Anything that can be observed can be measured. At a minimum, we can
measure the size and the position of any real thing of architectural interest.
Together, these concepts cover the notions needed to discuss all aspects of architectural
description in DoD. For example, capabilities as defined by Joint doctrine:
A capability is the ability to achieve a desired effect under specified standards and
conditions through combinations of means and ways to perform a set of tasks.
A desired effect is a measurable change in the state of resources we see in someplace in the
world. Activities consume resources in one state and produce resources in another state.
Performers perform activities that change the state of resources. Performers do this under
conditions that affect their performance. Performers do this following guidance to perform tasks
appropriately under those conditions. All this can be measured, and the performance of an
activity can be assessed against standards of performance. In architectural terms: tasks are
activities, ways are guidance, means are performers, conditions are conditions, standards are a
particular sort of guidance, and desired effects are changes in the states of resources.
In the DM2 these straightforward concepts are founded on a formal ontology that enables
architectural descriptions as complex and detailed as required. Figure 4-2 illustrates key
concepts of the DM2’s foundation.
4-4
Figure 4-2. Overview of DM2 Ontologic Foundation

The top-level
level foundation elements are represented by these boxes:
• thing — anything that is an individual or a grouping of individuals.
• individual — a thing that exists in space and time.
• type — a grouping of things. G
Groups may be themselves grouped.
• tuple — an ordered pair of two things (i.e., a relationship).
The foundation tuples (relationships) are similar to concepts found in many ontologies,
conceptual schemes, and data models. These common relationship patterns iinclude:
nclude:
• whole & part — composition. Everything has parts, and everything is part of something
else.
• supertype & subtype — generalization and specialization. Everything is a sort of
something.
• before & after — temporal ordering. Everything comes after somet
something
hing and before
something else.
• overlap — four-dimensional
dimensional shared extent. Everything has parts that are shared with
other things. In particular, overlap is the relationship that binds a persistent whole to its
changing parts.
Composition and specialization apply to all architecture concepts. Temporal ordering is needed
to arrange things through time. Overlap is necessary to describe things that interface but are not
necessarily contained within each other.
4-5
4.2 Architecture Viewpoints and DoDAF-described Models
An architecture viewpoint is a selected set of architectural data organized around some central
concept. There are many ways to present an architectural description. A model, regardless of its
form, is a representation of some portion of the architectural data, in the sense that a still
photograph shows only one view of a subject within a picture. Figure 4-3 provides a graphical
representation of the architecture viewpoints in the DoDAF.
Articulate applicable Operational, Business, Technical, and Industry
Overarching aspects of architecture context that relate to all views
requirements and the various projects being implemented; Details

Capability Viewpoint
Articulate the data relationships and alignment structures in the
dependencies between capability management and the Defense
Describes the relationships between operational and capability

Articulate the capability requirement, delivery timing,
policy, standards, guidance, constraints, and forecasts
and deployed capability

Data and Information Viewpoint
Operational Viewpoint
Acquisition System process.

Standards Viewpoint
Articulate operational scenarios, processes, activities
Project Viewpoint
architecture content
& requirements
All Viewpoint
Services Viewpoint
Articulate the performers, activities, services, and
their exchanges providing for, or supporting, DoD
functions
Systems Viewpoint
Articulate the legacy systems or independent
systems, their composition, interconnectivity, and
context providing for, or supporting, DoD functions
Figure 4-3. Architecture Viewpoints in the DoDAF
4.2.1 All Viewpoint
Some overarching aspects of an architectural description relate to all models. The All Viewpoint
(AV) models provide information about the entire architectural description, such as its scope and
context. The scope includes the subject area and timeframe of the architectural description. The
setting in which the architectural description exists comprises the interrelated conditions that
compose the context for the architectural description. These conditions include doctrine; tactics,
techniques, and procedures; relevant goals and vision statements; concepts of operations
(CONOPS); scenarios; and environmental conditions.
4-6
4.2.2 Capability Viewpoint
The Capability Viewpoint (CV) describes a vision for performing specified activities to achieve
desired resource states under specified standards and conditions. It applies specified guidance
and specified performers to those tasks. This viewpoint provides a strategic rationale for the
described architecture.
4.2.3 Data and Information Viewpoint
The Data and Information Viewpoint (DIV) describes information needs, data requirements, and
the implementation of data elements within an architectural description. This viewpoint includes
information associated with information exchanges in the architectural description, such as the
attributes, characteristics, and inter-relationships of exchanged data.
4.2.4 Operational Viewpoint
The Operational Viewpoint (OV) describes organizations, activities they perform, and resources
they exchange to fulfill DoD missions. This viewpoint includes the types of information
exchanged, the frequency of such exchanges, the activities supported by information exchanges,
and the nature of information exchanges.
4.2.5 Project Viewpoint
The Project Viewpoint (PV) describes how programs are grouped in organizational terms as a
coherent portfolio of acquisition programs. This viewpoint provides a way of describing the
organizational relationships between multiple acquisition programs, each of which is responsible
for delivering systems or capabilities.
4.2.6 Services Viewpoint
The Services Viewpoint (SvcV) describes services that provide or support operational activities.
This viewpoint traces service activities and resources to the requirements established by the
Operational Viewpoint.
4.2.7 Standards Viewpoint
The Standards Viewpoint (StdV) describes the minimal set of rules governing the arrangement,
interaction, and interdependence of systems and system parts. The purpose of this viewpoint is to
ensure that a system satisfies a specified set of operational requirements. The Standards
Viewpoint identifies the technical systems implementation guidelines upon which engineering
specifications are based, common building blocks established, and product lines developed. This
viewpoint includes a collection of the technical standards, implementation conventions,
4-7
standards options, rules, and criteria for organizing them into profiles that govern systems and
system or service elements in a given architectural description.
4.2.8 Systems Viewpoint
Systems Viewpoint (SV) describes system activities and resources that support operational
activities. This viewpoint traces system activities and resources to the requirements established
by the Operational Viewpoint.
4.2.9 Standard Models
The table, DoDAF Standard Models, list the standard models provided by the DoDAF for the
eight DoDAF viewpoints.
4-8
Table 4-1. DoDAF Standard Models

Model Describes…
AV-1: Executive Summary Project visions, goals, objectives, plans, activities, events,
conditions, measures, effects (outcomes), and produced objects.
AV-2: Glossary Definitions of ontic terms used in an architectural description.
CV-1: Capability Effects The overall vision for transformational endeavors, which provides
a strategic context for the capabilities described and a high-level
scope.
CV-2: Capability Hierarchies A hierarchy of capabilities which specifies all the capabilities that
are referenced throughout one or more architectural descriptions.
CV-3: Capability Schedules The planned achievement of capability at different points in time
or during specific periods of time. The CV-3 shows the capability
phasing in terms of the activities, conditions, desired effects, rules
complied with, resource consumption and production, and
measures, without regard to the performer and location solutions.
CV-4: Capability Dependencies The dependencies between planned capabilities and the
definition of logical groupings of capabilities.
CV-5: Capability Deployments The fulfillment of capability requirements shows the planned
capability deployment and interconnection for a particular
capability phase. The CV-5 shows the planned solution for the
phase in terms of performers and locations and their associated
concepts.
CV-6: Capability Activities A mapping between the capabilities required and the operational
activities that those capabilities support.
CV-7: Capability & Services A mapping between the capabilities and the services that these
capabilities enable.
DIV-1:Conceptual Information Information needs.
DIV-2: Data Requirements Model Data requirements.
DIV-3: Data Implementation The physical implementation of data elements.
OV-1: Operational Concept The operational concept.
OV-2: Organizations & Resources Resource flows exchanged between operational activities.
OV-3: Organizations, Activities, & Resources exchanged and the relevant attributes of the
Resources exchanges.
OV-4: Organizational Organizational context, roles, and other relationships among
Relationships organizations.
OV-5a: Operational Activity Capabilities and operational activities organized in a hierarchal
Hierarchy structure.
OV-5b: Operational Activities The context of capabilities and operational activities and the
relationships among activities, inputs, and outputs.
OV-6a: Operational Rules Rules that constrain operational activities.
OV-6b: Operational State Activity responses to other activities.
Transitions
OV-6c: Operational Activity Activities in a scenario, a specified sequence of activities.
Sequences
PV-1: Projects & Organizations The dependency relationships between the organizations and
projects and the organizational structures needed to manage a
portfolio of projects.
PV-2: Project Schedules A schedule of activities and their resources with the key
milestones and dependencies.
PV-3: Projects & Capabilities A mapping of programs and projects to capabilities to show how
the specific projects and program elements help to achieve a
4-9
Model Describes…
capability.
SvcV-1 Services Services, service items, and their interconnections.
SvcV-2 Services Interfaces Resource flows among services.
SvcV-3a Services & Systems relationships among or between systems and services in a given
architectural description.
SvcV-3b Service Relationships Relationships among services in a given architectural description.
SvcV-4 Services Functions Activities performed by services and the service resource flows
among service activities.
SvcV-5 Services & Operational A mapping of service activities to operational activities.
Activities
SvcV-6 Services, Activities, & Service resource flow among between services and the attributes
Resources of those resources.
SvcV-7 Service Measures Measures of services for interesting periods of activity.
SvcV-8 Services Evolution Planned incremental steps to migrate from current services to
future services.
SvcV-9 Service Technologies & Emerging resources, standards, and skills that planners expect to
Skills be available for future service development.
SvcV-10a Services Rules Rules that constrain service activities.
SvcV-10b Services State Service activity responses to other activities.
Transitions
SvcV-10c Services Activity Activities in a scenario, a specified sequence of service activities.
Sequences
StdV-1 Standards Profile Current standards constraining activities that produce solution
resources.
StdV-2 Standards Forecast Future standards that will constrain activities that produce
solution resources.
SV-1 Systems Composition and Systems, system parts, and their relationships.
Interface Identification
SV-2 System Interface Means Resource flows among systems.
SV-3 System Relationships Relationships among systems in an architectural description.
SV-4 Systems Functions The functions (activities) performed by systems and the system
data flows among system functions (activities).
SV-5a Systems & Operational The relationships of system activities to operational activities.
Activities
SV-5b Systems & Capabilities A mapping of systems back to capabilities or operational activities
(activities).
SV-6 Systems, Activities, & Provides details of system resource flow elements being
Resources exchanged between systems and the attributes of that exchange.
SV-7 System Measures Measures of a system.
SV-8 System Evolution The plan to upgrade a suite of systems to a more efficient suite or
to evolve a current system to a future implementation.
SV-9 System Technologies & Skills The emerging technologies, software/hardware products, and
skills that are expected to be available in a given set of time
frames and that will affect future system development.
SV-10a Systems Rules Constraints on system activities.
SV-10b System State Transitions How a system responds to events.
SV-10c System Activity Sequences System-specific refinements of critical sequences of activities
described in the Operational Viewpoint.
4-10
APPENDIX A ACRONYMS & ABBREVIATIONS
Acronym Definition
AV All Viewpoint
BEA Business Enterprise Architecture
BMA Business Mission Area
BPMN Business Process Modeling Notation
C2 Command and Control
CA Common Approach
CDM Conceptual Data Model
CI Configuration Item
CM Configuration Management
COI Community Of Interest
COMMPLAN Communications Plan
CDD Capability Development Document
CPD Capability Production Document
CPM Capability Portfolio Management
CV Capability Viewpoint
DAS Defense Acquisition System
DDMS Department of Defense Discovery Metadata Specification
DISR DoD Information Standards Registry
DIV Data and Information Viewpoint
DM2 DoDAF meta-model
DNDAF Department of National Defense Architecture Framework
DOTMLPF Doctrine, Organization, Training, Material, Leadership and

education, Personnel, and Facilities
E-R Entity-Relationship
EA Enterprise Architecture
EEI Essential Element of Information
A-1
Acronym Definition
FEA Federal Enterprise Architecture
FFP Fit For Purpose
FOC Full Operational Capability
IC Intelligence Community
IC-ISM Intelligence Community – Intelligence Standard Markings
ICD Initial Capabilities Document
IDEAS International Defence Enterprise Architecture Specification
IEA Information Environment Architecture
IER Information Exchange Requirement
IMA Information Mission Area
IPB Intelligence Preparation of the Battlefield
IPOE Intelligence Preparation of the Operational Environment
IOC Initial Operational Capability
ISO International Standards Organization
ISP Interoperability Support Plan
ISR Intelligence, Surveillance and Reconnaissance
IT Information Technology
JCA Joint Capability Areas
JCIDS Joint Capabilities Integration and Development System
LDM Logical Data Model
OMB Office of Management and Budget
OPLAN Operation Plan
OV Operational Viewpoint
MODAF Ministry of Defence Architecture Framework
MOE Measure Of Effectiveness
MOP Measure of Performance
NIEM National Information Exchange Model
A-2
Acronym Definition
NSS National Security System
PE Program Element
PES Physical Exchange Specification
PIR Priority Intelligence Requirement
POM Program Objective Memorandum
PPBE Planning, Programming, Budgeting, and Execution
PV Project Viewpoint
QoS Quality of Service
RA Reference Architecture
RDBMS Relational Database Management System
SA Solution Architecture
SCI Software Configuration Item
SE Systems Engineering
SETR System Engineering Technical Review
SOA Service Oriented Architecture
SoS System of Systems
SoSE System of Systems Engineering
SV Systems Viewpoint
SvcV Services Viewpoint
StdV Standards Viewpoint
TADIL TActial Data and Information Link
TEMP Test and Evaluation Master Plan
TOGAF The Open Group Architecture Framework
TTP Tactics, Techniques, and Procedures
UJTL Universal Joint Task List
UML Unified Modeling Language
URL Universal Resource Locator
A-3
Acronym Definition
WBS Work Breakdown Structure
WMA Warfighting Mission Area
XML Extensible Markup Language
XSD XML Schema Definition
A-4
APPENDIX B GLOSSARY OF CONCEPTUAL LEVEL TERMS

This appendix lists conceptual level terms and their definitions from the DoDAF Glossary1. For
more information about these terms, including their technical DM2 definitions, consult the
complete Glossary. These definitions are generally stated in the singular; however, this grammar
assumes that whatever applies to one also applies to many. Consult WordNet for the meaning of
terms not defined here. The appropriate senses among those given by WordNet are noted by an
index number in entries that specify a specific sense of term for DoDAF use.
activity — a transformation of some resource into another resource.
agreement — a guidance statement that records consent among performers to guidance and
conditions for performing an activity.
capability — an ability to achieve a desired resource state under a specified performance

standard and a specified condition through some combination of guidance and resources to
perform a set of activities. ◊ translated from: Joint Publication X.
condition — a state of resources that affects the performance of an activity.
data — an information resource that represents states in a standard way suitable for
consumption and production by activities. ● see: information.
desired resource state — a state of resources that is envisioned by a performer capable of

responsibility. ● see: vision, capability, resource. ● note: A desired resource state is the
DoDAF expression of the desired effect of a capability. In the Joint view of capability, a
performer capable of responsibility is exemplified by a combatant commander.
geopolitical extent — a region of the world whose boundaries are asserted by a nation state.
guidance — an information resource that is an authoritative statement that constrains the

performance of an activity.
information — a resource that is a representation of the state of rules, conditions, activities,

performers, and other resources. ● note: Information is often produced by one performer to
be consumed by another, decision-making performer. ● example: Information is a
difference that makes a difference. • Gregory Bateson.
location — a point or extent in space that may be referred to by coordinates or by name. ● note:
A location is said to be a geospatial extent.
1
The DoDAF 2.02, Chg 1 Glossary is also known as the DoDAF 2.02, Chg 1 Data Dictionary.
B-1
materiel — a resource that is some assemblage of equipment, apparatus, and supplies used by a
performer to perform an activity.
measure — a quantification of the magnitude of some property of a thing.
organization — a performer that is an assemblage of persons in roles and resources that support
those roles.
performer — a resource that performs an activity.
performer capable of responsibility — a person in a role that is accountable for the

performance of an activity. ● see: person role.
person role — a performer that is a person defined by a role with respect to an activity. ● note:
In day-to-day language, we speak of a person in a role.
resource — any thing that is produced or consumed by an activity. ● note: Performers and
guidance associated with an activity are themselves products of other activities.
rule — a guidance statement that prescribes the performance of an activity.
service — a performer that enables access to the performance of a set of activities.
standard — a guidance statement that specifies criteria for the performance of an activity.
system — a performer that is an assemblage of resources.
vision — an information resource that describes a future state of resources that is to be achieved.
B-2
APPENDIX C RECORD OF CHANGES FOR CHANGE 1

# Title Description Source Org Action
We model as Condition. It looks like Condition is a sub of
Context, esp Operational or Environmental Context, can set Property, e.g., UJTL Riverine Current of Stong, Moderate,
91 Context condition for interfaces, etc. UPDM Gentle -- the rivers whose current is Stong, all the rivers
Same as 453 whose current is Gentle, etc. Condition was made a
subtype of Property
To have a <<Powertype>> stereotype, the class must be at
the (arrow) end of a powertypeInstance relationship. In
Condition other words, it is formally redundant…but is there as it is
Changed to Type.
295 Powertype useful to be able to identify what is a powertype at a single IDEAS
WG Reviewed.
stereotype glance. In the case below, “condition” is not a powertype, as
we have not identified the type for which it is the powertype.
Suggest it is just stereotyped as <<Type>>
Schema has not been provided in the Dictionary for the
DoDAF Ver. 2.0 Viewpoints. The only schemas included are
Metamodel for the Meta-model Data Groups. CADM included schemas
316 diagram per that showed how each View was characterized and SPAWAR Create simplified versions of the LDM diagrams
DoDAF Model constructed from a data perspective. The Proposed
Resolution: Revise the Dictionary to add schemas for each
AV, CV, DIV, OV, PV, StdV, SvcV, and SV Viewpoint.
Are there examples of Rules that don't have spatio-temporal
same pattern as desiredEffect and
extent? For example, does the Constitution exist separate
desiredEffectDescription for WG to review prior to 2.03
Rules and from any printed copy? Should the context of a Performer
383a Sandia technical cutoff
Contexts WRT a rule constraining an Activity be generalized? Rules
Added pattern to Rules diagram.
and superrules? See SBVR WRT rules, operative rules, and
WG reviewed.
enforcement.
C-1

Put out a FAQ on this. Discuss external organizations and
how DM2 restricts send and receive to be by Activities only
but that this is not a problem -- simply create a Send XXX
and Receive XXX.
Also update FAQ's on Journal from EA Conference FAQs.
Provide FAQ in next readahead
Is there an official DoDAF 2 definition for an "external FAQ added.
performer" and how does the DM2 handle it? My architects FAQ list consolidated and put on Journal site.
believe that the external performer is a performer outside DM2 site has link to FAQ on Journal site. In DM2 you can
the scope of the architecture and we do not necessarily categorize as external or internal as needed. But may not
External know/care what they do with the information. For example, HQMC be standard across organizations. For Performers you do
402
Performer we know the we need to get information X to the Army, but CD&I not need to model, the DM2 doesn't not require
don't necessarily know the activity they will be doing if it is documentation of the Activities other than an
outside the scope of the architecture. Our architects capture acknowledgement that a generic or dummy consume or
the Army needline in the OV-2, but I don't think the DM2 produce activity must have taken place. See UPDM SAR
doesn't allow us capture it without documenting the activity. DM2 markup examples. An OV-2 diagram need not show
the implied activities but the DM2 PES XML document
must, even if they are just placeholders to be completed
later, e.g., during OV-5 development. This precision solves
the “overspecification” problem of earlier DoDAF OV’s.
In MODAF, would be known resource. Private action and
public actions in Joint action.
Physical and
Temporal
405 UPDM example does not have these mandatory elements DCIO made optional in PES matrix
Measures for
SV10b
C-2

Capability connects to Resource via desiredEffectOfCapability
which is descended from WholePartType. Capability is
descended from IndividualType, i.e. it is the set of sets where
DM2 AI rec change desiredEffectOfCapability name to
the instances of each of the sets it contains are entities that
desiredResourceStateOfCapability. Also, fix def of
have a capability, i.e. some of these can easily contain
MeausreOfEffect to remove "desired."
individuals that are kinds of performers. There is no
DM2 AI Capability must have at least one of these. May
argument however concerning the need to have something
also for Performer to say it must perform at least one
that connects a capability to a desired outcome in the form
Activity. Etc.
of a state of a given resource. As an example taken from the
Provide list of association name changes.
SAR it would seem likely that the end desired effect of a
Changed defs of desiredResourceStateOfCapability,
Maritime search and rescue would be that the state of the
Rename/Def desireMeasure, effectMeasure,
resources that are in need of rescue is changed from "in
change for visionRealizedByDesiredResourceState,
406 need of rescue" to "rescued and safe" and that the state of UPDM
desiredEffect desiredResourceStateRealizedByProjectType,
the resource "a place of safety" is changed from having "no
structure descriptionOfDesiredResourceStateDirectsActivity,
rescued" to "all in need rescued". This would however seem
descriptionOfDesiredResourceState,desiredResourceState
to imply a certain multiplicity as regards the resource. Is this
DescribedBy
assumption relating to multiplicity correct? The naming of
Renamed desiredResourceStateOfCapability,
the element gives the impression that it has something to do
visionRealizedByDesiredResourceState,
with desiredEffect which however is not the case. This would
desiredResourceStateRealizedByProjectType,
seem to require some handling to avoid misunderstandings.
descriptionOfDesiredResourceStateDirectsActivity,
An associated element is effectMeasure and
descriptionOfDesiredResourceState,desiredResourceState
MeasureOfEffect. The definition of effectMeasure talks
DescribedBy.
about desiredEffect in spite of the fact that there is no
relationship to this element. A change of definition would
seem to be in order here.
activitySuperSubtypeOfMeasureType is defined as: "
activityType is a member of MeasureType". There is no
element named activityType and this implies that the
activitySuperSu definition needs to be changed. Since Activity is the set of all Relationship changed to measureTypeApplicableToActivity
408 btypeOfMeasur subsets of IndividualActivity and MeasureType is the set of UPDM and is a typeInstance relationship and of proper order.
eType Def all subsets of a set of sets of Individual Measures, the The definition needed to be corrected and was.
connection is less than obvious and the author of this report
would like to discuss this.
Def is incorrect or remove TypeType.
C-3

Take Alex's Joint pub defs in the Capabilities deck and add
to aliases. Take a stab at DM2 that corresponds to it.
The proposed action is incorrect and leads to ambiguity.
Added Ways as alias.
414 Ways Ways are activities (behavior, tactics, etc.), means are SAF/A6
Revisit to finialize def and DM2 aliases.
systems (materiel facilities, people, etc)
Notify Mark that we went with Joint defs.
New source for Ways and def reviewed by WG.
CV-3 Capability phasing The text describing the view talks
428 Enterprise about phases derived from CV-1. What is being referred to UPDM Capability phasing will not be included in the TECHEDIT
here? (since no direct enterprise phase exists in DM2).
activityResourc
This seems weird to be a supersubtype since the super and
439 eOverlapSuperS DCIO relationship removed
sub are different types (Type and tuple type)
ubtypeOfRule
It has been stated previously that IndividualPerson is to be
Correct IndividualPerson is not a DoDAF architectural
considered as meta-data. It is however still shown as part of
449 Ind. Person UPDM element. Removed IndividualPerson. Created
the Performer data group. Does this mean that the use of
IndividualPersonRole to represent, e.g., billets.
IndividualPerson has changed?
Capability is related to Performer via capabilityOfPerformer.
This in turn is descended from propertyOfType which is Agreed, made Capability a subtype of Property so that a
defined as " A superSubtype that asserts an IndividualType is Capability is a set of types that exihibit certain desired
a subtype of a Property - i.e. it asserts all members of the effects and performance of activities under certain
Individual type "have" a property. Examples: All London conditions. (Similarly, changed CapabiltyType to be a
Buses are red, All Porsche 911 2.2S have a mass between 900 PropertyType.) Necessitated changing
and 960 kg.". In PropertyOfType <<place1Type>> is Property capabilityOfPerformer to be propertyOfType (a super-
capabilityOfPer and <<place2Type>> is IndividualType. In subtype relationship). This is a relatively big issue since it
453 UPDM
fomer capabilityOfPerformer <<place2Type>> is Performer which is high-lights a general problem where the model does not
a subset of Resource which in turn is a subset of seem to mesh properly. At present the DM2 model
IndividualType. <<place1Type>> is Capability which is a contains an error that has to be corrected in some fashion.
subset of IndividualType i.e. less restricted than the It is not strictly clear however exactly how this is to be
<<place1Type>> that propertyOfType links to since Property accomplished. There seems to be some misgivings about
is a subset of IndividualType. The following therefore seems using the solution that indicates capability as a subtype of
to be a valid question: Why is Capability not a subset of Property, the reason for this is at present not known.
Property?
Disjoint already in the current IDEAS foundation so can be Brought in IDEAS Disjoint for Partitions. Setup one for the
464 Disjoint UPDM
removed form DM2 partition of real property into sites and facilities.
C-4

ServiceDescripti
Service Description describes a Service. Still need to figure
on desribes ServiceDescription contains all the information relating to a
471 UPDM out what a Service Port is? Deleted from model for now.
ServicePort, not service but it is linked to a ServicePort not a Service
See 387 for this issue
Service
Project and
Project Type
484 UPDM Removed the TI
have a TI and a
PTI
Record DM2 AI for what are currently are called Info Type
and Data Type to be the resource types that flow in the
resource flow model. This is because it is not the actual
Individual Type Information that is modeled in the flow,
but the TypeType. This requires a person to understand
that the Individual information or data is at the utterance
or copy level. At present the DM2 model handling of
Information (a set of sets) and InformationType (set of
subsets of a set of sets is somewhat strange. The same
Information is indicated as a Type, i.e. it is a set of sets. goes for DataType. The explanation given is that an
InformationType is its Powertype, i.e. it is the set of all individual piece of information is a specific utterance as
subsets of a set of sets. Why is associationOfInformation such. As an example let is consider the information "weight
attached to it, would it not be better to make use of =10 kg". The set being referred to by Information are all
Info Type and Information instead if the intent of the element is to describe utterances or copies of this particular piece of information.
494 UPDM
Data Type the structure of a particular kind of information type (an The instances of InformationType are therefore all subsets
instance of the Information set). InformationType is not of theses sets and one of those subsets is weight
connected anywhere with the exception of the tuple and the information where the actual value is not defined but only
powertype association. The same could be stated for given as a valueType. The implication of this is then that
DataType. DM2 is wrong when it defines Information as a subset of
Resource, instead the subset should be InformationType if
it is to be usable. The same argument can be made for
Data and DataType.
Do 2nd order types for everything - done.

Information is a subclass of both Representation and
Resource. 2nd order of these classes follow the same
pattern.
Reviewed by WG
C-5

Why have measureOfIndividual been treated differently from Added subtype for MeasureOfIndividual, currently only
497 Measures UPDM
MeasureOfType (see 2.6 in the report). MeasureOfIndividualPoint.
Lars' rules should state that WholePart(Types) should be
limited to the same DM2 leaf classes only.
Make sure Lars' rules are formally in 2.03
The following relationships were added:

systemPartOfService
servicePartOfSystem
Org/OrgType
organizationTypePartOfService
503 WP(T) Relationship missing - Org/OrgType Part Of Performer DCIO
servicePartOfOrganizationType
Performer
organizationTypePartOfSystem
systemPartOfOrganizationType
removed:
portPartOfPerformer
change rule to add above and send to Alex

The definition for “Powertype” seems a bit garbled (“A Type
Powertype
517 that is the is the set (i.e., Type) of all subsets (i.e., subTypes) IDA Changed to IDEAS def.
Definition
that can be taken over the some Type.”
If needed only for metadata, does not need to be structured
Individual
520 so remove. If intended only for AV-1, how would you MITRE dupe of #449
Person
restrict?
Added DescriptionOfDesiredEffect and showed it as the
desiredEffectDi
537 How does a desired effect guide/direct Activities? UPDM Resource consumed by an Activity so that it would be
rectsActivity
guided by it.
Not all
Try PerformerCapableOfResponsibility on for size and WG
Performers can Probably limit to Oganizations, Organization Types, and
538 UPDM review. OrgType and PersonRole made sub of
desired an Person Types
PerformerCapableOfResponsibility. WG reviewed.
effect
Made a new relationship between Guidance and Activity-
Guidance and Guidance serves no purpose in DM2. It should either be guidanceShapesActivity
539a UPDM
Rule deleted or linked to something. Made Guidance dfo and new relationship as o in PES
matrix
C-6

PersonType
Use personRolePartOfPerformer with singleton
part of Need Individual Person part of Individual Performer to do
541 UPDM typeInstance relationship between IndividualPersonRole
Individual correctly. Related to 503
and IndividualPerformer
Performer
Information
Type is a Information Type is a Resource Type but forgot to show
542 UPDM Restitched InformationType To RepresentationType
Representation Representation Type relationship
Type
Pedigree Made Pedigree activities Individual Activities.
544 Pedigree Activities are Individual Activities UPDM
activities Combined InformationPedigree and Pedigree diagram
Name def
548 doesn't match IDA changed to IDEAS def
model
549 Action Should be in data dictionary IDA Get definitions for Action, e.g., JC3IEDM, Dale, …
especially:
1. desiredEffect the tuple is required in many products, but 1. made desiredEffect optional. ResourceState is dfo.
Monster Matrix we tend to use the resource state instead. 2. no change needed. Activity and ActivityType are
566a SBSI/DCIO
review - part 1 2. ov5a has no optional elements. that really limits things. available along with all IFO and DFO classes.
3. most SvcV products require port even though we alway 3 is OBE.
use serviceport instead.
Representation RepresentationType cannot be an IndividualTypeType and a
573 Type / Resource (IndividualType). This occurs because SBSI/DCIO Changed Info and Data flow resources to be first order.
Resource InformationType is needed in ResourceFlow
The DoDAF website should have a process to submit change
SBSI Website: requests. Also, there should be a way to see the submitted
593 DM2 Action change requests in a log on the public site (whether it is added to website
Item DoDAF or DoDAF Journal). It needs to collect the appropriate
status and change information.
In order for the IDEAS plugin to work properly with the
IDEAS plugin work with Ian to fix plugin
595 model, Ian will run a script to tweak it.
model tweaks new plugin available
Also, double-clicking on diagram items causes issues.
Need ARO to
added joint action as a couple that relates
597 prevent
activityConsumesResource and activityProducesResource
ambiguity
Is Capability really a subset of IndividualType. This results in
598 Capability Make Capability a sub of Property. Dupe of 453
strange connections for other elements.
C-7

Measure of
This means you can't put a Measure on any individual other
Type and measureOfType and measureOfIndividual made dfo
600 than a point and for types only the specifically defined
Measure of Ind verify done for 2.03
subclasses of Measure of Type.
are df
Def of 1. They're identical. 2. Theydon't make any sense: Changed to: activityPerformableUnderCondition-
activityPerform "Represents that an activity was / is / can-be/ must-be Represents that an activity was / is / can-be/ must-be
ableUnderCond conducted under certain conditions with a spatiotemporal conducted under certain conditions.
603
ition and overlap of the activity with the condition." 3. Why is the activityMapsToCapabilityType-Represents that an activity
activityMapsTo mapping an overlap rather than a wholePart like is part of a CapabiltyType. The mapping may go away
CapabilityType activityPartOfCapability? depending on resolution of the higher order types.
desiredFutureResourceState s/b desiredResourceState,
others s/b desiredResourceState not desiredEffect. The
following were renamed as such:
desiredEffect descriptionOfDesiredResourceStateDirectsActivity
604 association They're actually pointing to a resourceState. Dupe of 406 desiredResourceStateRealizedByProjectType
names desiredResourceStateOfCapability
desiredResourceStateDescribedBy
visionRealizedByDesiredResourceState
DescriptionOfDesiredResourceState
effect and
desire
measures can
605 Since both places are subtypes classes made subtypes of measureOfResource
be subtyped
under resource
measure
explcitness of
places 1 should be renamed to thingRepresented,
606 representation renamed as described
thingNamed, thingDescribed
places
places mixed up measureOfIndividualPoint -- should be place
measure of
2 that points to the thing measured. Don't need to redefine Changed place2 to point to class Point. Also put descriptive
607 individual place
place 1 since measureOfIndividual already points to name on place2.
renaming
Measure. Don't need to rename place 1 for most of the subs.
C-8

resources
overlap
locations, not
609 e.g., a facility's lat long point Change to overlap type
necessarily
contained
within
type for rule
since they are both information, they are consumed like Change to overlap type and before after type for both the
610 and guidance
other information rule constraining and guidance shaping. Like in 383
constraints
measures of
612 temporal should use IDEAS duration and period naming instead Dupe of 647
boundaries
rules and
guidance like 383
615
separate actual Pattern done for Rule but not Guidance - 539b.
from document
these are the beforeAfterType relationships in the model
and the relationship they describe:
ruleConstrainsActivity - rule before activity
desiredResourceStateRealizedByProjectType - projecttype
before resource
*descriptionOfDesiredResourceStateDirectsActivity -
descriptionOfDesiredResourceState before activity
*activityConsumesResource - resource before activity
place positions are reversed; the activities happen before the
desired effect activityProducesResource - activity before resource
617 objective. But the description of the desired effect happens
directs activity *descriptionOfRuleDirectsActivity - descriptionOfRule
before the activities.
before activity
guidanceShapesActivity - guidance before activity
enablingServiceStandardConstrainsEnablingServiceActivity
- EnablingServiceStandard before EnablingServiceActivity
businessServiceStandardConstrainsBusinessServiceActivity
- BusinessServiceStandard before BusinessServiceActivity
The starred items were backwards and changed to
described above.
Some combinations don't make sense; usage for system part
performer part Looks like all combinations are OK except OT WPT PRT.
618 of service, org part of system, etc. violates Lars Superclass
of performer Dupe of 503
Association Usage Rules; and LDM is inconsistent with CDM.
C-9

temporal
boundaries at
619 removed from model and data dictionary
the type level
unnecessary
DoDAF
620 Update text to WG levels develop text based on FAC brief
conformance
DoDAF says: "The Systems DoDAF-described Models are Change to: "The Systems DoDAF-described Models are
available for support of legacy systems. As architectures are available for support of systems. This includes legacy
updated, they should transition from Systems to Services and systems and systems that will not become services. If an
utilize the models within the Services Viewpoint”. Not all architecture transitions to services, they can transition
Systems
systems transition to services and architectures may need from Systems to Services and utilize the models within the
621 transitioning to
both SV and SvcV's. See the discussion thread on LinkedIn Services Viewpoint. An architecture can also have models
Services
for more details, in the Systems Viewpoint and the Services Viewpoint.'
http://www.linkedin.com/groups?mostPopular=&gid=25855 Discussed Services CRs. WG to review. McDaniel to work
50. Part of Service concept (CR's 516, 518, 523, 560, 387, on defs.
398, 621) Section being aligned with glossary and DM2.
622 Release Date Add release date to PES file DCIO changed in new PES
C-10

change to:
«Individual» an instance of an Individual: something with
spatiotemporal extent [gray (80%): R40 G40 B40]
«Type» a specification of a Type [pale blue: R153 G204 B255]
«IndividualType» a specification of a Type whose members
are Individuals [light orange: R255 G173 B91]
«TupleType» a specification of a Type whose members are
tuples [light green: R204 G255 B204]
«Powertype» a specification of a Type that is the set of all
subsets of a given Type [lavender: R204 G153 B255]
«Name» a specification of a Name, with the exemplar text
provided as a tagged value [tan: R255 G254 B153]
«NamingScheme» a specification of a Type whose members
Model are Names [yellow: R255 G255 B0]
625 convention The model uses these stereotyped relationships: UPDM changed
update «typeInstance» a relationship between a Type and one of its
instances (UML: dependency) [red: R255 G0 B0]
«powertypeInstance» a relationship between a Type and its
powerset (UML: dependency) [red: R255 G0 B0]
«nameTypeInstance» a relationship between a Name and its
NameType (UML: dependency) [red: R255 G0 B0]
«superSubtype» a relationship between a Type and one of its
subtypes (UML: generalization) [blue: R0 G0 B255]
«wholePart» a relationship between an Individual and one of
its parts (UML: aggregation) [green: R0 G147 B0]
«namedBy» a relationship between a Name and the thing it
names (UML: association) [black: R0 G0 B0]
«tuple»/«couple» a relationship among/between things
(UML: n-ary relationship diamond) [gray (80%): R40 G40 B40]
PersonType
Renamed as IndividualPersonRole, PersonRole,
630 residual The potential aliases for "Mission" still mentions PersonType. N2/N631
PersonRoleType
terminology
DoDAF Website PDF from website is not a document, but simply a print job Will provide formal document exactly same as web page
636 DCIO
PDFs from web content for 2.03
C-11

The following types in DM2 (v2.02) do not get the correct
foundation class using the specified rules.
- activityProducesResource
- activityConsumesResource
- desiredEffectDirectsActivity
Foundation
- desiredEffectIsRealizedByProjectType
641 category for EE change in new PES
All of the above classes are subtypes of both WholePartType
exporter
and BeforeAfterType. DM2_PES_v2.02.xsd specifies that they
must have the foundation category WholePartType. But the
rules indicate that the foundation category should be
CoupleType (the super type of BeforeAfterType) because it is
more generic.
Removed the association. It is not necessary. Can be
associationOfIn treated as any other Resource and use the other generic
642 It is the last triple in the model. Is this correct?
formation DM2 relationships like superSubType, WholePartType,
BeforeAfterType instead.
Put operationally, in architectures do we need to
sometimes say: Some type of Resource is (or will be) in an
Wanted to make sure we needed both actual location (e.g., Afghanistan) Some type of Resource
resourceInLocat individualResourceInLocation and resourceInLocationType. will need to be in a location type (e.g., the desert) Use a
643
ionType The only set of relationships in the model that are duplicated consistent pattern Example, documentation on use of
for Individual and Type. singletons Review convention on “Individual” prefixes and
“Type” suffixes and make consistent. Removed
individualResourceInLocation.
C-12

harmonize with IDEAS
deleted:
EndBoundaryType
measureOfIndividualEndBoundary
measureOfIndividualStartBoundary
measureOfTypeEndBoundaryType
measureOfTypeStartBoundaryType
StartBoundaryType
TemporalBoundaryType
kept:
Remove
endBoundary
647 temporalBound now using HappensIn DCIO
startBoundary
ary classes
temporalBoundary
added:
Period
Instant
PeriodOrInstant
happensIn
Duration
PeriodType
timeSuperTypeDurationSubtype
MeasurePoint
make sure version information is embedded in PES XSD and
649 Versioning DCIO add to new PES
LDM
associationOfInformation has the names of its relationships
associationOfIn
652 reversed "associateOne" is stereotyped as "place2" and DCIO relationship deleted. See 642.
formation
"associateTwo" is stereotyped as "place1".
Incorrect statement concerning ‘Legacy’ – “The Systems
Whole Viewpoint, for Legacy support, is the design for solutions
3 d-Deleted. Find other instances of legacy and change.
Document: articulating the systems, their composition,
663 USMC System views will not go away for Service views. Cross ref
Legacy System interconnectivity, and context providing for or supporting
with 621. Section being aligned with glossary and DM2.
Statement operational and capability functions.” http://cio-
nii.defense.gov/sites/dodaf20/ viewpoints.html
C-13

Incorrect statement and use of ‘connections’ “In addition to
Needlines, Resource Flow Connectors can be used to overlay
OV-2: Incorrect contextual information about how the Operational Activities 3.1.4.2.2 p - Removed term. Must define Resource Flow.
665 use of and Locations interact via physical flows” http://cio- USMC Rename Resource Flow diagram in DM2 . Section being
'Connections" nii.defense.gov/sites/dodaf20/OV-2.html Suggest using aligned with glossary and DM2.
‘Flow’ when referring to an information or resource
exchange.
OV-2: Incorrect
description and OV-2 description relies heavily upon activities and it should
changed 3.1.4.2.2 e and g. Section being aligned with
666 overly focus on the “performers”. http://cio- USMC
glossary and DM2.
dependant nii.defense.gov/sites/dodaf20/OV-2.html
upon 'Activities'
Incorrect statement - “Supply chain analysis” and "Allocation
OV-2: of activities to resources". It should not be used because it
3.1.4.2.2 c - removed both terms. Ensure allocation of
"Incorrect use skews the intended purpose of the OV-2. This analysis would
667 USMC activites to resource in OV5b. Section being aligned with
of supply chain require much more information than is captured on an OV-2
glossary and DM2.
analysis" and it will lead to confusion on the part of the developer of
the OV-2.
OV-5b:
Incorrect statement, delete all references to only ‘Intel
Incorrect
Community’ – “The OV-5b describes the operational,
statement and fixed 3.1.4.2.5 c.
668 business, and defense portion of the intelligence community USMC
use of Section being aligned with glossary and DM2.
activities associated with the Architectural Description,”
'Intelligence
http://cio-nii.defense.gov/sites/dodaf20/OV-5ab.html
Community"
Incorrect statement, does not accurately describe OV-5,
fixed 3.1.4.2.5 b - deleted: that are being conducted within
OV-5b: sounds more like OV-6c – “The OV-5a and OV-5b describes
the mission or scenario, added: and, optionally, the
669 Incorrect OV-5b the operational activities that are being conducted within the USMC
allocated performers.
description mission or scenario.” http://cio-
Section being aligned with glossary and DM2.
nii.defense.gov/sites/dodaf20/OV-5ab.html
3.1.4.2.5 c - deleted: The OV-5b also describes
OV-5b: Incorrect statement, should not focus on Business Activities
Input/Output flows between activities, and to/from
Incorrect only - “External interchanges (from/to business activities that
670 USMC activities that are outside the scope of the Architectural
description of are outside the scope of the model).” http://cio-
Description.
focus nii.defense.gov/sites/dodaf20/OV-5ab.html
Section being aligned with glossary and DM2.
C-14

OV-5b: 3.1.4.2.5 c - deleted: External interchanges (from/to
Incorrect statement, should not use not standardized or
Incorrect business activities that are outside the scope of the
671 defined term - “External interchanges.” http://cio- USMC
terminology model).
nii.defense.gov/sites/dodaf20/OV-5ab.html
used Section being aligned with glossary and DM2.
Incorrect definition and should be rewritten, it does not add 3.1.4.2.5 d - deleted: To maintain this independence from
any clarity to the correlation between the OV-2 and OV-5b - implementation, logical activities and locations in OV-2
OV-5b:
“To maintain this independence from implementation, Operational Resource Flow Description are used to
672 Incorrect USMC
logical activities and locations in OV-2 Operational Resource represent the structure which carries out the Operational
definition
Flow Description are used…” http://cio- Activities.
nii.defense.gov/sites/dodaf20/OV-5ab.html Section being aligned with glossary and DM2.
C-15

DoDAF v2.02 CHG 1 Vol I Final 2015-01-19

Uploaded by

Copyright:

Available Formats

DoDAF v2.02 CHG 1 Vol I Final 2015-01-19

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DoDAF v2.02 CHG 1 Vol I Final 2015-01-19

Uploaded by

Copyright:

Available Formats

DRAFT

DoD Architecture Framework

Volume I: Overview and Concepts

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

This page left intentionally blank

2 DoDAF Volume Organization and Intended Audience 2-1

4 DoDAF Structure 4-1

Appendix A Acronyms & Abbreviations A-1

Appendix B Glossary of Conceptual Level Terms B-1

Appendix C Record of Changes for Change 1 C-1

Figure 3-1. Architecture Manager Roles .......................................................................... 3-2

Table 4-1. DoDAF Standard Models ................................................................................ 4-9

1.1 Vision for the DoDAF

The vision for use of the DoDAF is to:

The purposes of DoDAF are as follows.

through well-organized strategic decisions relating to investments and Portfolio

f. From a practical perspective, an organization that pursues complex ends with

2 DODAF VOLUME ORGANIZATION AND INTENDED AUDIENCE

2.1 Volume I — Introduction, Overview, and Concepts

Primary audience: executives, project directors, and managers.

2.2 Volume II — Architectural Data and Models

Primary audience: architects, program managers, portfolio managers, systems engineers,

Primary audience: developers of architectural description analytics, tools, databases,

2.4 Volume IV — DoDAF Journal

3 WHAT DOD MANAGERS AND EXECUTIVES NEED TO KNOW

Figure 3-1. Architecture Manager Roles

3.1 Developing Architectures

• An enterprise architecture is a strategic information asset of an organization. This asset

3.2 Maintaining and Managing Architectures

Embedding architecture development process in routine planning and decision-making

3.3 Using Architectures

3.4 DoDAF Conformance

4.1 Architectural Data

4.1.1 The DoDAF Conceptual Data Model (CDM)

Figure 4-1. DoDAF Meta Model at the Conceptual Level

Figure 4-2. Overview of DM2 Ontologic Foundation

4.2 Architecture Viewpoints and DoDAF-described Models

requirements and the various projects being implemented; Details

dependencies between capability management and the Defense

Describes the relationships between operational and capability

and deployed capability

Acquisition System process.

Articulate operational scenarios, processes, activities

4.2.1 All Viewpoint

4.2.2 Capability Viewpoint

4.2.3 Data and Information Viewpoint

4.2.4 Operational Viewpoint

4.2.5 Project Viewpoint

4.2.6 Services Viewpoint

4.2.7 Standards Viewpoint

4.2.8 Systems Viewpoint

4.2.9 Standard Models

Table 4-1. DoDAF Standard Models

APPENDIX A ACRONYMS & ABBREVIATIONS

BEA Business Enterprise Architecture

BMA Business Mission Area

BPMN Business Process Modeling Notation

C2 Command and Control

CDM Conceptual Data Model