Contractor, Enterprise Architecture & Standards Implementation of the International Defence Enterprise Architecture Specification (IDEAS) Foundation in DoD Architecture Framework 2.0 9 MARCH 2010 DAVE MCDANIEL Contractor, Enterprise Architecture & Standards Office of the DoD Deputy Chief Information Officer +1 (619) 253-9040 davem@silverbulletinc.com 2

Outline of Presentation IDEAS Recap Why we used IDEAS – benefits Re-use of common patterns saved a lot of work Reconciliation and analysis tool Information pedigree model Design reification and requirements traceability Services description Semantic precision Mathematical precision How we implemented IDEAS Implementation challenges 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.

IDEAS Recap

Top-Level Foundation Four dimensionalist -- xyzt Extensional -- physical existence is the criterion for identity Signs and representations are separated from referents Mathematics: Type theory ~ Set theory Mereology (wholes and parts) 4D Mereotopology (spatio-temporal relations) 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. http://www.ideasgroup.org or http://en.wikipedia.org/wiki/IDEAS_Group

Type Theory Math Examples Flip over – not time to brief

Mereotopologic Math Examples Overlaps, spatial relationships (mereotopology) Behaviors -- Sequences, before-after (4D mereotopology) Flip over – not time to brief

Some Math Sources National Center for Ontologic Research (NCOR), http://ontology.buffalo.edu/smith/ Direct Model-Theoretic Semantics for OWL 2, http://www.w3.org/TR/2009/REC-owl2-direct-semantics-20091027/ Vocabulary Interpretations Object Property Expressions Data Ranges Class Expressions Satisfaction in an Interpretation Class Expression Axioms Object Property Expression Axioms Data Property Expression Axioms Datatype Definitions Keys Assertions Ontologies Models

Benefits of IDEAS for DoDAF 2

1. Rigorously worked-out common patterns are reused Saved a lot of repetitive work – “ontologic free lunch” Concentration of rigor on common patterns results in higher quality and consistency throughout Model compactness -- DM2 is tiny compared to its predecessor by two orders of magnitude! Easier to learn -- a few hard concepts are easier to learn than thousands of conceptually intractable ones. Implementations get reuse too – same code, queries, … work for many datasets Super/Sub Type, e.g., F-15 is type of Fighter Whole Part, e.g., AEGIS radar is part-of the AEGIS ship Overlaps, particularly Interface Type, e.g., Asset data collection activities produce data for audit reporting Before-After, e.g., The collection task takes place before the posting and exploitation tasks

2. Reconciliation and analysis tool (slide 1 of 4) State of practice in data modeling: Noun and adjective analysis Similar to natural language written in a diagram Often laden with entrenched but obsolete technology considerations The fundamental concepts of Entity-Relationship and Class Models: predicate subject object Implicit, built-in, language features: predicate “has” (for attributes) Plural, singular notions (cardinality) Sufficiency and completeness notions (e.g., no-nulls) Make a table / class / attribute / field / enumeration / etc. for every noun encountered Really a structured document Joins and associations allow for flexible sub-documents Good for storing and retrieving information Lousy for automated computation upon Set theory – categories of things Meronymy – spatial relationships between things Tuples – ordered relationships between things Logic – deductive, monotonic, non-monotonic, … Inference – probabilistic, evidential, … Lexical semantics, mathematical linguistics, … Like all complex systems, made up of many pieces The pieces interact through data Originally, piece makers (engineers, programmers) worked pair-wise (e.g., at design meetings, telephone, test sites) to figure out the interaction – involved much human interaction With network “bus” architectures, easier to make interaction possible because the data is available But understandable only by much human interaction1 The number of pieces continues to grow2 The number that need to interact continues to grow3 The scope of data they would like to use continues to grow4 XML provides documentation with the data, but humans still have to read and understand it. e.g., Smart Ship, Integrated Bridge System, BMD Continuing C4I – Combat System integration, Joint systems, OA and CANES SoA componentization e.g., reference data such as ECDIS-N charts and GCCS-I3 use in Combat System

