1. DoD Enterprise Architecture & Standards The Future of Architecture 16 September 2009
Walt Okon
Senior Architect Engineer
Senior Architect Engineer for Information Sharing
Enterprise Architecture and Standards Directorate
DoD Chief Information Officer
(703)

2. DoD Agenda for OMG
Future of Architecture; Vision, Mission, Deliver
0916 – 0945 DoD Organization, Governance, and Process
0945 – 1010 Refreshment Break
1010 – 1030 DoD IT Standards Program (DISR)
1030 – 1050 DoDAF Version 2.0
1050 – 1110 DoD Information Enterprise Architecture v1.1
1110 – 1120 EA Federation
1120 – 1130 Information Sharing Segment Architecture
1130 – 1140 Break
1140 – 1155 DoD Architecture Education & Training
1155 – 1210 DoD Architecture Exchange – UPDM V2.0

3. UPDM – Unified Profile for DoDAF/MODAF
Unalienable Rights: Life, Liberty and pursuit of Happiness
Defense Architecture Framework 3

5. DoD Architecture Federation
Solution Architectures
DoD Enterprise Architecture
Tech Stds
DISR
Arch Guidance
DoDAF
Ref Models
DoD EA RM
Laws, Regs, and Policy
Laws
Regs
Policy
Tools
DITPR
DARS
Force Application
Building Partnerships
Command & Control
Protection
Logistics
Force Support
Corporate Management & Support
Net-centric
Battlespace Awareness
Joint Capability Areas
Information Enterprise Architecture
Dept of Army
Dept of Navy
Army
Architecture
DON
Air Force
SOCOM
DISA
DLA
NSA
NRO
NGA
DIA
Other
Dept of Air Force 5 5

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

7. DoDAF Version 2.0 Metamodel7

8. “Fit for Purpose” DoDAF Architecture Descriptions

9. DoDAF V 2.0 Delivery DoDAF V2.0 is available at:
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.

10. 10 10

11. Architecture Exchange - Why
Motivation
US DoD and UK MOD interested in leveraging commercial standards for their Military Architecture Framework
Military Architecture Framework Tool Interoperability
Key Goal for DoD, MOD, NATO
Formal MetaModel basis for the Military Architecture Framework
Critical to Interoperability Objectives
Proliferation of Military Architectural frameworks
DoDAF, MODAF, DNDAF, NAF, AGATE, ADOAF, MDAF, etc.

12. UPDM – Unified Profile for DoDAF/MODAF
Walt Okon Matthew Hause
UPDM RFC Group
Adaptive
Artisan Software
ASMG
BAE Systems
DoD
DND
embeddedPlus
Generic
IBM
Thales
Lockheed Martin Co
Mitre
L3 Comms
MOD
NoMagic
Raytheon
Rolls Royce
Sparx Systems
VisumPoint
Selex 12

13. Defense-Industry Challenge: Synchronization of DoDAF-UPDM Lifecycles
Produces
Develops
Generic
Modeling &
Engineering
Standards
3. Vendors
Produce Product
Versions
Defense Domain Tools
“Just-In-Time”
Governments
Produce Baselines
Develop, Evolve &
Harmonize
Defense Enterprise
Architecture
Frameworks
For Acquisition
RFC
Leverages Vendors Standards-
Based Tools & Government Frameworks 13

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

15. 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 overarching architecture concepts, guidance, best practices, and methods to enable and facilitate architecture development. 15 15

16. Improving DoD’s Architecture
Guidance
DoDAF v2.0
Federated Architecture Strategy
Tools
DoD Architecture Registry System (DARS)
DoD IT Standards Registry (DISR)
GIG Technical Guidance (GTG) Tool
Education and Training
DoD Architecture Training Effort
All this is nothing without Certified Architects!

17. Architecture Training DKO Site
URL -

18. DoD Architecture Education & Training
DoD must identify Architect’s opportunities for Education & Training
Identifies core KSAs Architects must have to be able to design, develop, and deliver DoD architectures that enable senior leader decision making and engineering design
Analyze and define the types of architecture training at different levels of architecture
DoD – IT Architects Career Path–Architects Series
Define a certification requirement and process

19. White Paper: Outline Preface Introduction Purpose, Scope, and Approach
Findings
Recommended Way Ahead
The DoD Architect Competency Framework
A culmination of input gathered through research, interviews, and workshops on the standard knowledge, skills, and abilities DoD Architects should obtain at varying levels of maturity.

20. DOD Architect Levels Level 1 Development Level 2 Analysis
Primary function is to develop architectures based on user requirements and input from subject matter experts
Level 2 Analysis
Primary function is to analyze architectures for the purposes of integration, interoperability, gap analysis, risk assessment, leveragability, compliance, and business decision making
Level 3 Management
Primary function is to lead and manage an architecture effort through its entire lifecycle, from development to execution/implementation
White paper identifies the functions and associated KSAs for each level. These KSAs are independent of educational degree, working domain (contractor, civilian, military), or career title (GS level, rank, or role).

21. Roadmap to the Future
Deliver an IT EA Education & Training Strategic Plan
Deliver an architect careers plan
Establish architecture specialties in Office of Personnel Management (OPM)
Formalize a Architect’s Competency Framework
Implement certification across architecture specialties
Work with academic and educational institutions to enhance their curricula

22. DOD IT ENTERPRISE ARCHITECTURE TRAINING & EDUCATION
Strategic Plan 2009 Draft 1.7a

23. DKO Site
URL -

24. DoD Enterprise Architecture Conference 2010, San Antonio, TX
May 10-14, 2010
DoD Enterprise Architecture
Conference 2010, San Antonio, TX
Save the date!