DoDAF 2.0 Overview and Architecture Federation Pilot

1. DoD-CIO/ASD-NIIArchitecture & Interoperability DirectoratePresentation to CAFJanuary 22, 2008

2. DoDAF 2.0 Overview and Architecture FederationPilotAlan Golombekalan.golombek@osd.mil(703) 607-5257

3. High Level DoDAF Terminology • Views – Perspectives of architecture content: • Operational View = Requirements • Systems View = Implementations • Technical Standards View = Standards • All View = Summary Information & Definitions • Products - Graphical, tabular, or textual representations of architecture data within the views • Architecture Description - A set of architectural data for the products in the 4 views. This common foundation for development ensures the use of similar formats for displaying information enabling the integration, federation, comparison, and reusability of disparate architectures.

4. DoDAF Core Architecture Data Model (CADM) The CADM is the common foundation to ensure the capture of consistent data and their relationships to enable the integration, federation, comparison, and reusability of architectures.

5. Key Policies Requiring DoDAF Joint Staff • CJCSI 3170.01F, 1 MAY 2007, “JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM” • CJCSM 3170.01C, 1 MAY 2007, “OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM” • CJCSI 6212.01D, 8 MAR 2006, “INTEROPERABILITY AND SUPPORTABILITY OF INFORMATION TECHNOLOGY AND NATIONAL SECURITY SYSTEMS”

6. Key Policies Requiring DoDAF Office of the Secretary of Defense • DoD Directive 5000.1, 12 MAY 2003: “The Defense Acquisition System” • DoD Directive 5000.2, 12 MAY 2003: “Operation of the Defense Acquisition System” • DoD Directive 4630.5, 5 MAY 2004: “Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS)” • DoD Directive 8115.01, 10 OCT 2005: “Information Technology Portfolio Management” • DRAFT DoD Instruction 8210: “Global Information Grid (GIG) Architecture Development, Maintenance, and Use”

7. (Published in 2003) (Published in 2007) DoDAF Evolution To Support “Fit For Purpose” Architecture • DoDAF 1.0 • CADM Separate • Baseline For DoDAF 1.5 • Removed Essential & Supporting Designations • Expanded audience to all of DoD • 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 • 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)

8. Net-Centric Concepts addressed in DoDAF 1.5 The following Net-Centric Concepts were presented and discussed to be included in DoDAF 1.5 • Populate the Net-Centric Environment • Represent what information and capabilities are being made available (as services) to the NCE so they can be leveraged by others. • Utilize the Net-Centric Environment • Represent what information and capabilities provided on the GIG will be available to service consumers through service discovery and leveraged across the NCE. • Support the Unanticipated user • Represents that 1) capabilities can scale to support both human and system unanticipated users, and 2) the posting of information, data, applications and services to the NCE occur as soon as possible to enable multiple use. • Leverage COIs to promote Jointness • Represents the utilization of COI specific interface specifications, taxonomies, and common vocabulary to support interoperability in the NCE. • Support Shared Infrastructure • Represents that the shared physical and services infrastructure (the EIE) is identified and leveraged in the NCE.

9. Attribute 1.N: Data elements 5. Propose Net-Centric Guidance for DoDAF 1.5 4. Apply Data Elements to DoDAF 1.0 views and identify gaps 3. Decompose attributes to Data Element level DoDAF 1.5 Development Process 1. Review Concept and attributes from Net-Centric Concepts workshop … … … 2. Review architectural relevance of each attribute

10. Volume II Net-Centric Example “5.4.3 Net-Centric Guidance for SV-4b Augmented Product Purpose. In a net-centric architecture, the SV-4b is used todocument service functionality that is exposed to the NCE, their respective grouping into service families, and their service specifications. It is the SV counterpart to OV-5. Although there is a correlation between OV-5 or business-process hierarchies and the service functional hierarchy of SV-4b, it need not be a one-to-one mapping, hence, the need for the Operational Activity to Services Traceability Matrix (SV-5c), which provides that mapping. Net-Centric Product Description. The SV-4a traditionally describes system functions and the flow of system data between functions and correlated to SV-1 and SV-2 systems. In the NCE, the SV-4b should capture and depict how services are orchestrated together to deliver functionalityassociated with an operational need. In industry, this is often referred to as composeable applications. Services are a key means to share information and capabilities in the NCE and can be captured in the SV-4b by relevant service groupings or families to assist in understanding how a set of services align with an operational domain or a system capability. The SV-4b also documents the data flows between services and may represent external services, systems, or humans that interact with the service. Multiple SV-4b products can be utilized to show deeper levels of detail as system nodes are decomposed into service families which further decompose into services that consist of specific operations and data. In the NCE, services require robust and consistent descriptions to operate in the NCE where service capabilities are discoverable and able to be consumed in a scalable and flexible manner. The SV-4b should capture and depict information about each service that collectively represents the service specification. A service specification should be provided for each service that is or will be provided to the NCE. The service specification enables services to be documented in a consistent manner, and the DoD-wide SST should be used to the extent possible for describing each service. Regardless of the precise SST, the necessary minimum subset of information from the SST for each service must be captured in the SV-4b: - Interface Model Category includes information of the service specification that identifies the service and enables service consumers to discover the service and determine the service’s suitability for their needs. It also provides assistance in the usage of the service, and includes service policies and the following types of attributes: - Service Name is a short descriptive name for the service to be provided and as it appears in the SV-1…” Document service functionality that is exposed to the NCE Capture and depict how services are orchestrated together to deliver functionality Services are a key means to share information and capabilities in the NCE Document data flows between services Service Specification Template Service Specifications