One Result of this practice -- data model “wars” C2 Core UCORE model MIEM Anti-Submarine Warfare (ASW) COI Blue Force Tracking (BFT) C2 Interoperability Group CBRN Coalition C2 Interoperabilty (Coal C2) Common Sensor GEOINT Standards COI (GWG COI) Global Force Management (GFM) GPS Based Positioning Navigation Timing Service Integrated Fires Joint Air and Missile Defense Joint Air Track (JAT) Joint Electronic Warfare Data Standardization Joint Targeting Intelligence (JTI) Maritime Domain Awareness Meteorology-Oceanography (METOC) Mine Warfare Symbology (SYM) Undersea Warfare XML (usw-xml) CNDE model Users of these different models believe their model is the best for many purposes, in many cases overlapping purposes. NIEM GML Sensor ML Transducer ML a smattering – see notes for short descriptions JC3IEDM (STANAG 5525) C2 Core – Command and Control Core – in development at JFCOM (again) UCORE – Universal Core -- https://ucore.gov/node/23 -- a simplified “digest” of structured data with metadata and a COI-specific “structured payload” for information exchange across DoJ, DHS, IC, and DoD MIEM – Maritime Information Exchange Model – relevant to MDA-related missions CNDE – Consolidated Net-centric Data Environment -- https://nesi.spawar.navy.mil/projects/jtm/ -- formerly the JTM data model and currently the model for CANES NIEM – National Information Exchange Model -- http://www.niem.gov – relevant to MDA-related missions GML -- Geography Markup Language -- http://www.opengeospatial.org/standards/gml Adopted by NGA as their standard for geospatial and imagery data dissemination. Sensor ML – Sensor Markup Language – Transducer ML – Transducer Markup Language -- JC3IEDM -- Joint Command, Control, and Consultation Information Exchange Model -- http://www.mip-site.org/ -- NATO standard for coalition C2 information exchange VMF – Variable Message Format – TADIL-J – Tactical Action Data and Information Link -- CoT – Cursor On Target -- http://cot.mitre.org/bin/view/CoT/ -- implemented by many smaller systems A “Common” Data Model Has Not Worked Mandating “common” is problematic: Ignored, e.g., DoD Data Admin policy and “Corporate Information Management” -- rescinded in favor of current “market-driven” strategy; SECNAVINST 5000.36, Or complied with at great cost in terms of $’s, rqmts-to-deploy time, and interoperability One size rarely fits all, e.g., normalization is good for transactions, bad for mining A rational basis for model determination seems better COI Name Mission Anti-Submarine Warfare (ASW) COI to implement ASW Data Strategies and Open Architecture principles in support of DoD and Navy goals. The ASW COI has data responsibilities related to the Battlespace Awareness, Command & Control, Force Application and Force Protection Domains within the Warfighter Mission Area (WMA). COIs with associated interests include MASINT, METOC, Mine Warfare and Maritime Domain Awareness. Data sharing and interoperability with US Coast Guard and coalition forces are key components of effective ASW warfighting. Blue Force Tracking (BFT) Develop and provide a BFT Information Exchange Standard that facilitates BFT across Joint and Allied/Coalition forces to effectively ensure that data is visible, accessible, trusted, understandable and in accordance with the DoD Net-Centric Data Strategy and Directive 8320.2. C2 Interoperability Group The mission of the Command and Control Interoperability Group (CIG) is to manage the US-JC3IEDM standard. The CIG will capture US requirements, and develop and maintain US extensions, a set of specifications, a common implementation, and other products in support of the US-JC3IEDM. In addition the CIG will interface with other C2 interoperability groups to identify common technical issues and develop common solutions, when possible. The CIG will assist in coordinating the interoperability of US C2ISR at the strategic, operational and tactical levels. CBRN Coalition C2 Interoperabilty (Coal C2) The aim of the Coalition C2 is to achieve international interoperability of Command and Control Information Systems (C2IS) at all levels from corps to the lowest appropriate level, in order to support multinational, combined and joint operations and the advancement of digitisation in the international arena, including NATO. The Army wants to comprehenvisely manage the development and growth of Coaliton C2 Interoperability efforts. Common Sensor To serve as the focal point for Common Sensor PED Development; National Signatures Program; Common Sensor PED Customer Outreach; Common Sensor Metadata, Product Standards, and Portal; Common Sensor policy; Common Sensor related issues pertaining to Electro-Optical, Radar, CBRNE, Radio-Frequency, Seismic, Acoustic, Magnetic, Infrasonic, Laser, SAR, Spectral, Thermal, Biometrics; Common Sensor Testing & Evaluation GEOINT Standards COI (GWG COI) The GWG supports the ITSC in the configuration management of GEOINT standards within the DISR. Additionally, the GWG provides a standards-focused forum that the NSG community can use as a means to exchange and communicate issues regarding GEOINT standards requirements, development, implementation, and conformance. The GWG recommends GEOINT standards for data, systems, and their interfaces to ensure interoperability with DoD and non-DoD systems. The GWG serves as a community-based forum to advocate for Information Technology (IT) standardization activities related to GEOINT. In this capacity, the GWG supports the Director of the National Geospatial-Intelligence Agency (NGA) in carrying out GEOINT functional manager responsibilities for standards. The GWG performs two major roles: 1) as a technical working group (TWG) of the ITSC, with all the responsibilities of an ITSC member and, 2) as a coordinating body for the GEOINT community to address all aspects of GEOINT standards. Through the GWG, community consensu Global Force Management (GFM) GFM is a process that enables insight into global availability of US forces, and provides a means to assess risks associated with proposed allocation, assignment and apportionment. GFM data will be transparent, universal and accessible on demand in a net centric environment.Global Force Management requires the implementation of a common force structure, for which there are three key elements. 1. A joint hierarchical way to organize force structure data for integration across Service-lines, known as the Force Structure Construct (FSC). 2. Force structure data that is rigorously specified via a GFM Information Exchange Data Model and its semantics unambiguously defined so that sophisticated computer programs can economically exploit it via the net-centric data strategy. 3. A common naming convention and data tagging technology, known as Enterprise Wide Identifiers (EWIDs), that must be accepted and used across DoD (including adoption by future Joint systems such as DRRS, DIMHRS, and Blue Force Tracker), with th GPS Based Positioning Navigation Timing Service - GPNTS To provide Positioning, Navigation and Timing (PNT) solutions to afloat combat systems. Integrated Fires Fires Knowledge Network (FKN) is for all Fire Support and Field Artillerymen no matter where their mission may take them. This site is dedicated to linking the operational forces to the Field Artillery Center and to each other while providing a One-Stop Shop for all Fire Support and Field Artillery professional knowledge. Joint Air and Missile Defense Develop a common vocabulary, based on required capabilities and associated functions, for defining Joint AMD-specific data that must be shared among Joint, Interagency and Multinational (JIM) AMD platforms in the execution of the AMD mission, as well as the data required to support future AMD capabilities. Provide a resource to the Air Defense and Missile Defense Namespace Managers to ensure that AMD-specific metadata stored in those Namespace repositories are consistent with the common AMD vocabulary and harmonized with associated metadata from within their respective Namespaces as well as other associated COI's supporting Namespaces within the DoD Registry. Enable the discovery, posting, and subscription to Air and Missile Defense-specific data by all organizations associated with the DoD in accordance with the DoD Network Centric Data Strategy. Joint Air Track (JAT) Develop the collaborative environment of users, data sources, and services that supports exposure of air track data. Joint Electronic Warfare Data Standardization To establish a collaborative effort to ensure mutual concurrence in the review, standardization, and formal registration of Joint Electronic Warfare data elements with the Defense Information Syatems Agency (DISA). Joint Targeting Intelligence (JTI) Joint targeting intelligence to support deliberate planning and ultimately execution. COI Products: Targeting tables in MIDB, Joint Targeting Database (JTDB), Joint Target Materials Program, Joint Targeting Toolbox (JTT), Military Targeting Committee (MTC), Joint Targeting Automation Steering Group (JTASG), Targeting Issues Working Group (TIWG), Combat Assessment Working Group (CAWG), DIAI 57-24, Schema sets for target folders, target lists etc. Maritime Domain Awareness MDA COI is a new initiative to standardize data for Maritime Domain Awareness. It is composed of a steering committee and four working groups. Tasks for the COI working groups are to: define/implement high level COI Capability Roadmap; synchronize COI products with JCIDS and Mission Areas; develop shared vocabulary in accordance with DoD Net-Centric Data Strategy; develop repeatable processes; and to facilitate service implementation. Meteorology-Oceanography (METOC) Improve the interoperability, standardization and usage of METOC data, products and value-added net-centric services for the Joint Warfighter. * Provide a dynamic, authoritative, collaborative forum for establishment of DoD standards associated with Joint METOC information and services. * Improve joint usage and availability of meteorological, oceanographic (METOC) and space environmental architectures. * Define standards for METOC data, algorithms & model applications, and associated METOC interfaces to the GIG. * Manage the METOC XML Namespace within the MDR and de-conflict XML components across the other community namespaces. * Identify and develop METOC COI-specific services that embody CES tenants. * Provide one authoritative venue for the standardization of Joint METOC data, products and services. COI Product: The Joint METOC Conceptual Data Model(JMCDM) is the foundation for METOC information, implemented through the JMBL interface (Joint METOC Broker Language) as the single, web-enabled request and re Mine Warfare provide a location for creation and sharing of data to be used in the Mine Warfare arena Symbology (SYM) To develop and maintain Joint Warfighting Symbology MIL-STD-2525, for interoperability among C2 systems. Undersea Warfare XML (usw-xml) Create\assemble a common XML vocabulary to facilitate the establishment of coherent battlespace visualization capabilities for network-centric undersea warfare. VMF (MS 6017) TADIL-J (MS 6016) Cursor On Target Like diverse languages, there is a high cost to learn

