IDEAS Meeting London Status on DoDAF and CADM 10-14 September 2007

1. IDEAS MeetingLondon Status on DoDAF and CADM10-14 September 2007 Michael Wayson Architecture & Interoperability Directorate Office of the DoD CIO

2. Why DoDAF 2.0 DoDAF Evolution Management Structure Development Approach Schedule Agenda

3. Why DoDAF 2.0? • There is insufficient “decision making” support within the DoDAF regarding the major DoD Processes, i.e., JCIDS, PPBE, DAS, PfM • DoDAF should be “data centric” vs. “product centric” – more dynamic/flexible ‘presentation capabilities’ must be available • Full “semantic interoperability” requires not only ‘data alignment’ but also consensus on ‘methodology’

4. To enable the development of architectures that are meaningful, useful, and relevant to the DoD Requirements, Planning, Budgeting, Systems Engineering, and Acquisition decision processes. OASD(NII) Response Redefine DoDAF Purpose Redefine “DoD Architecture Framework” The DoD Architecture Framework is the structure for organizing concepts, principles, assumptions, and terminology into meaningful patterns to satisfy specific DoD purposes.

5. A Solid Foundation Has Been Established DoD Architecture Framework (DoDAF) Core Architecture Data Model (CADM) DoD Architecture Registry System (DARS) Net-Centric Operations and Warfare Reference Model (NCOW-RM) DoD Enterprise Architecture Reference Models Interoperability Policy DoD IT Standards Registry (DISR) These products need to become more agile to meet customer needs Identify and Leverage “Point of Departure”

6. DoDAF 1.0 • Program – Level Focus • Volume III Was A Desk book • CADM Was Separate • Baseline For DoDAF 1.5 • DoDAF 1.5 • Began to address Net-Centricity • Program – Level Focus • Volume III is CADM & • Architecture Data Strategy • Addressed Architecture • Federation • Baseline for DoDAF 2.0 (Published in 2003) • DoDAF 2.0 • Covers Enterprise • through Program • Architecture Spectrum • Documents High Level • Guidance • Web-based • On-Line Journal • - Best Practices • - Errata Sheets • - Interim Releases • - New Requirements • - Usage Examples (Published in 2007) • Potential Interim • Release Items • Conceptual Data Model • Guidance on Notation • Best Practices • Templates • Capability Description DoDAF 2.0 (To Be Published) (Late 2008) Evolve DoDAF To Support Agile Architecture Environment

7. Resolve DoDAF v1.5 Parking Lot Topics & Comments for DoDAF 2.0 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

8. SE Workshop JCIDS Workshop PPBE Workshop DAS Workshop PfM/CPM Workshop DOTMLPF Workshop DoDAF 2.0 Development Organizational Structure EA Summit CIO Executive Board Core Management Group Development Team DoDAF Plenary Presentation Working Group* Method Working Group* Data Working Group* * Led and Staffed by Component Representatives

9. DoDAF 2.0 CADM 2.0 Journal 2.0 DoDAF v2.0 Planned Approach DAS Process JCIDS Process PfM Process DOTMLPF PPBE Process SE Processes Requirements Workshops Input Comments & Parking Lot Items Plus 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 Policy FEA MODAF TOGAF NAF GAO BPMN SOA Presentation Group Net-Centricity Data-Centricity ASM UPDM CADM Logical Data Model Physical Data Model Data Group 2.0 Concept Map Conceptual Data Model UML Model Class Library

10. CADM 2.0 will: follow the specifications of DoDAF 2.0 and will be the main product of the Data TWG. Also, as indicated in DoDAF 1.5, the CADM is will be an integral part of the framework.CADM 2.0, will take into consideration both what we have now in CADM 1.5 as well as all the other specifications that are emerging e.g., UPDM, IDEAS, ASM. CADM Development

11. Obtain Resolution on Workgroup Leads Develop Outreach Plan for Workshops Identify Participants for Requirements Workshops Develop Schedule for Workshops CMG to Broker SMEs from their Components OSD to Broker SMEs for DoD Level NEXT STEPS

12. Notional DoDAF v2.0 Phased Development Schedule July 2007 Nov 2008 Jan 2008 Jun 2008 Phase I Phase II Phase III Potential Interim Release Items DoDAF Approval Planning is under way both to make interim releases and to shorting up the total development cycle to 12 months Posted to DARS

13. Meeting Lead Schedule Meetings Set Meeting Agendas Conduct Team Meetings Ensure meeting minutes are published Ensure consensus is reached on issues Project Lead Assess Feasibility of Desired Outcomes Develop Project Plan Identify TWG required skills and external SME participation Assign Action Items to Team Members Provide Progress Reports Against Requirements Ensure Task/Action Item Completion Ensure Quality of Content Deliver Content for Inclusion in DoDAF 2.0 Escalate Unresolved Issues to CMG Liaison Liaison with DEV-T Cross TWG Coordination Feedback to Requirements Workshops Proposed TWG Leader Roles and Responsibilities (with DEV-T Support)

