1. VERSION 15 UCORE Conference 23 Sep 2009
12/6/ :35
DoDAF 2.0 Meta Model (DM2)
Overview
UCORE Conference
23 Sep 2009

2. Briefing Outline DM2 Purposes What is DM2
Development and Maintenance Principles
Foundation Ontology
Pedigree
DM2 Data Exchange Notional Use Cases

3. DoDAF 2 Goals Support DoD’s core processes:
Capabilities Integration and Development (JCIDS)
Planning, Programming, Budgeting, and Execution (PPBE)
Acquisition System (DAS)
Systems Engineering (SE)
Operations Planning
Capabilities Portfolio Management (CPM)
Establish guidance for architecture content as a function of purpose – “fit for purpose”
Increase utility and effectiveness of architectures via a rigorous data model – the DoDAF Meta Model (DM2) -- so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

4. DoDAF Meta Model (DM2) Purposes
The constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes
Specification for federated EA data exchange between:
architecture development and analysis tools
architecture databases
other authoritative data sources
Support discovery and understandability of EA data:
Discovery of EA data using DM2 categories of information
Understandability of EA data using DM2’s precise semantics augmented with linguistic traceability (aliases)

5. What is the DM2 The DM2 has three levels, .
A conceptual level or Conceptual Data Model (CDM) defines the high-level data constructs from which Architectural Descriptions are created in non-technical terms, so that executives and managers at all levels can understand the data basis of Architectural Description.
A Logical Data Model (LDM) adds technical information, such as attributes to the CDM and, when necessary, clarifies relationships into an unambiguous usage definition.
A Physical Exchange Specification (PES) consists of the LDM with general data types specified and implementation attributes (e.g., source, date) added, and then generated as a set of XSD’s, one schema per DoDAF-described Model.
The DM2 has several levels, each of which is important to a particular viewer of Departmental processes.

6. What is the DM2
The DM2 consists of the following data items:

7. DM2 LDM Data Groups
The DM2 LDM is presented in 12 semantically-related clusters or data groups
Activities
Performer
Resource Flows
Information and Data
Rules
Measures
Locations
Goals
Capability
Services
Project
Training/Skill/Education
For each group:
Diagram, Definitions, and Aliases
Notes
Method of collection and construction
Usage in Core Process

8. DM2 Development and Maintenance Principles
Scope
Information Pedigree
Security classification marking
Term entry
Aggregation rule
Typed Relationships
Implementation neutrality
Definitions
Aliases
Extensions
Research and reference information
DM2 work share site
Configuration Management
Pilot and early adopter support

9. Leveraged Ongoing IDEAS Foundation
Mathematics
type (~set) theory
4D mereotopology
Deals with issues of states, powertypes, measures, space -- what is truly knowable vs. what is assumed
Separates signs and representations from referents
DM2 domain concepts are extensions to the formal foundation
Rigorously worked-out common patterns are reused:
Super-subtype, whole-part, temporal whole-part, type-instance, before-after, overlap
Saved a lot of repetitive work – “ontologic free lunch”
Result is higher quality and consistency throughout
Three types of Things:
Individuals – Things with spatio-temporal extent (not people)
Types – similar to sets
Tuples – ordered relations between Things
As we started figuring out relationships, we realized we were doing the same relationships over and over again. Decided to look into leveraging work we had been doing for several years with the international community on a formal .ontology. IDEAS foundation concepts are inherited into all the DM2 concepts. Saved us a lot of work – ontologic free lunch -- and part of the reason why the model is so small to this day -- ~ 300 classes, attributes, and values as compared to CADM’s 16, 000 pieces.
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.

10. Benefits of adopting the IDEAS formal foundation and common patterns
Model compactness through inheritance of superclass properties and common patterns.
Agreed-upon analysis principles that provide a principled basis for issue analysis
Improved ability to integrate and analyze multiple heterogeneous EA datasets to fulfill EA purposes