Some real-world and costly results of this practice Cost and project risk Developers and integrators must learn multiple proprietary “languages” Need to build many translators Over promised ability of “translation hubs” Context, interdependent, and value-dependent translations Operational impact E.g., from “lossy” translations, mis-translations, … Difficulty in transitioning new technologies, e.g., automated processing tools Prohibits or impedes scaling and cross-domain integration and data sharing Impedes Net-Centricity / OA / SoA due to need for much human interaction, e.g., no automated unanticipated users The costs and risks – both project and operational -- are usually underestimated

Reconciling Using IDEAS Analysis Technique: BORO1 Agreed-upon principles that provide a principled basis for issue analysis Example decision process time Example BORO analysis diagram Dave Copy and Send Ian Copy DD, copy 1 Flow process Send part Dave’s Document, Original Receive part Dave’s Document, Copy 1, in flow state 1. Business Objects Reference Ontology, http://www.boroprogram.org/ or http://en.wikipedia.org/wiki/BORO_Method DD, copy 1

3. Information Pedigree Model Workflow model, e.g., Open Provenance Model (provenance = linked together pedigrees) = Activity model (OV-5 + 6c)  got nearly for free! D Requirement in the DoD Net-Centric Data Strategy (NCDS) Similar to Open Provenance Model Describes the workflow that led to the production of the information Pedigree is the immediate link – provenance further back in the production chain Activities, Performers, Performer states, resources used, rules abided by, measures conformed to Got this one nearly for free!

