Do DAF-DM 2 WG Orientation Brief 13 April

Do. DAF-DM 2 WG Orientation Brief 13 April 2011 Do. DAF Development Team

Agenda • • • Do. DAF-DM 2 WG history Do. DAF-DM 2 WG Objectives Current Do. DAF-DM 2 WG Participants Do. DAF-DM 2 WG Challenges Do. DAF-DM 2 WG Way Ahead 2

Lay of Do. DAF Land 1. Model (view) specifications The 52 Do. DAF models and the DM 2 are related via a matrix* • • Operational Capabilities Services Systems Data and Information Standards Projects 2. DM 2 – Conceptual Data Model – very simple – Logical Data Model • Because of IDEAS there are only ~250 total data elements compared to the lessexpressive CADM that had ~16, 000! – Physical Exchange Specification is * 52 Do. DAF models X 250 DM 2 data elements, referred to as the “monster matrix” because it has ~ 13, 000 decision cells • Automatically generated from the LDM (an IDEAS plug-in, already paid-for) • Slightly-dumbed-down LDM in XML so if you know the LDM, PES is simple • PES tags and definitions are identical to DM 2 LDM • No new structures are introduced other than XML-isms 3

Conceptual Level of DM 2 is Simple Condition Guidance is-performable-under Rule Standard constrains Agreement requiresability-toperform Activity has Project Not shown but implied by the IDEAS Foundation: • Everything is 4 -D and so has temporal parts, i. e. , states • Everything has parts • Everything has subtypes is-performed -by is-thegoal-of consumesandproduces Resource Materiel Performer System is-realizedby Backup slide has term definitions achieves-desiredeffect (a state of a resource) Information describessomething Data Organization Service Capability Person. Role is-at Location Geo. Political is-part-of anything can have Measures 9

Do. DAF 2 Conceptual Data Model Terms • • Activity: Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state. Resource: Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed. – – Materiel: Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes. Information: The state of a something of interest that is materialized -- in any medium or form -- and communicated or received. • – Performer: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability. • • • Organization: A specific real-world assemblage of people and other resources organized for an on-going purpose. System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements. Person Role: A category of persons defined by the role or roles they share that are relevant to an architecture. Service: A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The capabilities accessed are Resources -- Information, Data, Materiel, Performers, and Geo-political Extents. Capability: The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities. Condition: The state of an environment or situation in which a Performer performs. Desired Effect: A desired state of a Resource. Measure: The magnitude of some attribute of an individual. Location: A point or extent in space that may be referred to physically or logically. Guidance: An authoritative statement intended to lead or steer the execution of actions. – Rule: A principle or condition that governs behavior; a prescribed guide for conduct or action. • • Data: Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields. Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in. Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel. Project: A temporary endeavor undertaken to create Resources or Desired Effects. Geopolitical Extent A geospatial extent whose boundaries are by declaration or agreement by political parties. 10

PES Structure Planned for future interoperability with IDEAS Packaging, e. g. , overall classification marking Extra goodies for Dublin Core (optional) Screen-scrape of the actual PES XSD Architecture data – tag names and definitions are exactly from DM 2 LDM • Where you say what views the data corresponds to – – XML stuff -- unimportant – This could be made optional One PES file can have multiple views A single piece of data can be in multiple views A recipient of the XML file should validated it against PES XSD which automatically encodes the “monster matrix”. 11

Do. DAF-DM 2 WG history • Do. DAF 2. 0 development in 2008 -2009 was done via 3 technical working groups: 1. Presentation 2. Methods 3. Data • Data TWG methodology during Do. DAF 2. 0 development – – – • Top-down from Do. D’s six core processes and their information requirements collected as part of the requirements workshops Bottoms-up from ~ two dozen existing data models Business rules enabled great success – DM 2 has only ~ 250 pieces compared to predecessor CADM’s ~ 16, 000 Do. DAF 2. 0 publication in May 2009 – Only Data TWG established a significant membership and meeting tempo and so it was a resource of opportunity to assume Do. DAF configuration management recommendations 12

