DoDAF Meta Model (DM2) Update -- Version 2.01 26 February 2010 DAVE MCDANIEL Contractor, Enterprise Architecture & Standards Office of the DoD Deputy Chief Information Officer +1 (619) 253-9040 davem@silverbulletinc.com 1

Outline of Presentation Recap of DM2 DM2 Configuration Management (CM) Process What’s improved in DM2 2.01 DM2 Adoption and Implementation Status The International Defence Enterprise Architecture Specification (IDEAS) foundation was developed over several years by an international group. It includes a formal ontology using type theory and mereotopology. The U.S. DoD Architecture Framework adopted IDEAS as a foundation for the meta model for the new DoDAF 2.0. The initial reason for adoption was simplification of the modeling via inheritance of foundation “common patterns.” But later, it was found the ontologic tools provided a basis for analysis of issues by the DoDAF 2.0 mete model working group; once the group understood the IDEAS foundation, it provided principled ways for the group to analyze problems. As the DoDAF 2.0 entered service in May 2009, it also started becoming apparent the IDEAS foundation would provide a basis for achieving essential goals of EA, namely, integration of EA models from many heterogeneous sources and analysis of the resultant integrated dataset for EA purposes. The very motivators for EA in the first place, e.g., enterprise interoperability assessment, detection and filling of capabilities gaps, avoidance of unintended capabilities redundancies, system-of-systems engineering, and so on, were seen to depend on just this sort of ability to integrate and cross-walk EA models. This paper describes DoDAF 2.0 meta model development and the different types of benefits of adoption of IDEAS. It also describes some of the challenges with community acceptance and training.

DM2 Recap

The DM2 Has Three Levels DIV-1 DIV-2 DIV-3 Conceptual Data Model (CDM) Logical Data Model (LDM) Reified and Formalized relationships DIV-1 DIV-2 (This is where almost all the design and analysis work is done) DIV-3 (Auto-generated from the LDM) Conceptual Data Model (CDM) Concepts and concept relationships The DM2 has several levels, each of which is important to a particular viewer of Departmental processes. A conceptual level or Conceptual Data Model (CDM) defines concepts and relationships between them business language of the enterprise normative across the six core processes A logical level or Logical Data Model (LDM) formalizes the relationships in the CDM mathematically A physical level or Physical Exchange Specification (PES) adds required NCDS metadata for security and pedigree to the LDM is generated from the LDM as a set of XSD’s, one schema per DoDAF-described Model Physical Exchange Schema (PES) XML encoding of LDM

(see “DM2 CDM Description document” for definitions) CDM (DIV-1) Graphic 23 (+ 24 &25) 20 (+ 21 & 22) 30 1 2 3 4 5 7 6 8 9 18 10 11 13 15 12 16 17 20 19 22 14 21 24 23 25 26 27 28 29 31 32 33 34 36 35 37 Green lines are super-subtype. Read in direction of arrow, “is a type of” Blue lines are associations. See notes for key descriptions and examples. Read key in direction of arrow. Crows feet are associations between the association at the foot and the arrow, read according to the key. Person Type (see “DM2 CDM Description document” for definitions)

LDM (DIV-2) Sample Graphic

Physical Exchange Schema (PES) (a form of DIV-3) Sample

Where is the DM2 DoD Meta Data Registry (MDR)1 DoDAF Web Site DM2 Collaboration Site2 . working copy of the DM2 is maintained on a TWG collaboration site, along with all reference and research materials and the current action item tracker. ARCH namespace. ARCH namespace has CDM (eap and xmi), LDM (eap, xmi, and xls), and PES (xsd’s). Can be accessed via DoD EA COI. http://metadata.dod.mil/ http://www.silverbulletinc.com/dm2

The DM2 is under Configuration Management (CM) by the DM2 WG DM2 WG has three responsibilities1: Configuration Management (CM) of the DM2 Data management for the DoD EA COI Review of architectural descriptions for suitability for federated data exchange The DM2 WG meets every Friday and has over 180 members 1. ASRG Management Plan