11. DoDAF v1.5 Volume II Changes

12. DoDAF v1.5 Volume II Changes

13. DoDAF v1.5 Volume II Changes

14. Net-Centricity Sources & Prioritization Decision Support Processes Survey, SME interviews, Feedback Workshop Inputs State of DODArchitecting Architecture Data Strategy FederationStrategy CADM 1.5 Volume I Volume II Volume III Three Integrated Volumes

15. DoDAF v1.5 Stakeholder Feedback ABM/ASM Service Oriented Architecture Other Frameworks Net-Centric Examples Service Specification Template Capability related concepts Service Interfaces Service Description Framework UPDM Net-Centricity Measurement concepts Operational Node Program vs. Enterprise Architecture Content Strategic Goals Relationship to FEA Information Assurance/Security SA and OO Architecture Tiers Relationship to NCOW RM BPMN Authoritative Sources Alignment to JCIDS/JROC

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

17. Definition for the DoD Architecture Framework The DoD Architecture Framework is the structure for organizing architecture concepts, principles, assumptions, and terminology about operations and technology into meaningful patterns to satisfy specific DoD purposes.

18. DoDAF 2.0 Development Management Structure

19. SE Workshop JCIDS Workshop PPBE Workshop DAS Workshop PfM/CPM Workshop Operations Workshop DoDAF 2.0 Development Organizational Structure EA Summit CIO Executive Board Core Management Group Development Team DoDAF Plenary Presentation Working Group OUSD(P&RM)* Method Working Group BTA* Data Working Group ARMY* * Led and Staffed by Component Representatives

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

21. DoDAF 2.0 Development Development Approach

22. DoDAF 2.0 CADM 2.0 Journal 2.0 DoDAF v2.0 Development Approach DAS Process JCIDS Process PfM/CPM Process Operations Processes PPBE Process SE Processes Requirements Workshops Input Comments & Stockholder Feedback Plus Workshops Interviews Surveys V A L I D A T I O N Phase I: Requirements Identification Phase III: Production Technical Working Group Analysis Initial Input Derive Baseline Requirements DoDAF 1.5 Phase II: Synthesis Method Group DOTMLPF FEA MODAF TOGAF NAF SOA GAO Assessment BPMN Presentation Group Net-Centricity ASM UPDM CADM Data-Centric Policy Data Group Mediation Federation Semantic Interoperability

23. Workgroup Collaboration Definitions & Relationships Collection & Assembly Data Method Synchronization & Harmonization Rules Content Display Query Presentation Inter-dependencies based on cross process requirements

24. DoDAF 2.0 Development Outline