Top-Down / Bottom-Up Development Do. D Core Process Information Requirements Collection UCORE COI 1 COI Coordination JCIDS Process Information Requirements Ops Planning Process Information Requirements SE Process Information Requirements PPBE Process Information Requirements DAS Process Information Requirements CPM Process Information Requirements Do. DAF 2. 0: § Conceptual Data Model (Vol I) Data Model Development COIn Existing / Emerging Schema, Models, and Databases § Logical Data Model (Vol II) § Physical Exchange Model (Vol III) 13

Conceptual Data Model Process 1. Overviews of Models 3. Make a pass on the “Core” Terms 2. Collect the terms 1 = Core, critical to process or very common in architectures 2 = Derived or less common 3 = TBD 4 = TBD 5 4 3 2 1 5. Group related terms 4. Gather authoritative definitions for “Core” terms 6. Proposed definitions (+rationale, examples, and aliases) 12/3 Strawman – list of important or recurring “core” words/terms/concepts with source definition(s) 7. Relationships 8. Relationship Types 1/3 Partial Draft – 2/3 Interim Draft – Initial 3/3 CDM version 0. 1 proposed definitions, some harmonization (e. g. , via super/subtyping, determining aliases) relationships (e. g. , "performs", "part-of", . . . ) 1. Concepts (defined) 2. Relationships (some typing, e. g. , super/sub, cardinality) 14

Sources a. b. c. d. e. f. g. h. i. j. k. l. m. n. o. p. q. r. s. Models CADM 1. 5 IDEAS UPDM BMM Hay/Zachman ASM CRIS Conceptual CADM in Do. DAF 1. 0 / prototype CADM 2. 0 M 3 NAF Meta Model Do. I Meta Model JC 3 IEDM GML UCORE 1. 1 GEIA 927 AP 233 SUMO and ISO 15926 (via IDEAS) FEA Reference Models JFCOM JACAE 1. 2. 3. 4. 5. 6. 7. 8. Definitions IEEE ISO W 3 C OMG EIA DODD & DODI JCS Pubs, especially CJCSI's Models in the Source_Candidates_071115. ppt 9. Do. DAF 10. Other frameworks: Zachman, MODAF, TOGAF, NAF, . . . 11. FEA 12. BMM 13. Worknet 14. Wikipedia 15. English dictionaries 16. Do. DAF Glossary 15

Definition Phase Example 1 Category Capability Technical Term Capability Proposed Definition Potentially Related Terms or Aliases Source/Current Definition (source) definition Capability: (n) 1. The ability to execute a specified course of action. (JP 1 -02) 2. The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks. (JCIDS): The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks. (Do. DAF/CADM): An ability to achieve an objective. (DDDS Counter (333/1)(A)) (JC 3 IEDM): The potential ability to do work, perform a function or mission, achieve an objective, or provide a service. (NAF): The ability of one or more resources to deliver a specified type of effect or a specified course of action. (GEN TERM) (NAF): A high level specification of the enterprise's ability. (MM) (JCS 1 -02): The ability to execute a specified course of action. (A capability may or may not be accompanied by an intention. ) (Webster's): 1. The quality of being capable; ability. 2. A talent or ability that has potential for development or use. 3. The capacity to be used, treated, or developed for a specific purpose. Examples "The soldier shall be able to load and fire his individual weapon. " (JP 1 -02) "The soldier shall be able to load and fire his individual weapon from (positions) on a trainfire range, in (weather) to achieve a minimum score of "Marksman" on the Army Marksm Definition Rationale Authority: "The Secretary of Defense, by DOD Directive 5025. 12, 23 August 1989, Standardization of Military and Associated Terminology, has directed the use of JP 1 -02 throughout the Department of Defense to ensure standardization of military and associated terminology. 16

WG Business Rules Essential for Broad Community Consensus 17

Do. DAF Must Relate to Core Processes DRAFT 18

Do. DAF Must Relate to Core Processes DRAFT 19

Do. DAF Must Relate to Core Processes DRAFT 20

Do. DAF Must Relate to Core Processes DRAFT 21

Do. DAF Must Relate to Core Processes DRAFT 22

Do. DAF Must Relate to Core Processes DRAFT 23

Do. DAF Must Relate to Core Processes DRAFT 24

Do. DAF Must Relate to Core Processes DRAFT 25

Do. DAF-DM 2 WG Objectives 26