4. Design Reification 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 Rules Rules constrain 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 constrain Rules constrain constrain constrain Worker Technician Engineer Architect Executive Strategic Op Rqmt TLR SLR A-Spec B-Spec C-Specs JCD time IOC Got this one for free too!

5. Service Descriptions (1 of 2) From OASIS SoA RAF, Figure 27, “Service Description”

Service Descriptions as Modeled in DM2 This means a Service Description can have all the structure of an Architectural Description, e.g., Activities Before-After Rules Conditions Data structures Locations Dependencies Etc. Got this one for free too!

6. Semantic Precision for Heterogeneous Data Integration Human-interpretable only A spectrum of information sharing Human-interpretable but with a predictable organized arrangement More structure than structured text Named records (or tables or classes) that are some sort of container for named fields (or attributes or columns).  Associations and relationships, containers can point to information in other containers Because of the labeling, you can tie the information together and query them.  A SQL query is just fundamentally a selection of the information.  Referential integrity, data validation, cardinality rules, etc. Applicable mathematics: Set or type theory Mereology Mereotopology 4 dimensionalism Predicate calculus Logics: modal, Kripke, … Rules, operators: Commutative, reflexive, transitive, … Member-of, subset-of, part-of, … Let's start generally:  "unstructured data", e.g., free text, might be considered one end of spectrum and math (numeric or symbolic) another.   But even so-called unstructured free text can have structure, e.g., the OMG RFP template.  Why do we do semi-structured text?  There's a step to understanding what we’re doing.  Why do we do databases?  There's another step. The shortcoming of databases is that they usually have little more semantic structure than structured text -- named records (or tables or classes if you wish) that are some sort of container for named fields (or attributes or columns).  Via associations and relationships, containers can point to information in other containers.  Because of the labeling, you can tie the information together and query them.  A SQL query is just fundamentally a selection of the information.  I don't think there's much going on besides that.  As for referential integrity, data validation, cardinality rules, etc., it's handy to go back to the semi-structured analogy and see that they just tell you what parts of the form or template have to be filled in, with what choices, what the rules are for cross-references, etc. Math does a lot more.  Let's just talk about logical entailment in this email.  Given, "I have a headache", how do you entail, "I have pain", unless you have a categorization of headache as a type of pain?  You won't get that from unstructured or semi-structured text, or database structure or SQL.  It's "common sense" to you but computers have no more common sense than a light switch (or even a few million light switches). Let's make this more relevant to EA.  "F-16C has a speed capability of Mach x" ==> some F-16's have a speed capability of Mach x "F-16's can fly at least Mach y" ==> F-16C's can fly at least Mach y "Ship's Self Defense System can parse and generate TADIL-J messages" and "SSDS is-part-of all CVNs" ==> CVN's can parse and generate TADIL-J messages I could go on and on.  Without the "intelligence" to perform entailment, data integrations, queries, and analysis algorithms miss connections.  I cannot even remember all the EA data integration and analysis routines I've seen over the years that flopped for this reason -- it is a real problem.  I'd bet Ian has lotsa examples too.  The C4ISR community has problems with semantic imprecision too. My basic point is that we computer scientists think we're doing a lot with computers when we use databases but it's really just storage and retrieval with connections only for exactly matching pieces of information (e.g., "keys" or exactly matching strings).  Reasoning requires a lot more and entailment is an important part.  IDEAS supports entailment and other sorts of mathematical understanding of the data with membership (~ set theory) and 4D mereotopology (parts and boundaries).  It only seems academic at first because it's so fundamental in human reasoning that it's hard to see that computers don't have it at all and that they need it if we want to use them for something more than just storage and retrieval.  We have to encode it into them with formal methods like IDEAS. It's a hard question because it's related to many questions that have been going on for a long time about AI, the "meaning of meaning", semantics vs syntax, types, set theory, categories, mereonomy, etc. I think now that we've got some of the "accidental" problems (e.g., when I had to write assembly language on green tablets or when we couldn't even run RDBMS' because they were too slow) behind us in computer science, we can start chipping away at some of these "essential" questions now.  Depends on near-universal mathematics and science that all learn very similarly

