1. DoDAF Delivering Architectures to the World
DoDAF Delivering Architectures to the World Presentation to GTRA Architecture GOV Symposium 07 December 2008
Walt Okon
Senior Architect Engineer for Standards
Architecture and Interoperability Directorate
Deputy Assistant Secretary of Defense for Information Management, Integration, and Technology & DoD Deputy Chief Information Officer
(703)

2. Strategy and Direction
Discussions:
DoDAF Version 2.0
Architecture Training - Architects Competencies
DoDAF Metamodel
“Fit for Purpose” Architecture
Defense-Industry Challenge – DoDAF + MODAF = UPDM
DoD IT Standards Registry (DISR)
IC & DoD IT Standards Integration
DoD GIG Technical Guidance (GTG)
Architects Career Path, Competencies & Certifications
DoD Information Sharing Environment

3. Key Policies Requiring DoDAF
Joint Staff
CJCSI F, 1 MAY 2007, “JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM”
CJCSM C, 1 MAY 2007, “OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM”
CJCSI D, 8 MAR 2006, “INTEROPERABILITY AND SUPPORTABILITY OF INFORMATION TECHNOLOGY AND NATIONAL SECURITY SYSTEMS”
Direct support for the Warfighter

4. 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
(To Be Published)
(Late 2008)

5. Focused on DoD Decisions
Cost View
Capability View
SE View
Acquisition etc.
Architecture
Views
“Fit for Purpose”
DoD Core Decision Processes
PPBE/PfM
JCIDS
DOTLMPF
Acquisition
Systems Eng M C E P
Federated Architectures
E – Enterprise
M – Mission Area
C – DoD Component
P - Program
Architecture IT
Technology
Governance
Link Technology to Objectives
Institutionalize IT Best Practices
Protect digital assets

6. 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
View
Operational
Rest of OVs
All TVs
All
All AVs
Systems
View
All “Systems”
Versions of
SV Products
Data &
Information
View
OV-7
Net-Centric
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
View
Project
System
Engineering
New
Updated
Moved

7. DoDAF 2.0 Viewpoints Capability Viewpoint Operational Viewpoint
VERSION 15
4/15/ :47
DoDAF 2.0 Viewpoints
Overarching aspects of architecture context that relate to all views
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 CT 7 7

8. Vision Statement
To enable the development of architectures that are meaningful, useful, and relevant to the DoD Requirements, Planning, Budgeting, Systems Engineering, and Acquisition decision processes.

9. DoDAF Metamodel 9

10. DoDAF Conceptual Model10

11. “Fit for Purpose” Architecture Descriptions

12. Notional DoDAF v2.0 Development Schedule (cont)
2nd
QTR 08
3rd
QTR 08
QTR 08
4th
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
EA Summit
23 Jan 08
EA Conf
14-19 Apr
Approval
DoD CIO
Plenary
22 July
Vwendor
Tool Session
Develop
Writing
Technical Editing
Cood
Plenary
1 Apr
PfM WS
PPBE WS
Feb 08
Post to
DARS
Validation
SPIRAL II
4 Apr 08
SPIRAL III
27 Jun 08
SPIRAL IV
12 Sep 08
Phase I
Phase II
Phase III

13. DODAF Version 2.0 in Coordination
Core Management Group - 10 December 2008
Discuss DoDAF Version 2 Spiral 4 Draft.
Comment and adjudication
Next Step: OSD NII Informal coordination
EA Summit – Services, Agencies, and COCOMs
DoD Executive Coordination Committee

14. Metadata Registration Service
Federation Client
Services Menu
DARS
Federated Catalog
DARS Federation Web Services
Register Provider
View Provider
Update Provider
Register Metadata
Search Holdings
SOAP
DDMS +
Metadata
(XML)
AV-1 metadata
captured and extracted
by repository/tool
environment
Federation Web services
Federation
Client
Federation
Repository
Repository/Tool
Environment