14. OSD Brian Wilczynski brian.wilczynski2@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 hilda_pineda@bah.com 703-902-4509 SOO Jeff Coffin jeffrey.coffin@lmco.com 703-916-9415 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 Points of Contact

15. BACKUP SLIDES

16. MAJOR focus will be to collect and incorporate data for architecture to support: Defense Acquisition System JCIDS PPBE SE Portfolio Management (Capability and IT) DOTMLPF Convene a 2 day workshop for each process to collect data requirements that support the processes If 2-day workshop approach proves too resource intensive, the Development Team will use: interviews surveys Workshops will occur in Aug – Sep 2007 timeframe WE NEED: Subject Matter Experts in DAS, PfM, PPBE, SE, DOTMLPF, & JCIDS from your organizations to participate Continual update and feedback back to the requirements workshop participants throughout the development effort Process Workshops

17. General Workshop Skills Understands the senior decision level process Know what decisions are made in the process area Know what data sets are required to make decisions at the senior level Know the questions asked by senior decision makers Know how the data sets are presented for senior decision making Able to represent the process for their organization Familiar with Guidance and Policy in their process area Personal experience working in the process area from different perspectives. Individuals who prepare the input to answer the questions asked to make decisions. For example: Program Management Perspective Certification/Compliance Perspective Programmatic Decision Perspective Portfolio Perspective Analytical Perspective Guidance to Apply to All Workshops OSD Perspective Service Perspective Focus on what needs to be in the Architecture to Support the Process – Not the Process! Set of Questions Focused on Each Workshop Area (TBD) How can architectures be changed to better support your process Workshop Participant Skill Sets (with DEV-T Support)

18. DoDAF 2.0 DevelopmentPhase I: Requirements Identification Phase I Products Enterprise Level Program Level Requirements Set for Each Process at each level Focusing On Data, Method, & Presentation Aspects Architecture & DAS Workshop Architecture & PfM Workshop Architecture & PPBE Workshop Architecture & SE Workshop Architecture & JCIDS Workshop Architecture & DOTMLPF Workshop

19. Guidance BPMN Conceptual Model Data Working Group DoDAF 2.0 Data Content Apply Overarching Rules & Integrate SOA NC IA UPDM Method Working Group DoDAF 2.0 Method Content Apply Overarching Rules & Integrate Other Frameworks UML Presentation Working Group DoDAF 2.0 Presentation Content Apply Overarching Rules & Integrate Security Data-Centric Potential Incremental Work Product Releases DoDAF 2.0 DevelopmentPhase II: Requirements Synthesis Phase I Products Phase II Products

20. Activities Validate and synthesize requirements for commonality. Identify additional requirements based on general guidance. Address requirements fed in by other Groups (Presentation, Method) Create a Conceptual Model Validate Conceptual Model against requirements. Create CADM version 2.0 Synchronize with Presentation and Methods Groups Reconcile Existing Architecture Data Modeling Efforts (Architecture Metadata) Validate products with Requirements Workshops Guidance IA SOA NC BPMN UPDM UML Other Frameworks Data-Centric Security Data ROLE: To develop and update a comprehensive set of Models (Conceptual, Logical, and Physical) and their related definitions for the DoDAF that are methodology and tool agnostic. Requirements Data Working Group Products Models Entities Attributes Definitions Relationships

21. Activities Validate and synthesize requirements supporting specific methods Identify additional requirements based on general guidance. Address requirements fed in by other Groups (Data, Presentation) Document Guidance for Implementing specific Methods (OO & Structured) Validate Conceptual Model support for specific Methods. Synchronize with Data and Presentation Groups Validate products with Requirements Workshops Guidance IA SOA NC BPMN UPDM UML Other Frameworks Data-Centric Security Method ROLE: To document standard methods for the development, maintenance, and use of architecture information and to ensure that the DoDAF models support these methods. Requirements Method Working Group Products • Architecture Lifecycle: • Develop & Approve • Federate • Use • Maintain

22. Activities Validate and synthesize requirements for presentation of data. Identify additional requirements based on general guidance. Address requirements fed in by other Groups (Data, Method) Document Guidance for developing specific presentations (OO & Structured) Validate Conceptual Model support for presentation. Synchronize with Data and Methods Groups Validate products with Requirements Workshops Guidance IA SOA NC BPMN UPDM UML Other Frameworks Data-Centric Security Presentation ROLE: To develop a set of “standard” presentations that can be generated from the architecture data in support of common user requirements and to ensure that the methods and data model support these presentations. To create guidance on building custom presentations. Requirements Presentation Working Group Products Products Views Reports * Standard and custom

23. Phase II Products DoDAF 2.0 Data Content CADM DoDAF Integrate Content & Produce Draft Products Review & Adjudicate DoDAF 2.0 Method Content 2.0 2.0 Journal DoDAF 2.0 Presentation Content 2.0 DoDAF 2.0 Development Phase III: Production Phase III Products Portal