Heterogeneous Data and EA For example: Interoperability assessment Capability gaps and overlaps Capability evolution measures SoS, FoS Portfolio optimization Joint, multi-agency, coalition operations Analysis of alternatives The very reason for EA implies a need to look at data from multiple sources

7. Mathematical precision Create architectural descriptions For example: Queries for disconnects, inconsistencies, … Specialized tools (e.g., cost / risk / performance / sustainment models, interoperability assessment) Process simulators (e.g., comms flow, workflow, Petri nets, state machines) Campaign, mission, engagement, etc. simulators Submit for core process event All have high-sensitivity to mis-interpreted, erroneous, incomplete, incompatible, … data For example: Capability solution proposal Acquisition milestone review Interoperability and supportability assessment checkpoints Budget cycle (PPBE, IRB, CPM) Ops Plan (contingency update cycle, actual) Get and integrate relevant datasets Analyze and assess Present Results for core process decisions

How did we implement IDEAS in DM2?

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

ò Conceptual Phase Data WG DoDAF 2.0 “Core” Process Workshops Authoritative Documents (e.g., DODI, CJCSI, …) DoDAF 2.0 “Core” Process Workshops Joint Capabilities Integration and Development System (JCIDS) Program, Planning, and Budgeting Environment (PPBE) Defense Acquistion System (DAS) Operations Planning Systems Engineering Capabilities Portfolio Management EA Presentation WG Data WG Collect terms Make a pass on “core” terms Group related terms Gather authoritative definitions for “Core” terms Proposed definitions (+rationale, examples, and aliases) Process EA information needs Terms with rough consensus definitions, sources, aliases, rational, examples Design information collection template Conduct and facilitate Compile process information needs ò Existing Models and Databases (many) Data dictionaries & models We have on the top left many natural language documents of “requirements” and on the bottom left, many existing data models and databases, which still rely substantially on natural language From these, we are to develop a reasonably unambiguous structure that supports many requirements How can we do this in a manner that is reasonably systematic, repeatable, and validatable within timeframe and resources? DoDAF 1.5 “Parking Lot” Issues EA Methods WG