Do. DAF-DM 2 is under formal configuration control • Architecture Standards Review Group CONOPS – Roles, Responsibilities, and Processes – ASRG -- FOGO / SES level – Federated Architecture Council – 06 level – Configuration Identification – Organizational Roles, Responsibilities, and Interactions – CM Processes and Procedures – CM Business Rules IN FA RE C VI DI SI RE ON CT P IO ER N • Do. DAF and DM 2 CM Plan 27

DISA Marine Corps Army Do. N AF NSA FAC is Small Formal Voting Body WG is Large & Collaborative Framework Groups • OMG / INCOSE / NDIA • MODAF / NAF / TOGAF • FEA / FSAM Core Process Stakeholders • CJCSI revs • AT&L So. SE & Acq Reform • Combatant Command architectures • CPM Governance • PA&E DNI CIO AT&L P&R USD(I) DCMO JCS J 6 STRATCOM CR Technical Redirectoin • CR Prioritization Redirectoin • JFCOM FAC – Voting – 23* votes * Some C/S/A have multiple members Do. D CIO • Do. DAF-DM 2 Configuration Status Accounting Report (CSAR) • Do. DAF-DM 2 Baseline Status • Do. DAF-DM 2 WG Activity Summaries • COI Metrics and Progress Report Framework & Ontology Groups • OMG / INCOSE / NDIA • IDEAS / NAF • UCORE • Enterprise Vocabularies Do. DAF-DM WG – Collaborative – Agreed-upon business rules enable analysis of different opinions Vendors • EA/ITA Tool • M&S • Data Analysis • Repository Data Exchange • Pilots • Early Adopters • Federation • Data Integration To join, go to Do. DAF 2. 0 website COI Coordination Groups • 400+ members + ~12 new each week • Meets biweekly • Do. D MDR WG • Do. D COI Forum 28

Bi-weekly WG Meetings • • • Collaboration site Readaheads and notebooks References folders Discussion groups CR Submission Tools 29

Monthly Report to FAC • Purposes: – Full visibility of WG activities and plans – Opportunity for FAC re-direction • Technical • Prioritization • Action Item / Change Request Status • Configuration Status Accounting Report – Summary of WG activities – Change Request Summary – Detailed status of all open Change Requests 30

Do. DAF-DM 2 WG Change Request Processing DRAFT 31

Do. DAF CR Detailed Processing DRAFT 32

DM 2 CR Detailed Processing DRAFT 33

Do. DAF-DM 2 Version Process DRAFT 34

Current Do. DAF-DM 2 WG Participants • Over 450 members – Military, Government, Industry, Vendors, Academia, and professional organizations – Operators, architects, tool developers, repository operators, and data analysts – All FAC Components represented + IC • Monthly participants and full member list reported to FAC in monthly CSAR • Imminent tasker to Components to identify their WG representative(s) – Multiple reps will be OK, e. g. , Navy could choose SPAWAR, NAVSEA, NAVAIR, OPNAV, and ASN RDA 35

Do. DAF-DM 2 WG Challenges 1. WG growth – from a dozen members to over 400, adding ~ 12 / week – A new member orientation package to be automatically sent upon registration is being developed 2. Separating material that needs to be controlled from that doesn’t – E. g. , “History of the Do. DAF” probably does not warrant formal review by Components and control by the FAC – Conversely, the viewpoints/views and DM 2 do 3. Cleanup of legacy text and focus of viewpoints/views towards six core processes – Wordsmithing is insufficient to resolve – Tools that will help: FEAF, Core Process information analyses, and DM 2 disambiguation power 36

Do. DAF-DM 2 WG Way Ahead 1. ASRG & FAC Governance to be updated 2. FAC Component reps formal tasker soon to be issued 3. Version tempo to slow to annual or semi-annual 4. Versions will go through review by Components by formal tasker 5. Predicted future CR sources: – Coordination with FEAF, JARM, and CUDEAF – Core process initiatives, e. g. , IT Acquisition Reform 37

Do. D Architectures COI WG is being considered DRAFT • Would cover, perhaps on a rotating basis: – Architecture information sharing needs – Architecture standards (i. e. , Do. DAF, DM 2, others) – Architecture tools (i. e. , current vendor list, DARS, others) – Architecture relevance in core processes and governance – Architecture federation – Architecture best practices DRAFT 38

Welcome! We look forward to your participation. 39