DM2 Configuration Management FAC DM2 CRs COI Guidance Architectural Description Review Tasks DM2 Baseline Release Direction DM2 CSAR COI Metrics and Progress Report Architectural Description Reviews DM2 Baseline Release Request and Status DM2 WG Govt Military Industry Academia vendors DoDAF WG DARS WG Referred CRs Referred CRs COI Coordination Groups DoD MDR WG DoD COI Forum Vendors EA/ITA Tool M&S Data Analysis Repository Data Integration Data Exchange Pilots Early Adopters Federation Framework & Ontology Groups OMG / INCOSE / NDIA IDEAS / NAF UCORE Enterprise Vocabularies Core Process Stakeholders CJCSI revs AT&L SoSE & Acq Reform Combatant Command architectures CPM Governance PA&E

Outreach and Tutorial DM2 Description Documents and Briefings

What’s improved in 2.01 Many minor model updates Stereotypes, definitions, cardinalities, etc. Desired Effect structure Design reification and requirements traceability International Defence Enterprise Architecture Specification (IDEAS) alignment We were developing the IDEAS Foundation, version 1.0, and DM2 in parallel and so there were a few disconnects. XML Schema Description (XSD) Format Only 1 XSD to implement, instead of 52! (two others with foundation metadata and one with IC-ISM) Beginning absorption of latest OASIS & Object Management Group (OMG) SoA concepts

Desired Effect structure

Levels of Abstraction – (reifications) and Requirements Traceability describes describes describes Thing describes describes Pedigree (requirements) Pedigree (requirements) Pedigree (requirements) Pedigree (requirements) Architectural Description Pedigree (requirements) Architectural Description Architectural Description Architectural Description Architectural Description Rules A&D Successive refinement of the Architectural description. For any phase, it is traceable to the prior (pedigree). The prior phase becomes the rules that constrain the activities of the next performer – adherence to requirements baseline. They’re all aiming at the same future Thing, just describing it in more detail and in different ways as you go along. Rules Rules constrain Rules constrain Rules constrain constrain constrain Worker Technician Engineer Architect Executive Strategic Op Rqmt TLR SLR A-Spec/SSS B-Spec/SSDS C-Specs/SRS JCD time IOC Got this one for free!

IDEAS Recap - Top-Level Foundation Developed by an international group of computer scientists, engineers, mathematicians, and philosophers under defense sponsorship. See http://www.ideasgroup.org or http://en.wikipedia.org/wiki/IDEAS_Group Then domain concepts inherit several important properties. None of these foundation properties are unusual; they are all used in reasoning everyday: Individuals, things that exist in 3D space and time, i.e., have spatial-temporal extent. Types, sets of things. Tuples, ordered relations between things, e.g., ordered pairs in 2D analytic geometry, rows in relational database tables, and subject-verb-object triples in Resource Description Framework. Whole-part; e.g., components of a service or system, parts of the data, materiel parts, subdivisions of an activity, and elements of a measure. Temporal whole-part; e.g., the states or phases of a performer, the increments of a capability or projects, the sequence of a process (activity). Super-subtype; e.g., a type of system or service, capability, materiel, organization, or condition. Interface; e.g., an overlap between two things. [1] http://www.ideasgroup.org Three types of Things: Types (which are like sets), Tuples (ordered relationships), and Individuals (not persons, but Things that have spatial and temporal extent – spatio-temporal extent.) mereology is a collection of axiomatic first-order theories dealing with parts and their respective wholes. In contrast to set theory, which takes the set–member relationship as fundamental, the core notion of mereology is the part–whole relationship. Mereology is both an application of predicate logic and a branch of formal ontology.

XSD format

XSD format

XSD format

Beginning absorption of latest OASIS & OMG SoA concepts From OASIS SoA RAF