Logical Phase Data WG CDM Using a UML class modeling tool: Add relationships During this activity, repeating association patterns became apparent – IDEAS! EA Methods WG Initial thinking about relationship types. (IDEF 5) During this activity, normalization led the WG to see that attributes are just relationships – IDEAS! We have on the top left many natural language documents of “requirements” and on the bottom left, many existing data models and databases, which still rely substantially on natural language From these, we are to develop a reasonably unambiguous structure that supports many requirements How can we do this in a manner that is reasonably systematic, repeatable, and validatable within timeframe and resources? EA Presentation WG Add attributes During this activity, it became apparent: Details are just specializations – IDEAS! Term reconciliation could be done using BORO – IDEAS! Refine detail 1. Data Dictionary 2. UML Ontology Model

Mechanization Add DoDAF concepts and concept relationships as extensions (subtypes) to IDEAS Start with words and definitions Use BORO analysis to figure out the IDEAS type Identify and include in data dictionary aliases and composites (concepts that are modeled as a structure, e.g., Role, Goal.)

Independent Entities Specialization IDEAS Foundation DoDAF 2 Domain Concepts

Associative Entities Specialization So their mathematical meaning is known IDEAS Foundation Associations Temporal Whole-part of Types Type-Instances Before-after for Types Description and naming Whole-part for Types Overlaps of Types Super-subtypes Whole-parts DoDAF 2 Domain Concept Relationships A&D Similarly, we type the associations by classifying them under their IDEAS foundation class.

Physical Level Auto-generated from UML-ish file – no additional semantics added or changed Because the native XSD generator in the UML tool did not understand IDEAS Profile, an XSD generator had to be developed (UK and US) Four XSD’s: IDEAS Foundation, version 1.0 DM2 additional foundation Classification marking (externally controlled) DM2 exchange data Very simple structure never instantiated, metadata reference only

Challenges

Frameworks IDEAS precision reveals ambiguities in framework models which requires revisions of the descriptions, deeper analysis of purposes, … The mathematics of some associations are ambiguous and take work to figure out, e.g., maps-to, depends-on, has-authority-over

Socialization Challenges Ontology education Computer Science education unwittingly emphasizes human interpretations of names and descriptions Ontologic experience is so everyday, conscious dialog about it is difficult Marketing claims about ontology, semantics, interoperability, … have, and continue to, confuse the user community Educating the business value of precision Makes work harder for architectural description producers Integration and analysis needs have often been forgotten Ontology education Computer Science education unwittingly emphasizes human interpretations of names and descriptions Ontologic language is unfamiliar even though ontologic experience is everyday Familiarity causes conscious unawareness, e.g., vision, language understanding, .. Marketing claims about ontology, semantics, interoperability, … have, and continue to, confuse the user community Same as before with AI, Neural Nets, … Solutions are not as easy as they would appear. Currently, only experience teaches this. Educating the business value of precision Makes work harder for architectural description producers Integration and analysis needs have been forgotten

DM2 Collaboration Helped DM2 WG open to all Collaboration Site Business rules, e.g., Aggregation and subtype rules Coordination with many other groups, e.g., Controlled vocabulary Data models Vendors and implementers Software and systems organizations Current baseline CDM, LDM, and PES files and documentation Working copy IDEAS model and profile Folders with: WG information References and research Tutorials and briefings Next meeting info Links to IDEAS & BORO 1. 2. 3. 4. 5. 6.

Adoption Challenges Adopter Types Database or repository implementers – how to Software and systems engineering tool vendors – mapping semantics Modeling and Simulation and Executable architecture tool vendors and developers – scenario, C&P, … representation Custom analysis tool vendors and developers, e.g., portfolio analysis or interoperability assessment tools – relevant parameter representation Mitigators Pilot, early adopter, and vendor support Sample database Education and communication program on wide range of EA data assets Semantic interoperabilty layers definition Exemplars and corresponding education

The Wide Range of EA Data Assets DM2 is the neutral format for Interchange Interoperability Layers (notional) 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

DoDAF 2 Exemplars They are: How they are being developed: Collections of architectural views and their corresponding DM2 PES XML document examples From coherent datasets, e.g., UPDM S&R, NCES ISP How they are being developed: DoDAF Journal DoDAF Outreach Brief - Views Discuss Candidate Datasets with Core Process Stakeholders 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

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

Summary The IDEAS project started as a data sharing project. It produced fruit that was not originally anticipated, e.g., A formal foundation based on solid mathematics A methodology for analysis of domain concepts The adoption by DoDAF is the beginning of being able to integrate, cross-walk, and analyze heterogeneous federated architectural description data sources This is critical in achieving DoD’s EA goals To introduce this level of rigor takes care, patience, and a good communications team

Questions and Comments?