1. DoDAF Data Meta Model (DM2) Overview
Workshop for ACT – IAC, EA-SIG
Mr. David McDaniel (ctr)
20 July 2012

2. Agenda DM2 Context Conceptual Data Model Logical Data Model
Ontologic foundation: International Defence Enterprise Architecture Specification (IDEAS)
Relationship to DoDAF models
Physical Exchange Specification
Overcoming challenges to change

3. Lay of DoDAF Land Model (view) specifications DM2 Operational
Capabilities
Services
Systems
Data and Information
Standards
Projects
DM2
The 52 DoDAF models and the DM2 are related via a matrix

4. The DM2 Has Three Levels DIV-1 (CDM) DIV-2 (LDM) DIV-3 (physical)
(This is where almost all the design and analysis work is done)
DIV-3 (physical)
(Auto-generated from the LDM)
Logical Data Model (LDM)
Reified and Formalized relationships
Conceptual Data Model (CDM)
Concepts and concept relationships
Physical Exchange Schema (PES)
XML encoding of LDM
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

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

6. Sources Definitions IEEE ISO W3C OMG EIA DODD & DODI
JCS Pubs, especially CJCSI's
DoDAF
Other frameworks: Zachman, MODAF, TOGAF, NAF, ...
FEA
BMM
Worknet
Wikipedia
English dictionaries
DoDAF Glossary
Models
DoD Core Architecture Data Model (CADM) 1.5
International Defence Enterprise Architecture Specification (IDEAS)
OMG Business Motivation Metamodel (BMM)
Hay/Zachman
MITRE Architecture Specification Model (ASM)
CRIS (TRANSCOM)
MODAF Meta Model (M3)
NAF Meta Model
DoI Meta Model
Joint Command, Control, and Consultation Information Exchange Model (JC3IEDM)
Geospatial Markup Language (GML)
Universal Core (UCORE)
GEIA 927
AP233
SUMO and ISO (via IDEAS)
FEA Reference Models
JFCOM JACAE
On the left are the model sources we considered to date; on the right, additional sources for definitions.
Note that as a result of the Ops Planning workshop at JFCOM last week, we now can add JACAE as source. That metadata is being parsed into the spreadsheet this week.
Note also, that we considered sereral non-AF sources, e.g., JCS Pub 1-02, the DoD Dictionary of Military Terms, and English dictionaries.

7. Definition Phase Example 1
Category
Capability
Technical Term
Proposed Definition
Capability: (n) 1. The ability to execute a specified course of action. (JP 1-02) 2. The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks. (JCIDS)
Potentially Related Terms or Aliases
Source/Current Definition (source) definition
(JCIDS): The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks. (DoDAF/CADM): An ability to achieve an objective. (DDDS Counter (333/1)(A)) (JC3IEDM): The potential ability to do work, perform a function or mission, achieve an objective, or provide a service. (NAF): The ability of one or more resources to deliver a specified type of effect or a specified course of action. (GEN TERM) (NAF): A high level specification of the enterprise's ability. (MM) (JCS 1-02): The ability to execute a specified course of action. (A capability may or may not be accompanied by an intention.) (Webster's): 1. The quality of being capable; ability. 2. A talent or ability that has potential for development or use. 3. The capacity to be used, treated, or developed for a specific purpose.
Examples
"The soldier shall be able to load and fire his individual weapon." (JP 1-02) "The soldier shall be able to load and fire his individual weapon from (positions) on a trainfire range, in (weather) to achieve a minimum score of "Marksman" on the Army Marksm
Definition Rationale
Authority: "The Secretary of Defense, by DOD Directive , 23 August 1989, Standardization of Military and Associated Terminology, has directed the use of JP 1-02 throughout the Department of Defense to ensure standardization of military and associated terminology.

8. Conceptual Level of DM2 is Simple
anything can have Measures
Condition
Guidance
is-performable-under
Rule
Activity
Capability
Standard
Agreement
constrains
requires-ability-to-perform
has
consumes-and-produces
is-performed-by
is-realized-by
Project
achieves-desired-effect (a state of a resource)
is-the-goal-of
Resource
describes-something
Information
Not shown but implied by the IDEAS Foundation:
Everything is 4-D and so has temporal parts, i.e., states
Everything has parts
Everything has subtypes
Activity: Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state.
Resource: Data, Information, Performers, Materiel, or Personnel Types that are produced or consumed.
Materiel: Equipment, apparatus or supplies that are of interest, without distinction as to its application for administrative or combat purposes.
Information: The state of a something of interest that is materialized -- in any medium or form -- and communicated or received.
Data: Representation of information in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Examples could be whole models, packages, entities, attributes, classes, domain values, enumeration values, records, tables, rows, columns, and fields.
Performer: Any entity - human, automated, or any aggregation of human and/or automated - that performs an activity and provides a capability.
Organization: A specific real-world assemblage of people and other resources organized for an on-going purpose.
System: A functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements.
Person Role: A category of persons defined by the role or roles they share that are relevant to an architecture.
Service: A mechanism to enable access to a set of one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. The mechanism is a Performer. The capabilities accessed are Resources -- Information, Data, Materiel, Performers, and Geo-political Extents.
Capability: The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.
Condition: The state of an environment or situation in which a Performer performs.
Desired Effect: A desired state of a Resource.
Measure: The magnitude of some attribute of an individual.
Location: A point or extent in space that may be referred to physically or logically.
Guidance: An authoritative statement intended to lead or steer the execution of actions.
Rule: A principle or condition that governs behavior; a prescribed guide for conduct or action.
Agreement: A consent among parties regarding the terms and conditions of activities that said parties participate in.
Standard: A formal agreement documenting generally accepted specifications or criteria for products, processes, procedures, policies, systems, and/or personnel.
Project: A temporary endeavor undertaken to create Resources or Desired Effects.
Geopolitical Extent A geospatial extent whose boundaries are by declaration or agreement by political parties.
Materiel
Performer
Data
System
Organization
is-at
Location
GeoPolitical
Service
PersonRole
is-part-of