15. DoD Architecture Federation
DoD Enterprise Architecture
Tools
Ref Models
Tech Stds
Arch Guidance
Laws, Regs, and Policy
DITPR
DoD EA RM
DISR
DODAF
Laws
Regs
Policy
Force Application
TAMD
Building Partnerships
Joint Capability Areas
Command & Control
GLOBAL C2
JC2
Net-centric
COMMS & Transport
IEA
IA Architecture
Battlespace Awareness
BEA
Protection
Logistics
MS&SM
JDDA
Force Support
RP&ILM
HRM
HRM Architecture
Corporate Management & Support
WSLM FM
Other
DISA
DLA
NSA
NRO
NGA
DIA
Dept of Army
Dept of Navy
Dept of Air Force
Army
Architecture
DON
Architecture
Air Force
Architecture
Solution Architectures

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

17. UPDM – Unified Profile for DoDAF/MODAF
Adaptive
Artisan Software
ASMG
BAE Systems
DoD
embeddedPlus
Generic
Lockheed Martin Co
Mitre
MOD
No Magic
Raytheon
Rolls Royce
Sparx Systems
VisumPoint
UPDM RFC Group 17

18. UPDM in General The UPDM Group was setup to:
UPDM is an OMG initiative to develop a modeling standard that supports both the USA Department of Defense Architecture Framework (DoDAF) and the UK Ministry of Defence Architecture Framework (MODAF)
The UPDM Group was setup to:
Significantly enhance the quality, productivity, and effectiveness of architecture modeling
Promote architecture model reuse and maintainability
Improve tool interoperability and communications between stakeholders
Reduce training impacts due to different tool implementations and semantics
Improve the integration between system of systems modeling and system modeling to support post acquisition life cycle design modeling
DNDAF
NAF
UPDM
DoDAF 1.5
MODAF 1.2
UPDM is an Object Management Group (OMG) initiative to develop a modeling standard that supports both the USA Department of Defense Architecture Framework (DoDAF) and the UK Ministry of Defence Architecture Framework (MODAF). The modeling standard is called the Unified Profile for DoDAF and MODAF (UPDM).
The UPDM Group was setup to:
Significantly enhance the quality, productivity, and effectiveness associated with enterprise and system of systems architecture modeling
Promote architecture model reuse and maintainability
Improve tool interoperability and communications between stakeholders
Reduce training impacts due to different tool implementations and semantics
Improve the integration between system of systems modeling and system modeling to support post acquisition life cycle design modeling
The UPDM Group consists of fourteen companies distributed around the world. You can see a list of these companies in the member section on this web site. 18

19. Need for UPDM Motivation
Significantly enhance the quality, productivity, and effectiveness associated with enterprise and system of systems architecture modeling, promote architecture model reuse and maintainability, improve tool interoperability and communications between stakeholders, and reduce training impacts due to different tool implementations and semantics.
Improve the integration between system of systems modeling and system modeling to support post acquisition life cycle design modeling.
UPDM fully supported by DoD, MOD, IDEAS
Statement and slides available on OMG website

20. Federated Architectures The Connection

21. What the Operator Sees Today

22. What the Operator Expects to See

23. A Federation of Data Producers
Strategy
Reporting (OMB, GAO, etc)
DARS
DoD EA
Reference Models
CADM
DoDAF
NCOW RM
COI x
MILDEP
COCOM
AGENCY
COI y
DATA
REQTS.
COI = Community of Interest
CADM = Core Architecture Data Model
DoDAF = DoD Architecture Framework
NCOW RM – Net-Centric Operations & Warfare Reference Model
UPDM = UML Profile DoDAF & MODAF
DoD Decision Processes

24. DoD EA Federation Strategy
Available on DARS Website:

