1. Introduction NAME 24 Sep 2009 Mr. Michael Wayson
Enterprise Architecture & Standards Directorate
Office of the DoD Deputy Chief Information Officer
(703)

2. DoDAF Definition
DoDAF V2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate DoD managers at all levels to make key decisions more effectively through organized information sharing across Department, Joint Capability Areas (JCAs), Component, and Program boundaries.

3. DoDAF V2.0 Goals Support the Department’s core processes:
Capabilities Integration and Development (JCIDS)
Planning, Programming, Budgeting, and Execution (PPBE)
Acquisition System (DAS)
Systems Engineering (SE)
Operations Planning
Capabilities Portfolio Management (CPM)
Establish guidance for architecture content as a function of purpose – “fit for purpose”
Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

4. DoDAF V2.0 What has been delivered?
Volume 1 – Manager’s Guide
Guidance for Development, Use, and Management of Architectures
Volume 2 – Architect’s Guide
Describes construction of Architectures, the DODAF Meta-model, Data Exchange Requirements, and Development of the Architectural Models in technical detail
Volume 3 – Developer’s Guide
Introduces the DoDAF Meta-Model Physical Exchange Specification

5. DKO DoDAF Journal
What has been delivered in the DKO DoDAF Journal (
Models, Evaluation, Process
Other Information (
Meta-Model Data Dictionary (Zip File)
Physical Exchange Specification XSDs (Zip file)
DoDAF Product Development Questionnaire Analysis Report (Capability and Project View examples and others are here)
The DKO-S DoDAF Homepage is
Need a sponsored account if not Military or DoD Civilian

6. DoDAF V2.0 Promulgation Memo
Version 2.0 is the prescribed framework for all Department architectures and represents a substantial shift in approach.
Don’t redo current architecture
Architectures shall comply with Version 2.0 in their next major release.
Update only in the next release
Does not prevent early adoption of DoDAF V2.0

7. VERSION 15
3/25/ :01
Value of DoDAF V2.0
DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development.
Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs.
Adoption of DoDAF V2.0 benefits the decision-maker and the architect with the freedom of presenting the architectural data in the terms for the decision-makers.
Facilitates development of architectural descriptions under Service-Oriented Architecture (SOA)-related techniques and tools
Adheres to the DoD Acquisition Life Cycle methodologies contained in the DoD Acquisition Guide
Can be used in conjunction with Lean Six Sigma and other Process Improvement methods 7

8. DoDAF V2.0 Focus
Results: Better ANALYSIS and Decisions.
Focus: architecture DATA, not Products
The DoDAF Meta-model (DM2) supports the architecture content of the DoD Core Processes
The relationships captured in DM2 supports qualitative and quantitative analysis
By being able to relate architectural descriptions, with a common architecture vocabulary, better analysis across architectural description can be performed .
Data allows better analytical results for the decision makers. 8

9. Shift from Product-Centric to Data-Centric Focus
Prior versions of DoDAF and earlier C4ISR versions of the Architecture Framework have emphasized reusable and interoperable data organized into ‘products’ (e.g., graphical representations or documents)
DoDAF V2.0 emphasizes focus on data, and relationships among and between data rather than the presentations of products
Emphasizes on utilizing architectural data to support analysis and decision-making,
Greatly expands the types of graphical representations that can be used to support decision-making activities.
Supports innovative and flexible presentation of the architectural data in a meaningful, useful, and understandable manner
DoDAF 2.0 significantly refocuses the architectural concepts that have been in play for many years. First and foremost, the focus is on DATA, not architecture products. Data is needed for good analysis and better decisions. How these decisions are made within the culture of an organization should not artificially change just because we publish a Framework.
Instead, this version discusses how to collect the data needed, validate that data, organize that data, and THEN form it into models, views, and viewpoints that graphically express the data. For those that have been happy with the older ‘DoDAF products’, please be assured that they are still being supported, along with many other views. The difference is that you can choose HOW to express your data in ways that better fit both your organizational preferences, and your specific project needs

10. DoDAF 2.0 focuses architecture development to ‘Fit for Purpose’
DoDAF 2.0 introduces ‘Fit-for-Purpose’ architecture as one that is appropriately focused on supporting the stated objectives
‘Fit-for-Purpose’ architectures
Respond to the stated goals and objectives of a process owner
Are useful in the decision-making process
Respond to internal and external stakeholder concerns
‘Fit-for-Purpose’ enables the architect to focus on collecting data and creating views that are necessary for the decision-maker’s requirements, and focusing the architecture to align to the decision-maker’s needs 10

11. Data-Centric: Original DoDAF Views have been expanded to better organize information, and reflect data that practitioners actually use
Modified Viewpoints
The original DoDAF Systems View has been separated into a Systems Viewpoint (SV) and a Service Viewpoint (SvcV) to accommodate extension to both systems and software/services engineering practice
All the models of data (Conceptual, Logical, and Physical) have been moved into the Data & Information Viewpoint (DIV)
The Operational Viewpoint (OV) now describes rules and constraints for any function (business, intelligence, warfighting, etc)
Technical View (TV) has been updated to the Standards Viewpoint (StdV) to describe business, commercial, and doctrinal standards in addition to technical standards
The All Viewpoint (AV) is essentially the same.
New Viewpoints
Capability Viewpoint (CV) focuses on Capability data in support of Capability development and to standardize the capture of capability data
Project Viewpoint (PV) focuses on the Portfolio Management/CPM information to explicitly tie architecture data to project efforts 11

12. DoDAF Evolution To Support “Fit For Purpose” Architecture
CADM Separate
Baseline For DoDAF 1.5
Removed Essential & Supporting Designations
Expanded audience to all of DoD
(Published in 2003)
DoDAF 1.5
Addresses Net-Centricity
Volume III is CADM &
Architecture Data Strategy
Addresses Architecture Federation
Baseline for DoDAF 2.0
Shifted away from DoDAF mandating
a set of products
(Published in 2007)
DoDAF 2.0
Cover Enterprise and
Program Architecture
Emphasize Data versus
Products
Tailored Presentation
AV-1 to capture federation
metadata
Quality Support to Decision
Processes
FEA & Allied/Coalition
Support
Journal
- Errata & Interim Releases
DoDAF
2.0

13. DoDAF V2.0 DoDAF Metamodel (DM2)
Fit For
Purpose
Presentation
Dashboards
Graphical
Depictions
Reference
Models
Fusion
Products
Composite
DoDAF V2.0
DoDAF V1.5
Standards
Viewpoint
Operational
Rest of OVs
All TVs
All
All AVs
Systems
Viewpoint
All “Systems”
Versions of
SV Products
Data &
Information
Viewpoint
OV-7
Services
SV-11
All “Service”
Versions of
SV Products
DoDAF Metamodel (DM2)
DoDAF 2.0 is a more focused approach to supporting decision makers than prior versions.
In the past the decision maker would look at DoDAF offerings and decide which were appropriate to their decision process. An example is the JCIDS process architecture requirements inside their documentation (IDC, CDD, CPD, etc.).
Additionally, older version architecture description products were “hard-coded,” so to speak, as to content and how they were visualized. Many times this lead to a lack of understanding and usefulness for the intended audience.
DoDAF 2.0, based on process owner input, increased focus on architecture data, and a new approach for presenting architecture information has addressed the issues.
BUILD ONE:
The original views (OV, SV,TV, AV) have had their content reorganized to better address their purpose
The Services portion of the older “Systems and Services” view is now a net-centric view that addresses in more detail our net-centric or services oriented implementations
All of the views of data, be they conceptual, logical, or physical, have been place in one view rather than spread out through all of the views.
BUILD TWO:
The new Systems view better accommodates our legacy system descriptions.
The new Standards view can now describe technical, business, and commercial standards applicable to our systems and services.
The operational view now can describe rules and constraints for any function (business, intelligence, warfighting, etc.) rather that just those derived from data relationships.
The standards view also now contains standards that can be applied from a technical, business, doctrinal, or commercial perspective.
BUILD THREE:
The emphasis within the Department on Capability Portfolio Management and feedback from the Acquisition community, the Capability and Project Views have been added through a “best of breed” analysis of the MODAF and NAF constructs for both.
Workshops with the Systems Engineering community have brought them and the architecture community closer together on defining the DoDAF architecture content that would be useful to the Systems Engineering process and has resulted in a new Systems Engineering View.
There is also a approach to the presentation of architecture description content that moves away from analytic and narrowly focused architect portrayals for architects. The term we have coined (stolen from the Air Force) is “fit for purpose” presentation. Through various techniques and applications, the presentation of architecture description data will increase customer understanding and architecture’s usefulness to decision making by putting the data underlying the architectural models into the context of the problem space for each decision maker.
Capability
Viewpoint
Project
New
Updated
Moved

14. Perspectives: Viewpoints That Fit-the-Purpose
Renamed
New
New
New
Overarching aspects of architecture context that relate to all models
All Viewpoint
Articulate the data relationships and alignment structures in the architecture content
Data and Information Viewpoint
Articulate applicable Operational, Business, Technical, and Industry policy, standards, guidance, constraints, and forecasts
Standards Viewpoint
Systems Viewpoint
Articulate the legacy systems or independent systems, their composition, interconnectivity, and context providing for, or supporting, DoD functions
Services Viewpoint
Articulate the performers, activities, services, and their exchanges providing for, or supporting, DoD functions
Operational Viewpoint
Articulate operational scenarios, processes, activities & requirements
Capability Viewpoint
Articulate the capability requirement, delivery timing, and deployed capability
Describes the relationships between operational and capability requirements and the various projects being implemented; Details dependencies between capability management and the Defense Acquisition System process.
Project Viewpoint
New
DoDAF organizes the DoDAF-described Models into the following viewpoints:
The All Viewpoint describes the overarching aspects of architecture context that relate to all viewpoints.
The Capability Viewpoint articulates the capability requirements, the delivery timing, and the deployed capability.
The Data and Information Viewpoint articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services.
The Operational Viewpoint includes the operational scenarios, activities, and requirements that support capabilities.
The Project Viewpoint describes the relationships between operational and capability requirements and the various projects being implemented. The Project Viewpoint also details dependencies among capability and operational requirements, system engineering processes, systems design, and services design within the Defense Acquisition System process. An example is the Vcharts in Chapter 4 of the Defense Acquisition Guide.
The Services Viewpoint is the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.
The Standards Viewpoint articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services.
The Systems Viewpoint, for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.
Architecture viewpoints are composed of data that has been organized to facilitate understanding. 14

15. DoDAF V2.0
The logo indicates the change with DoDAF V2.0. With authoritative data, using a vocabulary for architects, a development method, and desired presentations, an architectural description can be ‘Fit-for-Purpose’ for the Decision-makers. 15

16. “Fit for Purpose” Architecture Descriptions
There are now 52 DoDAF-described Models --- as w/ past versions of DoDAF you only build the ones you need to get the information you need.
It's the data behind the models that Decision-Makers really care about.
Models
Based on models and authoritative information (data), the architectural description can support desired presentations for multiple purposes. 16

17. DoDAF V2.0 Focus: Terms DoDAF V1.5 DoDAF V2.0 Architecture
Alignment with ISO and 15407
DoDAF V1.5
DoDAF V2.0
Architecture
Architectural Description
Architecture data
Architectural data
Product
Model (a template for collecting data)
View (a model with data for an architecture)
View
Viewpoint
Models are templates for organizing and displaying data in DoDAF 2.0
Previous versions of DoDAF referred to these as ‘Products’
An example of a Model is an OV-2, OV-5, SV-1, CV-5
Views are the result of collecting and populating Models with data and then presenting it
Views are a Model populated with specific data
An example of a view is a MOC OV-2, MDA OV-6c, NAVFAC SV-1
Viewpoints are a collection of models/views
Previous versions of DoDAF just referred to these as ‘Views’
Examples include: All Viewpoint (AV), Operational Viewpoints (OV), Capability Viewpoint (CV)
The collection of information, specifically Views and/or Viewpoints, used to document the architecture is referred to as an Architectural Description
Previous versions of DoDAF referred to these as just an ‘Architecture’
A few words about terminology before we go very far. There is a lot of terminology in the presentation, and you will be faced with it each time you discuss an architecture. In addition, there are changes from previous versions of DoDAF that you might be familiar with, and normally use.
In our part of the engineering world, everything starts will identifying a need, developing a plan for action, and collecting information about whatever it is that seems to need update or other types of change.
Unfortunately, data or information is not easy to read or even pretty to look at. For that reason, people create presentations, such as this, to explain what they mean, seek further information, do analysis, and eventually gain concurrence.
To do those things, we in the community look for ways to explain what we mean. Generally, for technical things, we use models—templates that look the way we usually express ourselves. When we ‘fill in’ the data, we have a view of the data. We used to call a view a ‘product’. A collection of these views is called a viewpoint, and becomes the architectural description.
The difference is that you don’t have to use the examples contained in DoDAF—they are NOT required. You can create your own if you wish from the data collected. These are called User-created Views or Fit-for-Purpose Views. If you are comfortable with the older DoDAF ‘products’, then you can use the DoDAF-described Views—all of the old products are listed among the DoDAF-described products.
DoDAF does describe a number of new views, as you will soon see. There is a lot of new material in DoDAF 2.0

18. Operational Model Example Architectural Description
DoDAF V2.0 Focus: Architecture Models + Data = Architectural Description
Operational Model Example
Things
Individuals
Types or classes of individuals or things
The framework enables architecture content to be built that is “Fit for Purpose”, defined and described in Volume 1 as architecture, which is consistent with specific project or mission objectives. Because architecture can be applied at myriad levels of an enterprise, the purpose or use of architecture at each level will be different in content, structure, and level of detail. Pulling everything together that we know about an architecture—the viewpoints, requirements, and expected outcomes, we have an architectural description.
In order to ensure that architectural descriptions meet program and mission objectives, the approach to architecture development must be tailored to address a specific, well-articulated, and understood purpose. This will help to ensure that necessary data collection, to an appropriate level of detail, is undertaken, completed, and supportive of specific decisions or objectives.
Architectural description: A collection of products to document an architecture. An architectural description generally contains one or more viewpoints to express the business, service, system and other elements of the overall project or program.
Architecture: 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.
Architecture
Data + Metadata
Architecture
Models
Architectural Description
Fit-for-Purpose (FFP)
Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs. 18

19. Methodology: DoDAF V2.0 Six-Step Architecture Development Process
Determine the
intended use of
the architecture 1
Determine
scope of
architecture 2
Determine data
required to
support
development 3
Collect, organize,
correlate, and
store architecture
data 4
Conduct
analyses in
support of
objectives 5
Document
Results IAW
Decision-Maker
needs 6
Provide list of data
needed and use
cases
3.1
Model to
DM2 Concept
List
Review list of
architecture data
and determine if
it meets the use
3.2
DM2 Conceptual
Data Model &
Logical Data Model
Assist with the
Architect’s
data collection
processes
4.1
List of
Potential
Collection
Methods
Selected
Verify the data
collected meets
the use cases
5.1
Example
Uses
Fit-for-Purpose
Use
Determine how
data needs to be
presented
6.1
Legacy
Products
User
Requirements
Presentations
Detailed
Steps for
Decision-
Maker
It is important to note at the outset that utilizing this methodology for your architecture effort is NOT mandatory. It has been provided in DoDAF 2.0 as a means for organizations to adopt a generic, easy-to-use method for creating an architectural description, and for new teams with little experience.
If an organization prefers to use its own methods, then the generic methodology is there to compare to ensure that all the needed steps are contained in the methodology the organization prefers to use in its own efforts.
There are six steps is the DoDAF methodology:
1-Determine the intended use of the architecture
2- Determine the scope of the architecture
3- Determine data required to support architecture development
4- Collect, organize, correlate and store data
5- Conduct analysis in support of architecture objectives
6- Document results
Managers don’t do all of these steps. The first 2 (speak to) are the managers’ domain, as is Step 5. The rest are the domain of the architect and development team, with the manager acting as a subject-matter expert, where needed.
With the updated process, DoDAF V2.0 describes Roles and Responsibilities for the Decision-maker throughout the architecture development effort.

20. Data: DoDAF Meta-Model (DM2)
Purposes:
The vocabulary for description and discourse about DoDAF models (formerly “products”) and core process usage
Specification for federated data exchange between:
architecture development and analysis tools
architecture databases
other authoritative data sources
Support discovery and understandability tenants of NCDS:
Discovery DM2 categories of information
Understandability thru precise semantics augmented with linguistic traceability
Capture and express Architectural Descriptions in a common, understood language for the exchange of architecture information 20

21. Data: Types of Data in DoDAF V2.0 (known as Conceptual Data)
Projects
Goals
Rules
Measures
Locations
Activities
Performers
Resource Flows
Information and Data
Training, Skill, Education
Capabilities
Services
The new DoDAF meta-Model is much simpler and easier to understand than the old CADM Model from previous versions of DoDAF. There are twelve data groups, each of which collects some specific type of architecture data.
[Go through groups]
Internal [Project, Goals, Training, skill, education]
Architectural [Rules, measures, Locations, Activities, Performers, Resource Flows, Capability, Services]
Informational [Information and data]
Data may be activity data, system or service data, or network data, or any of a number of data categories that contain appropriate data. 21

22. The DoDAF Meta-model Improvements
High-level conceptual model developed with easily understood terms and descriptions
Semantically correct without broken or obscure associations and relationships
Only that data related to architecture development in Departmental core processes
Extensible and Scalable to support “Fit-for-Purpose” developments
Small and compact versus large, cumbersome, and difficult to read

23. DoDAF V2.0 Conformance
The data in an architectural description is defined according to the DoDAF Meta-model (DM2) concepts, associations, and attributes.
The information captured in an architecture tool is consistent with the DM2 concepts, association, and attributes.
Architectural data should be stored in a recognized commercial architecture tool that conforms to industry standards.
Tools, preferably data-driven, can be used for the PRESENTATION of architectural data, but it must be based on DATA.
The architecture data is capable of transfer in accordance with the UPDM and PES

24. DoDAF Meta-model (DM2) and Unified Profile for DoDAF and MODAF (UPDM)
DoDAF Meta-model (DM2)/Physical Exchange Specification (PES) – A data model that defines conceptual, logical, and physical views of the information requirements for DoD architectures.
A language for the DoD architect
A model for ALL tool vendors
An exchange schema for interoperability
Unified Profile for DoDAF and MODAF (UPDM) 1.0 – An Object Management Group specification for UML tool vendors to follow for consistent representations/exchanges of DoDAF V1.5/MODAF V1.2 architectures.
A specification from which UML/SYSML tool vendors can implement
UPDM 2.0 – A new effort by the Object Management Group to update UPDM for DoDAF V2.0 and MODAF V1.3.

25. DISR and MDR
DoD Information Technology Standards and Profile Registry (DISR) – Registry of standards for the Department; UPDM is in DISR because it is a standard developed by a Voluntary Consensus Standards body.
DoD Metadata Registry (MDR) – A registry of data models, vocabularies, and schemas to support COI collaboration

26. DoDAF V2.0 Summary
DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development.
It is all about the decision-makers and the data!
Fit-for-Purpose describes an architecture that is appropriately focused and directly support customer needs or improve the overall process undergoing change. The models provide choices, based upon the decision-maker needs.
Adoption of DoDAF V2.0 benefits the decision-maker and the architect with the freedom of presenting the architectural data in the terms for the decision-makers.
DoDAF V2.0 is available at:
The DKO-S DoDAF Homepage is