1. Introduction USCENTCOM 15 July 2009 Mr. Michael L. Wayson
Enterprise Architecture & Standards Directorate
Office of the DoD Deputy Chief Information Officer
(703)

2. Released 28 May 2009 DoDAF v2.0 Spiral Approach Spiral IV Spiral I
VERSION 15
6/18/ :13
DoDAF v2.0 Spiral Approach
100% of all Requirements
Spiral IV
10% of all Requirements
Spiral I
35% of all Requirements
Spiral II
90% of all Requirements
Spiral III
Draft Conceptual Model
Draft DoDAF Outline
Volumes I –II Initial Write-ups
Final Deliverable
Volumes I – III
Journal
Released
28 May 2009 CT
Volumes I – II Updates
Conceptual Model
Fit for Purpose Concept
Customer Requirements
DoDAF Structure
Enterprise Architecture
Volume I – III Updates
Exchange Specification
Conceptual and Logical
Data Model Updates
New Potential Views
Journal Layout 2 2 2

3. 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
DoDAF Journal (
On-line interface providing examples, description of best practices, lessons learned, and reference documents supplementing the information in the three volumes
DoDAF Journal Other Information (
Meta-Model Data Dictionary (Zip File)
Physical Exchange Specification XSDs (Zip file)
DoDAF Product Development Questionnaire Analysis Report

4. 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
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.

5. DoD Architecture Framework Version 2.0 Executive Overview
SOUTHCOM
13 July 2009
Good morning
I am John Tieso from Booz-Allen Hamilton and a member of the Development Team that has been working to provide you with a new generation DoD Architecture Framework (DoDAF). Over the next hour, we will introduce the new DoDAF to you, explain its changes from previous versions, and prepare you for its introduction.
As senior managers, we are not expecting that you will become DoDAF experts—only that you will have a working knowledge of what it is, what is helps an architect and development team do, and what to expect as a result
Mr. Charles Thornburg
Enterprise Architecture & Standards
Office of the DoD Deputy Chief Information Officer (703) 5 5

6. Executive Overview Agenda
Key Concepts
DoDAF V2.0 Focus
Methodology
Perspectives
Conformance
The agenda this morning is straightforward. First we start with the focus of the new DoDAF.
We will then take you through a quick overview of the Models and architectural descriptions; how to select viewpoints that fit the purpose for which an architecture is being created, and the terms that we use. This section introduces you to the views and viewpoints (What we used to call products) that will be expanded on later in the morning by Charles Thornburg.
We will discuss, again briefly, the data in the new DoDAF meta-model, and we will end an introduction to the DoDAF six step development process.
There will be time at the end of the presentation for questions but, if, during the presentation you have a very brief question, please feel free to ask it. 6 6

7. VERSION 15
6/18/ :13
Key Concepts
DoDAF is prescribed for the use and development of Architectural Descriptions in the Department.
Specific DoDAF-described Models for a particular purpose are prescribed by process-owner (e.g., JCIDS) needs.
All the DoDAF-described Models do not have to be created. DoDAF V2.0 is “Fit-for-Purpose”, based on the decision-maker needs.
DoDAF V2.0 is data-centric and has shifted from the DoDAF V1.5 focus on Products, consistent with the Net-Centric Data Strategy (DoDD ).
DoDAF V2.0 prescribes a discipline for Architecture Development to determine the purpose and scope of the architecture before the data and Viewpoints are selected.
Node has been decomposed into more concrete concepts (Org, Facility, Location, System, etc.)
Examples (Views and XML) will appear in the DoDAF Journal. MW 7

8. DoDAF V2.0 Focus
Results: Better ANALYSIS and Decisions.
Focus: architecture DATA, not Products
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.
DoDAF V2.0 provides an overarching set of architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development. 8 8

9. DoDAF V2.0
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. 9 9

10. “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 10

11. DoDAF V2.0 Focus: Terms 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
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
Alignment with ISO and 15407

12. 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. 12 12

13. 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.

14. Methodology: 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. 14 14

15. Methodology: Conceptual Data Model Visualization
Vision
Organization
Realizes
Person Type
Location
Desired Effect
Is A
Produces At
Performer
Capability
Performer
Is A
Performs
Enables
Performed by
Activity
Activity
System
Service
Produces
Consumed by
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]
Resource
Subject To
Requires
Conditions
Which Is
Standards
Measures
Projects
Rules
Information Or
Materiel
Skills 15 15 15

16. Methodology: Roles in the development of Architectural Descriptions
Leadership
Program Manager
Establish the need to create an architecture
Formulate a strategy that includes the definition of a vision, objectives, and principles
Establish a program office and appoint a program manager and chief architect
Publish a program office charter
Establish a steering committee
Draft a program management plan
Obtain executive buy-in and support
Hire, train and manage program team
Establish a technical review board
Perform quality assurance, risk management, and configuration management
Chief Architect
Define and collaborate with stakeholders
Follow the selected methodology (e.g., DoDAF 2.0 Six-Step Architecture Development Process)
Supervises development of the architecture
Ensures requirements and visual representations of the architecture meet process owners’ and stakeholders’ requirements
Develop and maintain an architecture repository
Communicate with community of interest
This slide depicts the triad needed for creating a useful architecture for some specific purpose. All three of the major actors in this effort must be in synch, and understand their particular role to enable this to happen. The leadership establishes the need, and provides the continuing support to the project; the Program manager develops the management plan, designates the staff, and acts as the conduit to ensure that quality control and mission objectives are met, while the architect executes the development process.
Developing architectures is more than creating graphics and products. 16 16

17. 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

18. 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
In DODAF 2.0 we have described an expanded number of viewpoints (categories of models and views expressing differing aspects of a common architecture need) to include those shown on the slide. Some of the viewpoints were introduced in earlier versions of DoDAF, others, such as Project and Capability are new to DoDAF 2.0.
An architecture viewpoint can be displayed in a number of formats, such as dashboards, fusion, textual, composite, or graphs, which represents data and the architecture description which represents an architecture. In DoDAF 2.0, the ability is provided to create an architectural description which can be expressed in many of the same formats normally used for briefing, analysis, and decision-making.
The next few slides present a view of data from an architecture developed for the US Air Force at Arnold Engineering Development Center in Tennessee. This is the Air Force Center for R&D, testing and Analysis of aircraft, engines, and other components. Both Charles and I are using these views today with the permission of the Air Force.
Architecture viewpoints are composed of data that has been organized to facilitate understanding. 18 18

19. Perspectives: Architecture Implications for Stakeholders
Needs & Use Cases
Executive Steering Committee
Key Drivers
Operational Users
Data Collection
Goals
Decision Maker
Data Presentation
Program/Project Manager
Objectives
Operational Architect
Stakeholder’s Key Duties
Determine the purpose and scope of the architecture
Provide list of data needed and the usage of the data
Review & verify the architecture data
Determine how the data should be presented
Assist with data collection process
Pay Offs
Clarity of purpose and scope
Data is more appropriate and relevant
Data collection is more efficient and effective
Analyses of data is more meaningful
Technical Review Boards
Early on I briefly mentioned stakeholders. Gaining an understanding of the stakeholders (Even those who just might want to put that stake in your heart) is critical to the success of an architecture effort. Stakeholders are at all levels of the organization. They have a major job early in the effort in describing their needs and expectations so that the architect can deliver a product that is acceptable and useful. Each stakeholder has some different piece of information to impact that together forms the scope, purpose, and objective of the architecture. Like the triad or executive, manager and architect, the stakeholder cannot be left out of the development picture—of he/she will come back to haunt you and kill or severely injure your program.
It is all about the stakeholders and data! 19 19

20. 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. Powerpoint, Visio, Excel, etc. 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 Physical Exchange Specification (PES)
Architectures that will exchange information need to comply with DM2 PES (for the appropriate architectural data)
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.

21. 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.

22. DISR, MDR, & CADM
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
DM2 is a set of data models, so it will be here
Core Architecture Data Model – CADM is no longer the Department's standard for architecture information requirements and data exchange

23. 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
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.