11. Why Formal Ontology?
Formalizes important properties of the real world being modeled
Categorization of things (type (~set) theory)
Things can be in many categories
Parts and wholes (mereology)
The parts don’t have to be contiguous, e.g., parts of a squadron
Temporal states (4D mereology)
The objects have a lifetime (temporal extent) that can be broken into temporal states
Overlaps, spatial relationships (mereotopology)
Sequences, before-after (4D mereotopology)
Establishes a criterion of identity -- If something has the same spatio-temporal extent as something else, they are the same
Enables mathematical analysis of EA datasets using well-established set theoretic, geometric, and topologic mathematic “laws” and theorems, e.g.,
Commutivity and anti-commutivity, e.g.,
Symmetry and anti-symetry
Reflexivity and irreflexivity
Associativity
Transitivity
Many others D

12. Information Pedigree – workflow model ~ Open Provenance Model (provenance = linked together pedigrees)
Information Production Activity
Resources Used, e.g., other Information
Who
Rules followed in the production 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
Measures in the production, e.g., QoS, uncertainties
Where done

13. Use Cases Identification / Requirements Why do I exchange EA data?
JCIDS
JCD / ICD / CPD / CDD / FNA / FSA / FNA / AoA / TDS Evaluator – overlap and best value comparison
ISP / TISP Evaluator – interoperability comparison
Tester – “derive” / trace TEMP to
Preparer -- reuse
DAS
Milestone Reviews
Gate reviews
Functional Control Boards (FCB)
PPBE
Investment Review Boards (IRB)
OMB 300
Determine & defend FYDP
CPM / CPIC
Functional alignment of portfolio
PPBE support
Systems Engineering
Spec development
Ops Planning
Plans development
Interoperability Assurance
Ability to share architectures across enterprise
Discover the right architecture
False hits are costly – must be minimized
Must successively refine discovery/search
Search must:
be Federated across the DoD repositories
Include registry categories and taxonomies
Sample/snapshot data is required
Access the architecture
WSDL (web services discovery language)
Pass authentication credentials – single sign-on
Register the architecture
Type / quantity of data, by DM2 concept
By model (product)
By JCA (subject area)
By AV-1 (purpose, scope, format, dates, POCs, tools, TBD)
By taxonomies
Understand the accessed architecture
DM2
Taxonomies
Must meet DoD Legal/regulatory requirements
Must meet federal and DoD information sharing
DARS Functional Requirements
(Based on DoD CIO, JCS and OMB guidance – see refs)
Draft
Required Functions
Implement all major tenets of the Net-centric Data Strategy for architecture data [Make Data Visible and Accessible, Institutionalize Data Management, Enable Understandability and Trust, and Support Interoperability].
Make Data Visible
Expose data via query and navigation, subject to policy-based visibility controls
Implement DoD standards for visibility
Implement the DoD Discovery Metadata Specification (DDMS)
Implement federated search conforming to DoD standards
Make Data Accessible
Expose data in a publically accessible web site
Make data available in commonly useable formats
Provide data access services with controls appropriate to security, privacy and need-to-know constraints
Implement and Assess Data Management Best Practices
Implement data management best practice processes
Implement data editing controls
Implement data configuration management processes
Validate data quality in architectures
Validate use of “approved” vocabularies, taxonomies
Validate use of data federation standards
Validate content conformance with policy and guidance
Provide metrics on data quality
Enable Understandability
Identify vocabularies and schemas used
Identify content via content metadata exposure
Identify formats via metadata exposure
Support Trust in Data
Identify the source and authority of data
Identify data access controls
Identify the validation and approval status of data
Identify the validity time frame of data
Identify the currency of data (creation date and refresh cycle time)
Identify the intended use of data (purpose and scope)
Implement controls to ensure the integrity of metadata
Support Interoperability
Implement DoD, Federal and commercial standards for data exchange
Implement DoD standards for content metadata
Implement standards for data federation
Identify data formats and schemas used for data exchange
Support Compliance with the DoD IEA
Identify implementation of Data and Services Deployment practices in architectures
Identify implementation of Secured Availability practices in architectures
Identify implementation of Computing Infrastructure Readiness (CIR) practices in architectures
Identify implementation of Communications Readiness (CR) practices in architectures
Identify implementation of NetOps Agility (NOA) practices in architectures
Support JCIDS Processes
Support Capability-Based Architecture (CBA) alignment and assessment
Validate architecture content and quality directed by JCS instruction
Identify validation status of architectures
Identify KPP content in architectures
Identify Joint Potential in architectures
Support Compliance with OMB Guidance for FEA Practices
Support Segment identification
Identify alignment of architectures with Segments
Identify alignment of architectures with FEA reference models
Identify reuse of systems, services, and data in architectures
Specific DARS functions
Ability to tag architectures, architecture artifacts and architecture reference data sets with DoD Discovery Metadata Specification (DDMS)-conformant discovery metadata and provide discovery services in conformance with enterprise content discovery standards. [NCDS Visibility]
Provide automated discovery metadata tagging of registered content,
Provide editing of discovery metadata,
Provide content discovery services
Ability to import, store, index, reference, link, and export architecture data (including taxonomies, reference models, fit-for-purpose data sets, vocabularies, etc.) with authenticated role-based and/or attribute-based controlled access to support architecture development in conformance with DoD EA standards for data structure, semantics and content. [NCDS Accessibility, Understandability and Trust]
Provide content registration services,
Provide group-based visibility and access control to registered content,
Integrate user authentication with DKO,
Provide data import/export services conforming to the DoDAF Meta Model (DM2)
Ability to identify the source and authority of architecture data. [NCDS Trust]
Ability to restrict the recording of source and authority properties of data to authorized parties.
Ability to tag, import, export, discover and visualize the source and authority properties of data.
Ability to restrict the recording of data authority properties in discovery metadata to ensure trust in the pedigree of architecture data. [NCDS Trust]
Ability to federate authoritative architectures, architecture artifacts and reference data with traceability to authority for federation.
Implement architecture federation IAW DoD Architecture Federation Strategy, [NCDS Trust, Understandability, FEA practices]
Ability to federate/align architectures and architecture artifacts, including taxonomies, vocabularies and reference data, with DoD EA segments, Joint Capability Areas and other reference models, reference architectures and taxonomies. [DARS FY-09 Functional Support Agreement, FEA Practice Guidance]
Ability to provide community-based visibility and access control over architecture data and discovery metadata. []
Ability to validate conformance of architecture data with DoD standards, policy and guidance for architecture content.
Ability to provide metrics on federated architecture content and conformance with EA standards, policy and guidance.
Facilitate architecture exchange and interoperability.
Ability to import, export, and manage taxonomies and vocabularies
DARS Roles
Authoritative source for DoD architecture data and EA standards.
Tool for assessment of architecture conformance of with DoD EA standards.
Tool for assessment of data quality management practices for authoritative data sources.
Tool for managing authoritative architectures, including segment, capability and solution architectures, and the federated structure of the DoD EA.
Tool for assessing conformance of architectures with EA federation standards for alignment with segment and other reference architecture standards.
References
DoDD , Data Sharing in a Net-Centric Department of Defense
DoD Architecture Federation Strategy
FEA Practice Guidance
Federal Enterprise Architecture Data Reference Model V 2.0
FAQs
Can required functions be achieved by DKO, the DMR, DISR, JCPAT, KMDS, DITPR, DNAP-IT, or a combination of these capabilities?
How does DARS relate to the DMR?
How does DARS relate to DISR?
How does DARS relate to the DITPR?
How does DARS relate to the SOA Foundation?
How does DARS support acquisition decision making?

14. Interrogatives Relationship to DM2 CDM UCORE 2
Interrogatives Relationship to DM2 CDM UCORE 2.0 Who, What, When, Where
WHEN
WHY
HOW
WHAT
WHO
WHERE

15. Questions?

16. Backup

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

18. DoDAF Domain Concepts are Specializations
Thing
Type
Individual
Individual Type
A&D
So you take all the DM2 domain concepts and classify them into the IDEAS foundation classes.
So they inherit associations (can occupy association place positions)
(zoom-in to read or see handout)

19. All Associations are Typed
Before-after
Whole-part for Types
Overlap for Types
Before-after for Types
Description and naming
Instance-of-type
Instance-of-powertype
A&D
Similarly, we type the associations by classifying them under their IDEAS foundation class.
So their mathematical meaning is formally modeled – a first in DoDAF meta models
(zoom-in to read or see handout)

20. Naming and Description Pattern
A&D
Multiple names for same thing (aliases) – must tell Naming Scheme
Information (formerly Information Element) linked to the Things it describes