9. Logical Phase
Data WG
Using a UML class modeling tool:
EA Methods WG
EA Presentation WG
CDM
Add relationships
Add attributes
Refine detail
During this activity, repeating association patterns became apparent – IDEAS!
During this activity, normalization led the WG to see that attributes are just relationships – IDEAS!
During this activity, it became apparent:
Details are just specializations – IDEAS!
Term reconciliation could be done using BORO – IDEAS!
Initial thinking about relationship types. (IDEF 5)
1. Data Dictionary
2. UML Ontology Model
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?

10. IDEAS Layered Approach
1. Foundation (upper ontology)
Ontologic concepts and relationships
Commonly used patterns, e.g., Resource Flow, Exchange
Universally accepted concepts and relationships, e.g., person, organization, material, etc.
2. Common patterns
3. Universal objects & relationships X X X X
Reports drawn from the architecture data specific to needs and policies of individual nations
national
views
national
views
national
views
national
views 10

11. Everthing (except Thing) is an Extension
Attributes
Relationships (associations)
Domain Values (enumerations)
From KBIS’ IDEF-5 Spec

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

13. Mathematical 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) z x
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. t * t
* © Rob Byranton

14. Independent Entities Specialization
IDEAS Foundation
DoDAF 2 Domain Concepts

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

16. One Result: Compare DM2’s predecessor, a classic E-R model
CADM had 687 entities, 3,914 attributes, 11,911 domain values, and 1,249 associations = 17,762 data elements
DM2 has less than 300 data elements TOTAL
And can represent more
(only shows entities, attributes, and relationships, domain values are non-graphical)
CADM had 687 entities, 3,914 attributes, 11,911 domain values, and 1,249 associations = 17,762 data elements
DM2 has 217 foundation and domain data elements, 37 IC-ISM's, and 4 metadata for a total of 258 data elements

17. DM2 Data Groups Performers Resource Flows Information and Data Rules
Capabilities
Services
Projects
Organizational Structures
Measures
Locations
Pedigrees
Documentation per data group in DoDAF Volume II describes non-obvious features.

18. Example: Resource Flows

19. DoDAF Models are described according to DM2
OV-2 Example (pg 1 of 2)
SHALLS & MAYS

20. Example (pg 2 of 2)

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

22. Example 3. Information Pedigree Model
Workflow model, e.g., Open Provenance Model (provenance = linked together pedigrees)
= Activity model (OV-5 + 6c) 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

23. Example 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
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
Rules
constrain
constrain
constrain
Worker
Technician
Engineer
Architect
Executive
Strategic
Op Rqmt TLR SLR A-Spec B-Spec C-Specs
time
CBA ICD AoA Perf Spec CDD CPD
IOC

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

25. PES Structure Planned for future interoperability with IDEAS
Packaging, e.g., overall classification marking
Extra goodies for Dublin Core (optional)
Screen-scrape of the actual PES XSD
Architecture data – tag names and definitions are exactly from DM2 LDM
Where you say what views the data corresponds to
One PES file can have multiple views
A single piece of data can be in multiple views
A recipient of the XML file should validated it against PES XSD which automatically encodes the “monster matrix”.
XML stuff -- unimportant
This could be made optional

26. The Wide Range of EA Data Assets
XMI / MOF Conversant (e.g., UPDM / SysML)
Analysis Software
DM2 PES
XSD
neutral
implementation
EA / ITA Tools
Authoritative Data
Sources
EA Domain Concepts
Common
Patterns
4D Mereology
Set Theory
Naming
Pedigree
M&S
Tools EA
DBMS’
Ontic Foundation
Reporting Tools and Formats
Federal, Coalition, and other EA exchanges
DM2 is the neutral format for Interchange

27. Overcoming Challenges to New Ways

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

29. WG Business Rules Essential for Broad Community Consensus

30. DoD Architectures COI WG is being considered
Would cover, perhaps on a rotating basis:
Architecture information sharing needs
Architecture standards (i.e., DoDAF, DM2, others)
Architecture tools (i.e., current vendor list, DARS, others)
Architecture relevance in core processes and governance
Architecture federation
Architecture best practices

31. Summary
At the conceptual level, DM2 was grounded in the six core processes DoDAF is required to support: JCIDS, DAS, SE, PPBE, CPM, and OPS
The adoption by DoDAF of the IDEAS formal ontology as a foundation for the DM2 LDM resulted:
A very compact and relatively easy model to understand model that represents complex information such as pedigree and reification
A mathematical means for integration, cross-walk, and analyze heterogeneous federated architectural description data sources that is critical in achieving DoD’s EA goals
To introduce this level of rigor takes care and patience in your organization

32. Questions?