25. DoD Architecture Framework Version 2.0 VOLUME 1 (cont) 14. Relationships to Other Frameworks 14.1 MODAF (Copy from NAF Executive Summary) 14.2 NAF (Copy from NAF Executive Summary) 14.3 TOGAF 14.4 Zachman VOLUME 1 Executive Summary (Same for all Volumes) Introduction, Overview, and Concepts 1. Vision for DoDAF 2.0 1.1 Fit for Purpose Architecture 1.2 Goals and Objectives 2. Framework and Journal Overview 2.1 DoD Architecture Framework Defined 2.2 Purpose and Scope 3. Domains of Architecture (Strategic, Capability, and Solution) 4. Principles of Federation 4.1 FEA & DoD Reference Models 4.2 DoD Enterprise Architecture Overview 5. Customer Requirements 5.1 Support of Key Processes 5.2 The Program Tier 5.3 The Enterprise Tiers (Component, Mission Area, and Department) 6. Methodologies 6.1 Methodology Based Approach to Architecture 6.2 System – Component, Package, Deployment Diagrams 7. Presentation 7.1 DoDAF Notional Structure 7.2 Generated Views (Reports) 8. Data Focus 8.1 CADM 8.2 Exchange Standard: XML Schema Definitions (XSDs) 9. Process Performance Engineering & Metrics 9.1 Performance Engineering in Process Improvement 9.2 Metrics for Use in Testing Process Improvement 10. Analytics 10.1 Modeling and Simulation 10.2 Executable Architectures 11. Architecture Planning 11.1 Organizing the Architecture Effort 11.2 Architecture Management • Governance 13. CM (Not Instantiated Architectures) 13.1 CCB 13.2 CADM (DoD Architecture Data Model) 13.3 Generic Process Models 13.4 DoDAF 13.5 Journal VOLUME 2 1. Operations Architecture 1.1 Capabilities/Metrics 1.2 Process 1.3 Information Flow 1.4 Data Descriptions 1.5 Roles 2. Technology Architecture 2.1 Systems, Applications, Services, Interfaces 2.2 Infrastructure (Networks, CES, Computing, Spectrum) 2.3 Standards (DISR, profiles) 2.4 Data Exchange 3. Net-Centric Architecture Description 3.1 Net-Centric Perspective 3.2 Backward Compatibility with Legacy Architectures 3.3 Point to Point Connections 3.4 Support for SOA VOLUME 3 1. DODAF Metamodel APPENDICIES (Applies to all 3 Volumes): A. GLOSSARY B. ACRONYMS C. REFERENCES D. TRANSITION FROM DODAF V1.0/1.5 TO V2.0

26. DoDAF (Notional Structure) DRAFT * Implementer Responsibility

27. DoDAF (Notional Architecture Content) DRAFT Generated Presentation • Examples • SE • Acquisition • JCIDS • Capability • Cost

28. DoDAF 2.0 Development Spiral Development

29. Spiral Approach - DoDAF 2.0 Requirements Delivered by Phase Spiral 1 10% of all Requirements • High Priority • Simple • Obvious Value • Low Risk • Draft Conceptual Model • DoDAF 2.0 Outline • Volumes I-III initial write-up Spiral 4 100% of all Requirements Fulfilled * • Finalized • Volumes I-III • Journal Spiral 3 Spiral 2 35% of all Requirements Fulfilled • High Priority • Simple • Obvious Value • Draft Logical Model w/Rqts Workshop Data • Presentation Artifacts; Methods Content • Refined Volumes I-III spiral write-ups 70% of all Requirements Fulfilled • Conceptual and Logical Data Model • Presentation Artifacts • Methods Content • New Potential Views • Refined Volumes I-III write-ups • Initial v2.0 Journal * Includes requirements that require revisit or further interviews

30. Plenary 11 Dec CMG Outbrief 30 Aug EA Summit 7 Aug CMG Outbrief 19 Jul CIO EB Coord Meeting 28 Jun CMG Outbrief 27 Sep DEV-T Kickoff 2 Jun TWG Kickoff 25 Sep SE WS 17 Oct JCIDS WS 11-12 Jul All TWG 6 Dec Opns WS DAS WS Jan DoDAF Kick Off Meeting 7 Jun Bi-Weekly DEV-T Meetings SPIRAL I 18 Jan Weekly TWG Meetings Notional DoDAF v2.0 Development Schedule 4th QTR 07 1st QTR 08 2nd QTR 08 Jun Jul Sep Oct Nov Dec Jan Aug Phase I Phase II

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

32. Points of Contact • OSD • Brian Wilczynski brian.wilczynski2@osd.mil 703-607-0252 • Alan Golombek alan.golombek@osd.mil 703-607-5257 • Walt Okon walt.okon@osd.mil 703-607-0502 • Michael Wayson michael.wayson@osd.mil 703-607-0482 • Scott Badger scott.badger.ctr@osd.mil 703-607-0556 • Mike McFarren mmcfarren@mitre.org 703-489-2286 • CADM • Francisco Loaiza floaiza@ida.org 703-845-6876 • Forest Snyder forrest.snyder@us.army.mil 703-602-6365 • REQUIREMENTS BASELINE • Charles Thornburg thornburg_charles@bah.com 703-412-7937 • Hilda Pineda pineda_hilda@bah.com 703-902-4509 • SOO • Tracy LaRochelle tracy.larochelle@lmco.com 703-916-7453 • SCHEDULE • Craig Cromwell craig.cromwell@lmco.com 703-916-7456 • Tracy LaRochelle tracy.larochelle@lmco.com 703-916-7453 • DARS • Bruce Dunn bruce.dunn@us.army.mil 732-427-3674 • DEV-T LEAD • Craig Cromwell craig.cromwell@lmco.com 703-916-7456 • DEV-T SECRETARIAT • Tracy LaRochelle tracy.larochelle@lmco.com 703-916-7453