25. DoD EA Federation Pilot Use
BTA/USTRANSCOM/Marine Corps:
Federate the BEA with JDDA and Marine Corps Logistic architectures and register in DARS to gain visibility into “end to end” logistics process
Army:
Create a “knowledge base” through architecture federation for Army communities.
Test tools and concepts through federation, i.e. social networking (ontology development, semantic indexing,) architecture data analysis, UPDM applicability
Air Force:
Establish interface and search capability between DARS and AFARS. Demonstrate search capability
Navy:
Implement and use procedures outlined in the GIG Enterprise Architecture Federation Strategy and DARS CONOPS to create a repeatable federation process
Joint Staff/J6I:
Identify interface points and alignment between Mission Area-level architectures to obtain enable a horizontal view across mission areas and drill down to Program level.
DARS:
Develop registration template for AV-1 and DDMS metadata

26. DoD IT Standards Registry (DISR) IC/DoD IT Standards Registry

27. IT and NSS Interoperability and Supportability Policy and Process Overview
DoD Sponsored Policy
JCIDS Documents (ICD, CDD, CPD) ACAT I - III & Special Interest
J6 Interoperability Requirements Certification of All JCIDS Docs (JCPAT-E Tool)
ITS & NSS Predecessor Doc. System Profile Requirement
- IT Standards Profile (DISRonline)
- IIC Profile (LISI)
Maintain OASD(NII) JCIDS/ISP Assessment Capability (JCPAT-E Tool)
Maintain IT Standards and Profiles (DISRonline)
Certify Standards Conformance
ITS and NSS Interoperability Requirements Certification
Assessments of NR-KPP in JCIDS Docs
KM/DS
Joint Staff
J-8
CJCSI D
Joint Staff J-6 Interoperability Requirements Certification Process
DoDI
4630.8 C
CJCSM
DoDD
5000.1
JROC
FCB
JCPAT-E
ITS & NSS
Registration
DISR Online
LISI InspeQtor J6
Interoperability Requirements
Certification = •
UAM / JCPAT- E System Registration
Technical View (CDD & CPD)
Interoperability & Interconnectivity
Profile (CDD & CPD)
J6I
Stage I, II & III
Assessments
JCPAT
JCPAT
Joint Staff J-6 OASD(NII)

28. DISR and DISRonline Architecture View
Objectives:
Champion DoD’s Re-Engagement of the IT Standards Communities
Online IT standards Registry
Tri-Annual Update of IT Standards Registry
Tied to JCIDS IT Standards Conformance and Compliance Process
Intelligence Community Cross Coordination (ICSR)
Improved DoD Visibility and Participation in IT Standards Development Organizations
Develop and Register PM Standards Profiles (TV)
Standing IT Standards Working Groups Aligned to GIG Portfolio Management
DoD IT Standards Registry (DISRonline)
Lifecycle Tagged: Emerging and Retired Standards
Profile Assistance Software
Organization-Unique Bins
Information /
Guidance (I/G)
Informational Standards
Best Practices
Procedures
Policies
Manuals
Handbooks
Other IT Documents
Change Request Tool Software
PM System IT Standards Profiles
TVs *
Governance
and General Information Area
Policy
FAQs
CM Procedures
User Guides
Links
SOP
POCs
GIG Mission Area Management
Voting Tool Software Collaboration Tool Software
* May Contain Standards from Lifecycle Categories other than Mandated
DISR Mandated Standards
Mandated “Net-Centric” & Mandated Sunset “Interoperability” Standards
DISR Profile Registry Area
Key
Interface Profiles *
(KIPs)
Prescribed
Technology
Profiles *
(IPv6, PKI etc.)
Future
Enhancements
THIS SLIDE IS MORE OR LESS A NOTIONAL MODEL MEANT TO GIVE YOU IDEA OF BOTH THE FUNCTIONAL CAPABILITIES AND THE MANDATED CORE AND PROFILE REGISTRY AREAS WITHIN DISR.
THE AREAS CODED IN BLUE PROVIDE THE MANDATED STANDARDS FROM WHICH PRESCRIBED STANDARDS PROFILES ARE BUILT, SUCH AS TECHNOLOGY PROFILES LIKE IPV6, KEY INTERFACE REFERENCE IMPLEMENTATIONS, AND INDIVIDUAL PM PROFILES MAKING USE OR TAKING ADVANTAGE OF THE OTHER BLUE AREAS.
THE LEFT AND RIGHT WINGS IN THIS MODEL IDENTIFY THE OTHER CAPABILITIES OF DISR AND INFORMATION LINKS SUCH AS THE CHANGE REQUEST TOOL, THE VOTING AND COLLABORATION TOOL, AND STATIC DOCUMENTS SUCH AS THE SOP, USER GUIDE ETC.
UNDER OBJECTIVES, YOU SEE SOME OF THE POINTS I MENTIONED BEFORE BUT I’D ALSO LIKE TO POINT OUT THAT WE RECENTLY HAVE PLACED A GREATER EMPHASIS ON COORDINATING I-T AND INTEL STANDARDS WHERE THEY APPLY TO BOTH COMMUNITIES. IN FACT, WE ARE IN THE PROCESS OF SUPPORTING THE IC CIO ON THE STAND UP OF A DISR LIKE STANDARDS TOOL TO BOTH SUPPORT THEIR UNIQUE INTEL STANDARDS REQUIREMENTS AND THAT LIKE IT STANDARDS ARE CONSIDERED.
I WOULD ALSO NOTE THAT THE MANDATED SET OF STANDARDS STILL NEEDS TO ALLOW FOR A CERTAIN LEVEL OF LEGACY STANDARDS TO EXIST WITHIN THE CORE ALBEIT THEY MAY BE TAGGED AS A SUNSET STANDARD THUS SIGNALING TO OUR WORKING GROUPS THE NEED TO KEEP AN EYE ON EMERGING CANDIDATE STANDARDS.