24. From the11 – 12 July DoDAF Workshop: The DoD Architecture Framework is the structure for organizing concepts, principles, assumptions, and terminology into meaningful patterns to satisfy specific DoD purposes. NII Modification: The DoD Architecture Framework is the structure for organizing concepts, principles, assumptions, and terminology about operations and technology into meaningful patterns to satisfy specific DoD purposes. Proposed Definitions for the DoD Architecture Framework • Reference Definitions: • NAF Executive Summary Definition: “An architecture framework is a specification of how to organize and present an enterprise through architecture description.” “…defines a standard set of model categories (called “Views”) which each have a specific purpose.” • TOGAF Definition: • “A tool for assisting in the production of organization-specific architectures. An architecture framework consists of a Technical Reference Model, a method for architecture development and a list of component standards, specifications, products, and their inter-relationships which can be used to build up architectures.” • MODAF Definition for Enterprise Architecture Framework • “A logical structure for classifying, organizing and presenting complex information relating to Enterprise Architectures in a uniform manner.”

25. Alignment – Aligning architecture and system engineering efforts Architecture Compliance Transition – The compliance process for transition architectures from a version of DoDAF to a newer version of DoDAF Architecture Federation – The registration, discovery, use, and linking of architectures across DoD, governance of the architecture federation, and the services to support the federation Audience – Having DoDAF written for the users viewpoint that would benefit from DoDAF Parking Lot and Comment Adjudication Issues from DoDAF 1.5 Development

26. Clarity - Concepts in DoDAF that need to be improved for understanding Conceptual/Logical/Physical Data Alignment - The alignment of concepts in DoDAF to the Logical Data Model (CADM), Data Interoperability between architectures, and the relationship of UML and CADM Coordination – The coordination of other efforts with DoDAF, including CADM WG, Architecture Instruction, JCIDS, JRC, JROC, and Net-Centricity Parking Lot and Comment Adjudication Issues from DoDAF 1.5 Development

27. Definition Synchronization – Determining the definitions of terms in DoDAF, i.e., Operational Node, Organizational Role, Activity (OO & UML) Document Organization – Recommendations for changes in the organization of the DoDAF Volumes DoDAF Update Plan – The plan and cycle to update DoDAF Net-Centricity - How DoDAF will support Net-Centricity, including support for Service Registries, Data Catalogs, and the XML Metadata Registry Parking Lot and Comment Adjudication Issues from DoDAF 1.5 Development

28. New Concepts & Relationships – The addition of new concepts that need to be added (captured) and the relationships between the new concepts and the existing concepts Authoritative Sources, Capability, Evaluation Measure (MOE, MOP), Capability Increments, DOTMPLF, Effect, Human View, External/Internal Nodes, Means and Ways, Metrics, Operational Stage, Scenario, Service Data Exchange, Service Processor, SOA Patterns, System of Systems, Tactical Edge, Taxonomy, Unanticipated Provider, Version, Warfighter Mission Area Physical, informational, cognitive and social domains for NCO/W. This is not NCOW RM Parking Lot and Comment Adjudication Issues from DoDAF 1.5 Development

29. Policy & Procedure Coordination – How does DoDAF help meet requirements from JCIDS, DAS, & PPBE Process Requirement – The requirements that DoDAF needs to support various processes Purpose – Clarify the uses of the architecture for additional audiences Relationship to other Models & Efforts – What are the relationships to the following models, communities, and efforts: FEA, GIG Technical Foundation, IC, ISE, NCOW RM, NIEM, ODNI Parking Lot and Comment Adjudication Issues from DoDAF 1.5 Development

30. Standards – Clarity on standards and the potential impact in developing capabilities. It includes functional and operational standards, beyond the technical standards Templates & Examples – Adding templates and examples to DoDAF for: Activity/Process, BPMN, CADM, IA Information Sharing, IA Attack/Response, IA Protect Data, IDEF0, IDEF1x, IDEF3, Information Element/Attribute/Service Specification Template, Joint Mission Area, Net-Centric, Operational Role, Operational Stage, Service Specification Template, SYSML, UML Parking Lot and Comment Adjudication Issues from DoDAF 1.5 Development

31. Problem Statement Intended Use of Architecture Not Fully Supported Product Based Unable to Align Individual Architectures Architectures are Stove-Piped Developments Value Statement Support Analysis with Data Focused Architecting Collaboration and Reuse Alignment of Enterprise Architectures Architecture to support decision making and PfM Architecture Policy and Federation Objectives Methodology-Independent, Design-Agnostic, Data Centric Policy Directed Architecture and Federation Net-Centric and SOA Decision making and PfM at all Tiers Structured & OO, Multiple Methodologies, and Toolsets Interoperability Core Management Group Statement of Objectives (SOO)

32. Guiding Principles Development Schedule Duration (?) Focus on the Mission Areas Data vice Products Policy Drives and Supports the DoDAF Supports Net-Centricity and SOA Decision Support and PfM Ground Rules DoDAF v1.5 is the Baseline Not Restricted to Existing Products Must Support Multiple Uses Operating Procedures and Structures DoDAF/CADM Steering Group – Scope/Oversight TWGs and Sub-WGs – Based on Skill Sets Membership (DoD and Non-DoD) Voting Rights – DoD Membership Only TBD Outcomes/Metrics/Deliverables Agreement on Statement of Objectives (SOO) cont