33. What the Operator Sees Today

34. What the Operator Expects to See

35. A Federation of Data Producers Federation Strategy Reporting (OMB, GAO, etc) DARS DoD EA Reference Models • CADM • DoDAF • NCOW RM MILDEP COCOM AGENCY COI x 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 DoD Decision Processes

36. DoD Architecture Federation (Notional) GIG Architectural Vision D E P T NCOW RM DoD EA RMs GIG Capability Increments DISR Warfighter Defense Intelligence Business M I S S I O N A R E A BEA 4.1 TAMD JCA GLOBAL C2 Enterprise Information Environment IA Component of the GIG (ES, IA, CI) COMMS ARMY NAVY COCOMS &Agencies AIR FORCE C O M P O N E N T DON EA Coordination Board AENIA JDDA USMCEA Efforts MCASE MAGTAF C2 Constellation LIAA JC2 GLOBAL C2 METOC HRM EA OSEA LandWarNet FORCEnet JTF HQ DCGS – A TSAT JTRS NECC P R O G R A M WIN-T Navy ERP CAC2S NMCI DJC2 GCCS M GCSS USMC - Planned - Completed - In Process Architecture Federation • Discovery and Information Sharing • What is Available? • Who Owns the Content? • Where is it Located? • What is the Current Status? • What Tool was it Developed in? • What Level of Detail? Working Draft Pre-decisional

37. DoD EA Federation Strategy Completed Available on DARS Website: https://dars1.army.mil/IER/index.jsp

38. NCES Federated Search Client Title Creator Identifier (URL) C2C Architecture AFC2ISRC https://dars1.army.mil C2C Architecture Hanscom http://hanscom.af.mil C2C Architecture STRATCOM https://dars1.army.mil DARS Federated Catalog C2C Architecture AFC2ISRC https://langley.af.mil Search Results Other Federated Catalogs Other Federated Catalogs Federated EA Catalogs GIG Architecture Enterprise Services in Use

39. DoD Architecture Federation GIG Architectural Vision DoD EA RMs NCOW RM D E P T GIG Capability Increments DISR Business Warfighter Defense Intelligence BEA 4.1 M I S S I O N A R E A TAMD JCA GLOBAL C2 Enterprise Information Environment IA Component of the GIG DON EA Coordination Board (ES, IA, CI) COMMS ARMY NAVY COCOMS/ Agencies AIR FORCE C O M P O N E N T AENIA JDDA C2 Constellation USMCEA Efforts MCASE MAGTAF LIAA JC2 GLOBAL C2 OSEA LandWarNet METOC HRM EA JTF HQ TSAT JTRS DCGS – A FORCEnet NECC P R O G R A M WIN-T Navy ERP CAC2S NMCI DJC2 GCCS M GCSS USMC - Planned - Completed - In Process DoD EA Federation Pilot Participants: BTA USTRANSCOM Army DARS Marine Corps Navy Air Force Joint Staff – J6I Objectives: • Develop a Component value proposition to test through architecture federation (Use Case) • Use Registration and Discovery services (GAES) • Federate the items in the “Table” Graphic (minimum) • Validate federation process and tools (technical) • Validate usefulness of federation (use cases) • Issue federation implementation guidance

40. DoD EA Federation Pilot Use Cases • 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

41. DoD EA Federation Pilot Schedule • September – October 2007 • Acquire resources to conduct pilots • Develop Use Cases • November 2007 – February 2008 • Conduct Pilots • Analyze results • Submit findings and lessons learned • Initial Pilot Demonstrations to FJAWG • March – April 2008 • Prepare Demonstrations • Demonstrate Architecture Federation at EA Conference • Conduct Panel Discussion at EA Conference: • Architecture Federation (General) • Architecture Federation Pilot Findings

42. Points of Contact • OSD: DoDAF & Architecture Federation • Brian Wilczynski brian.wilczynski2@osd.mil 703-607-5257 • Walt Okon walt.okon@osd.mil 703-607-0502 • Alan Golombek alan.golombek@osd.mil 703-607-5727 • Michael Wayson michael.wayson@osd.mil 703-607-0482 • Scott Badger scott.badger.ctr@osd.mil 703-607-0556 • DARS • Bruce Dunn bruce.dunn@us.army.mil 732-427-3674 • Tracy LaRochelle tracy.larochelle@lmco.com 703-916-7453