2. 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) 2

3. 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.

4. IDEAS Recap

5. 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]
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 Sources
National Center for Ontologic Research (NCOR),
Direct Model-Theoretic Semantics for OWL 2,
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

9. Benefits of IDEAS for DoDAF 2

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 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

11. 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

12. 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 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 formerly the JTM data model and currently the model for CANES
NIEM – National Information Exchange Model -- – relevant to MDA-related missions
GML -- 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 exchange
VMF – Variable Message Format –
TADIL-J – Tactical Action Data and Information Link --
CoT – Cursor On Target 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 ,
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
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

13. 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

14. 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, or
DD, 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! 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!

16. 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!

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.,
Activities
Before-After
Rules
Conditions
Data structures
Locations
Dependencies
Etc.
Got this one for free too!

19. 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 .  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

20. 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

21. 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

22. How did we implement IDEAS in DM2?

23. 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

24. ò 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

25. 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

26. 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.)

27. Independent Entities Specialization
IDEAS Foundation
DoDAF 2 Domain Concepts

28. 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.

29. 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

30. Challenges

31. 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

32. 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

33. 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.

34. 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

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 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

36. 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

37. 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

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 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

39. Questions and Comments?