2 Contractor, Enterprise Architecture & Standards Implementation of the International Defence Enterprise Architecture Specification (IDEAS) Foundation in DoD Architecture Framework 2.09 MARCH 2010DAVE MCDANIELContractor, Enterprise Architecture & StandardsOffice of the DoD Deputy Chief Information Officer +1 (619)2
3 Outline of Presentation IDEAS RecapWhy we used IDEAS – benefitsRe-use of common patterns saved a lot of workReconciliation and analysis toolInformation pedigree modelDesign reification and requirements traceabilityServices descriptionSemantic precisionMathematical precisionHow we implemented IDEASImplementation challengesThe 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.
5 Top-Level Foundation Four dimensionalist -- xyzt Extensional -- physical existence is the criterion for identitySigns and representations are separated from referentsMathematics:Type theory ~ Set theoryMereology (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.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.or
6 Type Theory Math Examples Flip over – not time to brief
7 Mereotopologic Math Examples Overlaps, spatial relationships (mereotopology)Behaviors -- Sequences, before-after (4D mereotopology)Flip over – not time to brief
8 Some Math SourcesNational Center for Ontologic Research (NCOR),Direct Model-Theoretic Semantics for OWL 2,VocabularyInterpretationsObject Property ExpressionsData RangesClass ExpressionsSatisfaction in an InterpretationClass Expression AxiomsObject Property Expression AxiomsData Property Expression AxiomsDatatype DefinitionsKeysAssertionsOntologiesModels
10 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 throughoutModel 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 datasetsSuper/Sub Type, e.g.,F-15 is type of FighterWhole Part, e.g.,AEGIS radar is part-of the AEGIS shipOverlaps, particularly Interface Type, e.g.,Asset data collection activities produce data for audit reportingBefore-After, e.g.,The collection task takes place before the posting and exploitation tasks
11 2. Reconciliation and analysis tool (slide 1 of 4) State of practice in data modeling:Noun and adjective analysisSimilar to natural language written in a diagramOften laden with entrenched but obsolete technology considerationsThe fundamental concepts of Entity-Relationship and Class Models:predicatesubjectobjectImplicit, 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 encounteredReally a structured documentJoins and associations allow for flexible sub-documentsGood for storing and retrieving informationLousy for automated computation uponSet theory – categories of thingsMeronymy – spatial relationships between thingsTuples – ordered relationships between thingsLogic – deductive, monotonic, non-monotonic, …Inference – probabilistic, evidential, …Lexical semantics, mathematical linguistics, …Like all complex systems, made up of many piecesThe pieces interact through dataOriginally, piece makers (engineers, programmers) worked pair-wise (e.g., at design meetings, telephone, test sites) to figure out the interaction – involved much human interactionWith network “bus” architectures, easier to make interaction possible because the data is availableBut understandable only by much human interaction1The number of pieces continues to grow2The number that need to interact continues to grow3The scope of data they would like to use continues to grow4XML provides documentation with the data, but humans still have to read and understand it.e.g., Smart Ship, Integrated Bridge System, BMDContinuing C4I – Combat System integration, Joint systems, OA and CANES SoA componentizatione.g., reference data such as ECDIS-N charts and GCCS-I3 use in Combat System
12 One Result of this practice -- data model “wars” C2 CoreUCORE modelMIEMAnti-Submarine Warfare (ASW) COIBlue Force Tracking (BFT)C2 Interoperability GroupCBRNCoalition C2 Interoperabilty (Coal C2)Common SensorGEOINT Standards COI (GWG COI)Global Force Management (GFM)GPS Based Positioning Navigation Timing ServiceIntegrated FiresJoint Air and Missile DefenseJoint Air Track (JAT)Joint Electronic Warfare Data StandardizationJoint Targeting Intelligence (JTI)Maritime Domain AwarenessMeteorology-Oceanography (METOC)Mine WarfareSymbology (SYM)Undersea Warfare XML (usw-xml)CNDE modelUsers of these different models believe their model is the best for many purposes, in many cases overlapping purposes.NIEMGMLSensor MLTransducer MLa smattering – see notes for short descriptionsJC3IEDM (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 DoDMIEM – Maritime Information Exchange Model – relevant to MDA-related missionsCNDE – Consolidated Net-centric Data Environment -- https://nesi.spawar.navy.mil/projects/jtm/ -- formerly the JTM data model and currently the model for CANESNIEM – National Information Exchange Model -- – relevant to MDA-related missionsGML -- Geography Markup Language -- 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 NATO standard for coalition C2 information exchangeVMF – Variable Message Format –TADIL-J – Tactical Action Data and Information Link --CoT – Cursor On Target implemented by many smaller systemsA “Common” Data Model Has Not WorkedMandating “common” is problematic:Ignored, e.g., DoD Data Admin policy and “Corporate Information Management” -- rescinded in favor of current “market-driven” strategy; SECNAVINST ,Or complied with at great cost in terms of $’s, rqmts-to-deploy time, and interoperabilityOne size rarely fits all, e.g., normalization is good for transactions, bad for miningA rational basis for model determination seems betterCOI Name MissionAnti-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 DirectiveC2 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.CBRNCoalition 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 & EvaluationGEOINT 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 consensuGlobal 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 thGPS 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 reMine Warfare provide a location for creation and sharing of data to be used in the Mine Warfare arenaSymbology (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 TargetLike diverse languages, there is a high cost to learn
13 Some real-world and costly results of this practice Cost and project riskDevelopers and integrators must learn multiple proprietary “languages”Need to build many translatorsOver promised ability of “translation hubs”Context, interdependent, and value-dependent translationsOperational impactE.g., from “lossy” translations, mis-translations, …Difficulty in transitioning new technologies, e.g., automated processing toolsProhibits or impedes scaling and cross-domain integration and data sharingImpedes Net-Centricity / OA / SoA due to need for much human interaction, e.g., no automated unanticipated usersThe costs and risks – both project and operational -- are usually underestimated
14 Reconciling Using IDEAS Analysis Technique: BORO1 Agreed-upon principles that provide a principled basis for issue analysisExample decision processtimeExample BORO analysis diagramDaveCopy and SendIanCopyDD, copy 1Flow processSendpartDave’s Document, OriginalReceivepartDave’s Document, Copy 1, in flow state1. Business Objects Reference Ontology, orDD, copy 1
15 3. Information Pedigree Model Workflow model, e.g., Open Provenance Model (provenance = linked together pedigrees)= Activity model (OV-5 + 6c) got nearly for free!DRequirement in the DoD Net-Centric Data Strategy (NCDS)Similar to Open Provenance ModelDescribes the workflow that led to the production of the informationPedigree is the immediate link – provenance further back in the production chainActivities, Performers, Performer states, resources used, rules abided by, measures conformed toGot this one nearly for free!
16 4. Design Reification and Requirements Traceability describesdescribesdescribesThingdescribesdescribesPedigree(requirements)Pedigree(requirements)Pedigree(requirements)Pedigree(requirements)Architectural DescriptionPedigree(requirements)Architectural DescriptionArchitectural DescriptionArchitectural DescriptionArchitectural DescriptionRulesRulesRulesconstrainA&DSuccessive 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.RulesconstrainRulesconstrainconstrainconstrainWorkerTechnicianEngineerArchitectExecutiveStrategicOp Rqmt TLR SLR A-Spec B-Spec C-SpecsJCDtimeIOCGot this one for free too!
17 5. Service Descriptions (1 of 2) From OASIS SoA RAF, Figure 27, “Service Description”
18 Service Descriptions as Modeled in DM2 This means a Service Description can have all the structure of an Architectural Description, e.g.,ActivitiesBefore-AfterRulesConditionsData structuresLocationsDependenciesEtc.Got this one for free too!
19 6. Semantic Precision for Heterogeneous Data Integration Human-interpretable onlyA spectrum of information sharingHuman-interpretable but with a predictable organized arrangementMore structure than structured textNamed 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 containersBecause 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 theoryMereologyMereotopology4 dimensionalismPredicate calculusLogics: 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 . 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 messagesI 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
20 Heterogeneous Data and EA For example:Interoperability assessmentCapability gaps and overlapsCapability evolution measuresSoS, FoSPortfolio optimizationJoint, multi-agency, coalition operationsAnalysis of alternativesThe very reason for EA implies a need to look at data from multiple sources
21 7. Mathematical precision Create architectural descriptionsFor 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. simulatorsSubmit for core process eventAll have high-sensitivity to mis-interpreted, erroneous, incomplete, incompatible, … dataFor example:Capability solution proposalAcquisition milestone reviewInteroperability and supportability assessment checkpointsBudget cycle (PPBE, IRB, CPM)Ops Plan (contingency update cycle, actual)Get and integrate relevant datasetsAnalyze and assessPresent Results for core process decisions
23 The DM2 Has Three Levels DIV-1 DIV-2 DIV-3 Conceptual Data Model (CDM) Logical Data Model (LDM)Reified and Formalized relationshipsDIV-1DIV-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 relationshipsThe 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 thembusiness language of the enterprisenormative across the six core processesA logical level or Logical Data Model (LDM) formalizes the relationships in the CDM mathematicallyA physical level or Physical Exchange Specification (PES)adds required NCDS metadata for security and pedigree to the LDMis generated from the LDM as a set of XSD’s, one schema per DoDAF-described ModelPhysical Exchange Schema (PES)XML encoding of LDM
24 ò Conceptual Phase Data WG DoDAF 2.0 “Core” Process Workshops Authoritative Documents (e.g., DODI, CJCSI, …)DoDAF 2.0 “Core” Process WorkshopsJoint Capabilities Integration and Development System (JCIDS)Program, Planning, and Budgeting Environment (PPBE)Defense Acquistion System (DAS)Operations PlanningSystems EngineeringCapabilities Portfolio ManagementEA Presentation WGData WGCollect termsMake a pass on “core” termsGroup related termsGather authoritative definitions for “Core” termsProposed definitions (+rationale, examples, and aliases)Process EA information needsTerms with rough consensus definitions, sources, aliases, rational, examplesDesign information collection templateConduct and facilitateCompile process information needsòExisting Models and Databases(many)Data dictionaries & modelsWe 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 languageFrom these, we are to develop a reasonably unambiguous structure that supports many requirementsHow can we do this in a manner that is reasonably systematic, repeatable, and validatable within timeframe and resources?DoDAF 1.5 “Parking Lot” IssuesEA Methods WG
25 Logical Phase Data WG CDM Using a UML class modeling tool: Add relationshipsDuring this activity, repeating association patterns became apparent – IDEAS!EA Methods WGInitial 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 languageFrom these, we are to develop a reasonably unambiguous structure that supports many requirementsHow can we do this in a manner that is reasonably systematic, repeatable, and validatable within timeframe and resources?EA Presentation WGAdd attributesDuring this activity, it became apparent:Details are just specializations – IDEAS!Term reconciliation could be done using BORO – IDEAS!Refine detail1. Data Dictionary2. UML Ontology Model
26 MechanizationAdd DoDAF concepts and concept relationships as extensions (subtypes) to IDEASStart with words and definitionsUse BORO analysis to figure out the IDEAS typeIdentify and include in data dictionary aliases and composites (concepts that are modeled as a structure, e.g., Role, Goal.)
28 Associative Entities Specialization So their mathematical meaning is known IDEAS Foundation AssociationsTemporal Whole-part of TypesType-InstancesBefore-after for TypesDescription and namingWhole-part for TypesOverlaps of TypesSuper-subtypesWhole-partsDoDAF 2 Domain Concept RelationshipsA&DSimilarly, we type the associations by classifying them under their IDEAS foundation class.
29 Physical LevelAuto-generated from UML-ish file – no additional semantics added or changedBecause 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.0DM2 additional foundationClassification marking (externally controlled)DM2 exchange dataVery simple structurenever instantiated, metadata reference only
31 FrameworksIDEAS 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
32 Socialization Challenges Ontology educationComputer Science education unwittingly emphasizes human interpretations of names and descriptionsOntologic experience is so everyday, conscious dialog about it is difficultMarketing claims about ontology, semantics, interoperability, … have, and continue to, confuse the user communityEducating the business value of precisionMakes work harder for architectural description producersIntegration and analysis needs have often been forgottenOntology educationComputer Science education unwittingly emphasizes human interpretations of names and descriptionsOntologic language is unfamiliar even though ontologic experience is everydayFamiliarity causes conscious unawareness, e.g., vision, language understanding, ..Marketing claims about ontology, semantics, interoperability, … have, and continue to, confuse the user communitySame 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 precisionMakes work harder for architectural description producersIntegration and analysis needs have been forgotten
33 DM2 Collaboration Helped DM2 WG open to allCollaboration SiteBusiness rules, e.g.,Aggregation and subtype rulesCoordination with many other groups, e.g.,Controlled vocabularyData modelsVendors and implementersSoftware and systems organizationsCurrent baseline CDM, LDM, and PES files and documentationWorking copyIDEAS model and profileFolders with:WG informationReferences and researchTutorials and briefingsNext meeting infoLinks to IDEAS & BORO22.214.171.124.5.6.
34 Adoption Challenges Adopter Types Database or repository implementers – how toSoftware and systems engineering tool vendors – mapping semanticsModeling and Simulation and Executable architecture tool vendors and developers – scenario, C&P, … representationCustom analysis tool vendors and developers, e.g., portfolio analysis or interoperability assessment tools – relevant parameter representationMitigatorsPilot, early adopter, and vendor supportSample databaseEducation and communication program on wide range of EA data assetsSemantic interoperabilty layers definitionExemplars and corresponding education
35 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 SoftwareDM2 PESXSDneutralimplementationEA / ITA ToolsAuthoritative DataSourcesEA Domain ConceptsCommonPatterns4D MereologySet TheoryNamingPedigreeM&SToolsEADBMS’Ontic FoundationReporting Tools and FormatsFederal, Coalition, and other EA exchanges
36 DoDAF 2 Exemplars They are: How they are being developed: Collections of architectural views and their corresponding DM2 PES XML document examplesFrom coherent datasets, e.g., UPDM S&R, NCES ISPHow they are being developed:DoDAF JournalDoDAF Outreach Brief - ViewsDiscuss Candidate Datasets with Core Process StakeholdersConform Diagram to DoDAF 2 and Add LegendsDoDAF Outreach Brief – DM2 Developers / Analyst / IntegratorDM2 Description Document – PESDoD MDRDM2 Collaboration SiteAdd Additional Markups for DM2Enter Into DM2 DatabaseDM2 DBReview With DM2 WGDM2 PES XML Document
37 Review for DoDAF 2 Conformance Review for DM2 Conformance DM2 / DoDAF Testbed PlanDoDAF 2 Exemplars: View Diagrams View DM2 PES DatasetsDoDAF View Diagram PublisherReview for DoDAF 2 ConformanceDoDAF 2 View Diagrams and DescriptionsTool DB(or data structure)DoDAF WGDM2 PES XML Generator / ExporterDM2 PES XML DocumentDevelop views in toolData BrowsersDM2 WGDM2 DBReview for DM2 ConformanceDM2 PES XML Document Validator
38 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 mathematicsA methodology for analysis of domain conceptsThe adoption by DoDAF is the beginning of being able to integrate, cross-walk, and analyze heterogeneous federated architectural description data sourcesThis is critical in achieving DoD’s EA goalsTo introduce this level of rigor takes care, patience, and a good communications team
Your consent to our cookies if you continue to use this website.