Relationship Between Action and Service Description

Service Descriptions So a Service Description can have all the structure of an Architectural Description Activities Before-After Rules Conditions Data structures Locations Dependencies Etc.

DoDAF 2 Exemplars What are they How are we doing them Collections of architectural views and their corresponding DM2 PES XML document examples From coherent datasets, e.g., UPDM S&R, NCES ISP How are we doing them DoDAF Journal DoDAF Outreach Brief - Views Discuss Candidate Datasets with Process Owners Conform Diagram to DoDAF 2 and Add Legends DoDAF Outreach Brief – DM2 Developers / Analyst / Integrator DM2 Description Document – PES DoD MDR DM2 Collaboration Site Add Additional Markups for DM2 Enter Into DM2 Database DM2 DB Review With DM2 WG DM2 PES XML Document

Adoption and Implementation Status

Tool Vendors Unified Profile for MODAF and DoDAF (UPDM)1 (see next slide) Joint working sessions: DM2 participation in OMG Technical Meeting UPDM sesssions UPDM Team participation in DM2 WG Ongoing Plan: Map UPDM Domain Meta Model (DMM) to/from DM2 Use to develop DM2 PES generator / exporter Test and validate DM2 PES XML documents so generated Other vendors2 DoDAF Team briefings and DM2 PES conformance DM2 meetings Comment and question submissions Tool vendor members: Adaptive (Adaptive Metadata Manager, Adaptive IT Portfolio Manager, Artisan (Artisan Studio), ASMG (mdPortal, mdParser, mdBrowser), Embedded Plus Engineering UPDM Toolkit (for IBM RSDP), IBM (Telelogic SA, Rhapsody, RSA), No Magic (MagicDraw), Sparx Systems (Enterprise Architect), MetaStorm (ProVision), IBM (RSA, System Architect, Rhapsody), Artisan (Artisan Studio), MicroFocus (Borland Together), ViTech (CORE), METRON (Naval Simulation System), Siemens (TeamCenter), Enterprise Elements, Salamander (MooD), Sybase (PowerDesigner), QualiWare (QualiWare Enterprise Architecture), IDS Sheer (ARIS), alfabet (planningIT), MicroFocus (Borland Together), Casewise (Corporate Modeler), Mega (Mega Suite), Troux (Troux Architect). (Other interested vendors please contact Mike Wayson, Michael.Wayson@osd.mil.)

DoDAF 2 Conformance: DM2 PES is the Neutral Standard Interoperability Layers XMI / MOF Conversant (e.g., UPDM / SysML) Analysis Software DM2 PES XSD neutral implementation EA / ITA Tools Authoritative Data Sources EA Domain Concepts Common Patterns 4D Mereology Set Theory Naming Pedigree M&S Tools EA DBMS’ Ontic Foundation Reporting Tools and Formats Federal, Coalition, and other EA exchanges

DM2 / DoDAF Testing Levels

Review for DoDAF 2 Conformance Review for DM2 Conformance DM2 / DoDAF Testbed Plan DoDAF 2 Exemplars: View Diagrams View DM2 PES Datasets DoDAF View Diagram Publisher Review for DoDAF 2 Conformance DoDAF 2 View Diagrams and Descriptions Tool DB (or data structure) DoDAF WG DM2 PES XML Generator / Exporter DM2 PES XML Document Develop views in tool Data Browsers DM2 WG DM2 DB Review for DM2 Conformance DM2 PES XML Document Validator

Implementation JFCOM Joint Integrated Architectures Working Group (JIAWG) Federation Sub Working Group (SWG) Enhanced ISP (EISP) Naval Architecture Repository System (NARS) / Naval Architecture Elements Reference Guide (NAERG) DM2 Database used for exemplar generation Universal Core (UCORE)1 Coordination EA data exchange between DoD – IC – DHS – DoJ Formal ontology 1. www.ucore.gov

Questions