1. VERSION 15
9/12/ :44
International Defence Enterprise Architecture Specification (IDEAS) and DoDAF 2.0 Data Model
OMG Systems Engineering Domain
Special Interest Group (SE DSIG)
Mr. David McDaniel
Silver Bullet Solutions, Inc.
under contract to OASD (NII) / DoD CIO
11 March 2008

2. Outline DoDAF 2.0 Data Model Development Process IDEAS Role
Overview of Conceptual Data Model version 0.1

3. Top-Down / Bottom-Up Development
DoDAF 2.0:
Conceptual Data Model (Vol I)
Logical Data Model (Vol II)
Physical Exchange Model (Vol III)
Existing / Emerging Schema, Models, and Databases
Data Model Development
COI1
COIn
COI Coordination
PPBE Process Information Requirements
JCIDS Process Information Requirements
Ops Planning Process Information Requirements
SE Process Information Requirements
DoD Core Process Information Requirements Collection
UCORE
DAS Process Information Requirements
CPfm Process Information Requirements

4. 3. Make a pass on the “Core” Terms 1. Overviews of Models
2. Collect the terms
1 = Core, critical to process or very common in architectures
2 = Derived or less common
3 = TBD
4 = TBD
5 = TBD 5 4 3 2 1
5. Group related terms
4. Gather authoritative definitions for “Core” terms
7. Relationships
6. Proposed definitions (+rationale, examples, and aliases)
8. Relationship Types
This slide is an update to what has been presented before.
Recall,
We gathered overviews of many relevant models, listed on the next slide
We pulled the key terms into a spreadsheet, keeping track of the source
We noticed certain repeating ones, and ones that seemed “core” We ranked their core-ness / priority / key-ness. We ended up with key / core terms, which seemed about manageable
We gathered “authoritative” definitions for those 50-60, from the models plus the definition sources shown on the next slide
We noticed some terms referred to related concepts, perhaps, so we grouped them
We’ve been coming up with a proposed definition, following some group guidance. We also record the rationale and are working on examples for each definition.
We’ve started working on relationships between the concepts the terms refer to
We are starting to think about formalizing a few key relationships, e.g., super/subtype, whole-part, produce/consume (input/output), performs/supports/…,
This work is all done by various members of the SWG.
Not shown here, is that SWG members researched many thorny semantic issues and reported back to the WG their findings.
12/3
Strawman – list of important or recurring “core” words/terms/concepts with source definition(s)
1/3
Partial Draft –
proposed definitions, some harmonization (e.g., via super/subtyping, determining aliases)
2/3
Interim Draft – Initial relationships (e.g., "performs", "part-of", ...)
3/3
CDM version 0.1
Concepts (defined)
Relationships (some typing, e.g., super/sub, cardinality)

5. Logical and Physical Exchange Models
VOLUME II, DoDAF Logical Data Model (LDM)
The DoDAF Logical Data Model (LDM) is the Conceptual Data Model described in Volume I with attributes, specializations, and association reifications added
VOLUME III 1. DoDAF Physical Data Exchange Model
Physical Data Exchange Model is the Logical Data Model 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 product/view type described in Volume II. The full model is also available on DARS for customized product/view, topics, or other needs. The DoDAF Physical Data Exchange Model (PDEM) is TBS.

6. Sources Models CADM 1.5 IDEAS UPDM BMM Hay/Zachman ASM CRIS
Conceptual CADM in DoDAF 1.0 / prototype CADM 2.0 M3
NAF Meta Model
DoI Meta Model
JC3IEDM
GML
UCORE 1.1
GEIA 927
AP233
SUMO and ISO (via IDEAS)
FEA Reference Models
JFCOM JACAE
Definitions
IEEE
ISO
W3C
OMG
EIA
DODD & DODI
JCS Pubs, especially CJCSI's
Models in the Source_Candidates_ ppt
DoDAF
Other frameworks: Zachman, MODAF, TOGAF, NAF, ...
FEA
BMM
Worknet
Wikipedia
English dictionaries
DoDAF Glossary
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. International Defence Enterprise Architecture Specification (IDEAS) Relevance to DoDAF 2.0 Data Model

9. What Makes IDEAS Different ?
Foundation Layers
Foundation based on Set Theory
Traditional data modelling is generally not founded in mathematic principles
IDEAS uses formal set theoretic tools to accurately represent the structure of real-world concepts
Next – common patterns based on the foundation
Next – domain patterns that specialize the common patterns
BORO Methodology
Relies on the only thing that is irrefutable, the physical extent of something
All analysis is rooted in 4D spatio-temporal “individuals” that are instances-of Types
Naming Pattern
Allows separation of linguistics from semantics

10. Foundation Top Level Everything’s a Thing:
Individuals that have spatio-temporal extent
Types that are sets of Things
Tuples that relate Things in a specified manner (tuplePlaces)

11. Foundation: Key Objects in the Common Patterns for DoDAF 2.0
A special type of membership where a set is an element of a some other set (or class, to be more precise), e.g.,
The set of Government workers is an element of the set of worker types
Can be thought of as the way to say set membership, i.e., aÎ{A}
one tuplePlace points to the element
the other tuplePlace points to the set
Can be thought of a subset, e.g.,
F-18 (type) is a subset of the set of Fighter (type) is a subset of the set of Aircraft (type)
Means the 4D spatio-temporal extent of the Part is contained within the 4D spatio-temporal extent of the Whole

12. DoDAF 2. 0 Conceptual Data Model version 0
DoDAF 2.0 Conceptual Data Model version 0.1 Foundation and Sample Diagrams

13. Foundation Top-Level Foundation Elements:
Thing, similar to other model’s “object”
Individual, a “thing” that has spatio-temporal extent.
Type, a set of individuals or classes of other sets or classes
Tuple, ordered places of “things”
Common (Reuse) Patterns:
Composition (or whole-part)
Super/Sub Type (or generalization / specialization)
Before / After, for “things” that have temporal relationships in their Type
Interface, for “things” that can exchange other things that are parts of themselves
This is similar to many foundation ontologies such as SUMO or ISO Note that since most architecture data is Type data, not Individual data, the data elements are mostly generalized as Types.

14. Foundation Linkage to Domain

15. Capabilities and Metrics

16. Interfaces

17. Exchange Object Flow

18. Standards

19. Project

20. Next Refinement and completion
Coordination and feedback from other TWG’s
Spiral II Comments
Attributes
Trace to Core Process requirements
As mentioned on the GANNT chart, there is a lot of parallelism. So we’re still considering new sources, e.g., JACAE. You see the definitions are just proposed, although we did record the SWG member’s rationale for the selection or derivation.
You see we’re working on relationships.
At some point we need to define the relationships, just like everything else in the model. So when we make a relationship like “performs”, that term will be used consistently, we’ll know if it has any super or sub types, and we’ll know how it is distinct from, say, “supports”.
We will need to coordinate with the other TWG’s and consider new requirements from the remaining workshops: PPBE and DAS.

21. Backups

22. Sample EA Domain Patterns: Specialize from the Foundation

23. Rule

24. Activity

25. Performers (inc Systems, Services, and Applications)

26. Systems, Services, and Applications

27. Infrastructure

28. Goals