29. Lifecycle of a Standard
Emerging
Upgradeability Should be a Concern
May be Implemented but Not in Lieu of Mandated Standard
Expected to be Mandated within Three Years
Mandated
Essential for Interoperability and Net-Centric Services in DoD
Minimum Set of Essential Standards for the Acquisition of All DoD Systems that Produce, Use, or Exchange Info, and, When Implemented, Facilitates the Flow of Info in Support of Warfighter
Sunset Tag Identifies an Event and Date to Retire a Standard
Inactive / Retired
New Standards / Technology Now Available and Implemented
Require Waiver and Migration Plan
Remain in the Registry

30. IT Standards Governance Organization Membership
Technical Working Groups

31. DoD GIG Technical Guidance (GTG)
Walt Okon

32. DoD Technical Guidance Concept
Query &
Retrieve
Identified
Interoperability
Standard,
Specifications,
And Interfaces
Capability
Development Areas
Joint Capability Areas
Standards
Specifications
Mission Area Portfolios
Community Of Interest
GIG Governance Processes
Structured and
Unstructured Sources
for Standards and
(Notional)
DARS
. . .
DKO
CADM
4630
80XX
XML
Metadata
Registry
SFIS
Taxonomy
Detailed
Standards &
Information
DISR
NCID
Technical Direction Query
Technical Direction Query
Capability
GIG
Technical Guidance
Standards &
Specifications
For
Interoperability
From the left side of the figure, the Type II Technical Direction detailed standards and specifications information are obtained from Structured and Unstructured sources such as DISR, DARS, DOL, CADM, 4630, etc. which provide the necessary content and references contributes to the Type II Technical Direction. From the right side of the figure, the identified interoperability standards and specifications that are applicable to the capability development area contribute to the Type II Technical Direction. These interoperability standards and specifications will have to be identified by system engineers and functional experts for each.
As indicated by the green arrows in the figure, the “assembling” of the set of interoperability standards and specifications for the capability portfolio area, JCA, COI, and GIG Governance Processes that a developing capability touches becomes the Type II Technical Direction (for that developing capability). The mapping of these comprise the targeted Type II Technical Direction for the user.
A portal for the delivery of Type II Technical Direction will allow a developer to determine the minimum interoperability standards and specifications. By querying on the capability portfolio area/JCA/COI that are drawn on for the capability to be developed, the portal can “assemble” the Type II Technical Direction. For example, A team building a Spend Analysis Capability under the acquisition portfolio needs to implement the following functions:
1) provide financial information to users on the GIG
2) publish the financial reporting service to the GIG
Using the Type II portal, the team can query for the capability portfolio/JCA/GIG Governance process/COI utilized. Based on the identified interoperability standards and specifications within the Business Mission Area portfolio to exchange financial information on the GIG, the portal (portlet, service) retrieves the detailed information from the standards source. Also, within the EIEMA Portfolio, the portal (portlet, can find the publication standards for the Enterprise Service Discovery Service.
XML Schemas/ Components

33. Architects Career Path Architects Competencies
Architects Certifications

34. IMPROVING DOD’S ARCHITECTURE
Guidance
DoDAF v2.0
Federated Architecture Strategy
Tools
DoD Architecture Registry System (DARS)
DoD IT Standards Registry (DISR)
Type II – GIG Technical Direction
Education and Training
DoD Architecture Training Effort
All this is nothing without Certified Architects!

35. ARCHITECTURE TRAINING
Expanded need for architectures and their significance in achieving defense of our nation results in the need for qualified architects
Therefore, we are confronted with questions:
Is there a pool of qualified architects?
What are the competencies of an architect?
Is there a core body of knowledge?
What education and training courses exist?
DoD– IT Architects Career Path–Architects Series

36. RECOMMENDED WAY AHEAD Deliver an architect career plan
Establish architecture specialties in Office of Personnel Management (OPM)
Formalize a competency framework
Implement Certificates & Certification across architecture specialties
Work with academic and educational institutions to enhance their curricula

37. ACCOMPLISHMENTS WHITE PAPER - Phase I: A Competency Framework
Defines a path for a quality architecture workforce
Provides collected data on the competencies of an architect
Architecture Education and Training DKO Site
OPM Job Family Standard Review
Clinger-Cohen Core Competency Review for Architecture
Delivered two Architecture Training Tutorials at 2008 EA Conference

38. Chief Architect, DoD Information Sharing
Sharing Environment
Walt Okon
Chief Architect, DoD Information Sharing
Architecture & Interoperability Directorate Office of the DoD CIO/ASD NII

39. DoD is part of this complex, extended information sharing enterprise…
Complexities of Information Sharing
Northeast Power Blackout
Counter Terrorism
Failed States (Haiti)
Terrorist
Actions
Natural Disasters
Warfighter
Operations
Coalition
Humanitarian
Pandemic
Flu
DoD is part of this complex, extended information sharing enterprise…

40. DoD Information Sharing Environment
Description:
– Provide a DoD Information Sharing architecture and standards capability which will support cross-community, institutional approach to the sharing of information within DoD and can apply across Federal Departments, state, and local governments
– Provide architecture and engineering guidance for DoD Information Sharing Executive and DoD Information Sharing
– Provide PM-ISE DoD’s Shared Space architecture and standard guidance to enable cross-community sharing for identifying, planning, installing, and operating capabilities that will become the ISE.

41. DoD Information Sharing Environment
FY08 Key Taskings:
– PM-ISE Chief Architect Roundtable and the CTISS Committee
– Design and deliver a CTISS Federated Standards Registry pilot
– Develop a DoD ISE Shared Space use case and concept capabilities with Net-Centric direction
– Partner with other ISE architects in the Federal Departments
– Partnership with DISA on analysis and engineering.

42. DoD Enterprise Architecture Conference 2009
Bring It All Together
DoD Enterprise Architecture Conference 2009

43. DoD Enterprise Architecture Conference 2009
All DoD Architecture Professionals
Only official Architecture Conference
Enterprise Architecture & Standards
Deliver Interoperability
1 – 5 June 2009; DoD Enterprise Architecture Conference 2009 in St Louis, MO
Deliverables

44. Chief Architect, DoD Information Sharing
Questions/Wrap-Up
Walt Okon
Chief Architect, DoD Information Sharing
Enterprise Architecture & Standards Directorate Office of the DoD CIO/ASD NII
07 December 2008