1. Walkthrough DoDAF 2.0 Meta Model (DM2) TBD 20 March 2009 VERSION 15
4/27/ :51
DoDAF 2.0 Meta Model (DM2)
Walkthrough
TBD
20 March 2009

2. Briefing Outline Background Why an EA meta model?
History and Lessons Learned
So – DM2 Methodology
Walkthroughs:
Conceptual Data Model
Logical Data Model
Physical Exchange Specification
How to get engaged

3. Background

4. DoDAF 2 Goals Support the department’s 6 core processes:
Capabilities Integration and Development (JCIDS)
Acquisition System (DAS)
Budgeting and Planning (PPBE)
Systems Engineering
Operations Planning
Capabilities Portfolio Management (CPM)
Establish guidance for architecture content as a function of purpose – “fit for purpose” (see cover logo)
Increase precision of architectures by defining architectures principally in terms of data with diagrams (presentations) related to the data – the DoDAF Meta Model (DM2)

5. DoDAF Meta Model (DM2) Purposes:
The vocabulary for description and discourse about DoDAF models (formerly “products”) and core process usage
The basis for generation of the “physical” exchange specification for exchange of data between architecture tools and databases.
Supports discovery and understandability of architecture datasets:
Discovery thru abstraction levels and super-subtype taxonomies
Understandability thru precise semantics augmented with linguistic traceability
Form:
VOLUME I, DoDAF Conceptual Data Model (CDM)
Core concepts, definitions (with examples, sources, aliases)
Relationships (with some typing)
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 (made explicit) added
VOLUME III, DoDAF Physical Exchange Specification (PES)
The Logical Data Model generated as a set of XSD’s, one schema per model (product) described in Volume II.

6. Volume II Organization
Vol II
Perspectives
Metamodel Data Groups
Views
 Metamodel Data Groups
Performer
Resource Flow
Information & Data
Activity
Training / Skill / Education
Capability
Services
Project
Goals
Rules
Measures
Location
x.y.1 Data – what are the concepts and how are they related
Diagram and definitions from DM2
Discussion
x.y.2 Method – how is such information collected and assembled
x.y.3 Usage in Core Processes – how is such information used in budgeting, acquisition, capabilities integration and development, systems engineering, capabilities portfolio management, and operations planning
x.y.4 Presentation – what are the ways this information can be presented
for each:

7. Team and Weekly Sessions
Collaboration Site:
pre- & post- meeting updates
UML file
Excel file (defs and AI’s)
HTML version of UML file
Reference and Research folders updated as material is submitted

8. Coordination with many related activities
Examples:
OMG UPDM & SYSML teams
DM2 Coordination with teams in mutual telecons, OMG meetings, …
BTA Primitives and Lexicon
Core Enterprise Services – to – Tactical Edge (CES2TE)
ASN RDA and JFCOM Modeling and Simulation
JTEM
DoD MDWG
SPAWAR / ASN RDA Naval Architecture Elements Requirements Group (NAERG)
JFCOM JACAE – MCSC MACAE – TRADOC AMID
MODAF and NAF (via IDEAS)
DoDAF Plenary, Vendor’s Days, and weekly data model telecons
UPDM “architect” access to DM2 workgroup site with weekly updates
Comment acceptance into working group system
UPDM Team Coordination with DoDAF
UPDM weekly telecons, OMG technical meetings, and UPDM “face-to-face” meetings
Regular distribution of UPDM “Domain Meta Model”
Their DoDAF baseline is 1.5 but they want the “heads-up” on 2.0 to better support the UPDM mod for DoDAF 2 when it is finalized

9. Conceptual Data Model

10. Conceptual Data Model Version 0.1 Process
12/3
Strawman – list of important or recurring “core” words/terms/concepts with source definition(s)
3/3
CDM version 0.1
Concepts (defined)
Relationships (some typing, e.g., super/sub, cardinality)
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", ...)
1. Overviews of Models
2. Collect the terms
3. Make a pass on the “Core” Terms
4. Gather authoritative definitions for “Core” 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
6. Proposed definitions (+rationale, examples, and aliases)
7. Relationships
8. Relationship Types
5. Group related terms
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.

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

12. Key Concepts

13. A Project consists of several or many Activities (e.g., Tasks) 1 2 3 4 5 6 7 8 9 10 11 12 13 15 14 16 17 18 19 20 21 22 23 27 24 25 26 28
The blue triangle-headed lines are read, “type-of” from bottom to top, e.g, “a System is a type-of Performer”
The associations between the concepts, are as follows, keyed to the footnote numbers from top to bottom and left to right:
Measurements are done in accordance with Rules, e.g., Rules that specify how test measurement equipment must be calibrated before a test
Certain types of Measures apply to an Activity, e.g., how long it takes. This feature was part of the IDEF0 specification.
A Project consists of several or many Activities (e.g., Tasks)
Measures can be categorized into Measure Types
There are Measures associated with a Project (e.g., time, cost)
Activities are performed in accordance with Rules (e.g., Controls in IDEF0)
A Project has Desired Effects (e.g., goals)
Desired Effects (e.g., goals) guide / drive Activities
Visions are realized by Desired Effects (e.g., objectives)
Desired Effects are Measureable; otherwise there would be no way to know they were achieved. This statement implies a measure can be constructed for all Desired Effects.
A Rule applies to an Activity under certain Conditions, e.g., Rules of Engagement may vary dependent on threat Conditions
An Activity is performable under certain Conditions, e.g., the Conditions applicable to Tasks in the UJTL
The performance of Activities under certain Conditions has Measures, e.g., the Measure Types applicable to Tasks (Activities) in the UJTL
Capabilities have Desired Effects, as so stated in the CJCSI 3170
A Capability entails performance of Activities (Tasks) , as so stated in the CJCSI 3170
The performance of Activities as part of a Capability is done under certain Conditions, , as so stated in the CJCSI 3170
The performance of those Activities as part of a Capability have Measures (metrics) for their performance, as so stated in the CJCSI 3170
A Condition has metrics (Measures)
An Activity is performed by a Performer under certain Conditions
Performers perform Activities. This characteristic distinguishes Performers from their superclass, Resources
The performance of Activities by Performers is subject to Rules. Even though Rules constrain Activities, there may be tailoring for the performance of those Activities by specific Performers
The performance of Activities by Performers is subject to Measures. Activities can have Measures in and of themselves; however there can be additional or tailored Measures associated with the performance of those Activities by specific Performers
An Activity consumes or produces Resources. Those Resources can be Materiel, Information , Data, Geo-Politcal, or other Performers. When the production and consumption is of Information or Data, the DoDAF 1.5 OV-3, OV-5, SV-4, SV-6, and others are partially represented.
The consumption or production of Resources by Activities is subject to Rules, e.g., the Information Assurance Rules that are part of the OV-3
The consumption and production of Resources by Activities is measureable, e.g., the Timeliness and Size measures that are part of the OV-3
Activities result in effects on Effect Objects (Resources), i.e., a cause-effect chain.
The effect on Effect Objects by Activities is measureable
A Capability is realized by one or more Performers (including configurations of Performer)
A Resource has Measures, e.g., mass, size.
Performers perform at Locations
The Skills of a Person Type are measureable, e.g., as in Skill level of a Person Type.
Person Types have Skills
Information describes some Thing
Information Pedigree is a type of Information that describes the production of Information (resources) by Activities, their Performers, and the Rules, Conditions, and Measures that apply to that information production
A Person Type can be part of a System, e.g., a radar operator or, more generally, in a cybernetic sense
A Service provides access to Performers. This results from the DoD definition of Service which is verbatim from OASIS
Materiel can be part of a System, the parts and equipment that are part of a System 29 30 31 32 33 34 35 36
Person Type 37

14. Conceptual Data Model – Foundation Elements
Everything in the EA Domain inherits from the foundation
Examples:
System A1 (part) wholePart System A (whole)
Activity A (before) beforeAfter Activity B (after)
Capability Increment temporalWholePart of Capability
Organization typeInstance Organization Type
Location A overlap Location B
System (subtype) superSubType System (supertype)

15. Logical Data Model

16. Modeling Principles
Model Core Process (PPBE, DAS, JCIDS, CPM, SE, Ops) business objects
Terms enter model through thorough semantic research:
Assignment to a researcher
Collection of authoritative definitions, documenting source
Assessment of redundant (alias) or composite terms
Formulation / selection of definition based on authoritative definitions
Examples
Outbrief to team
Recording of research and decision rationale
No need to distinguish / label concepts that differ only in level of aggregation – e.g., subfunction – function. Whole-part relationship covers the need without different names for different types of wholes and parts. When a user has need to label, the naming pattern accommodates.
Typed Relationships, e.g., using IDEAS
No commitment to an implementation type. Support RDBMS, XSD, Java, etc. from core model
Goal is a core that can be extended by user communities, not to try to cover all user detail. Extenders should be careful to not create redundant representations.
Model will enter a CM process

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

18. Definitions and Aliases Record Excerpt
PRE-DECISIONAL WORKING DRAFT
Definitions and Aliases Record Excerpt
PRE-DECISIONAL WORKING DRAFT

19. Definitions and Aliases Record Excerpt
PRE-DECISIONAL WORKING DRAFT
Definitions and Aliases Record Excerpt
PRE-DECISIONAL WORKING DRAFT

20. Leveraged IDEAS for Formal Foundation
IDEAS is more than OWL:
Based on mathematics
set & 4D meronymy theory
Deals with issues of states, powertypes, measures, space -- what is truly knowable vs. what is assumed
Domain concepts are extensions to the formal foundation
Rigorously worked-out common patterns are reused
Saved a lot of repetitive work – “ontologic free lunch”
Result is higher quality and consistency throughout

21. BORO book is downloadable from DM2 site

22. Why Formal Ontology? Corresponds to the real world being modeled:
Physical objects that have parts, can be aggregated into larger wholes – both spatially and temporally
The parts don’t have to be contiguous, e.g., parts of a squadron
The objects have a lifetime (temporal extent) that can be broken into temporal states
Only one object can occupy the same spatio-temporal extent
Examples:
Things are categorized
Multiply
Categorization should follow the rules to set theory, e.g.,

23. Why Formal Ontology (cont’d)
Why is this better? “is-a” example:
Not mathematically rigorous:
More precise:
“Has” – the basis of fields and attributes is flawed too
Does this really matter – all the time – fouls queries, analysis algorithms, and interoperability
Why did this happen? Database design had in origins in form automation, not mathematical analysis – good for storing stuff to be processed by humans – terrible for automated processing as in data fusion

24. Diagram Conventions and Use of UML
The IDEAS Model has been developed using a UML Profile. The IDEAS Foundation specifies the fundamental types that define the profile stereotypes. The following stereotyped classes, with their colour-coding are used in the model:
<<Individual>> An instance of an Individual - something with spatio-temporal extent [Black]
<<Type>> The specification of a Type [Cyan]
<<IndividualType>> The specification of a Type whose members are Individuals [Orange]
<<TupleType>> The specification of a Type whose members are tuples [Green]
<<Name>> The specification of a name, with the examplar text provided as a tagged value [Light Yellow]
<<NameType>> The specification of a Type whose members are names [Dark Yellow]
The following stereotyped relationships are used in the model:
<<typeInstance>> a relationship between a type and one of its instances (UML:Dependency) [Red]
<<powertypeInstance>> a relationship between a type and its powerset (UML:Dependency) [Dark Red]
<<nameTypeInstance>> a relationship between a name and its NameType (UML:Dependency) [Red]
<<superSubtype>> a relationship between a type and one of its subtypes (UML:Generalisation) [Blue]
<<wholePart>> a relationship between an individual and one of its parts (UML:Aggregation) [Dark Green]
<<tuple>>/<<couple> a relationship between a things (UML:n-ary relationship diamond) [White]

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

26. DoDAF Domain Concepts are Specializations
Next slide is a zoom-in

27. Sample zoom-in

28. There are some common attributes too
Everything has a classification marking – a “portion mark”
Everything has a pedigree – who, how,… it came into being
Names (formal, nick, acronym, ID / UID / GUID, etc.) done via naming pattern (an association). Very flexible allowing multiple names, typed by NameType.
Descriptions too.
Time periods via Measure model.

29. Naming and Description Pattern
For example, NameType = Mil-Std 6016, Mil-Std 2525, Nickname, GUID, …
For example, InformationType = “to-be architecture description”, “as-is architecture description”

30. Capability Oriented towards Desired Effects (measurable)
Manifested by Performers (including Performer configurations – remember whole-part)
Activities, Rules, Conditions, …

31. Activity

32. Performer
System – defined generally (i.e., not just a DoD Program of Record)
Can include humans
Animals too
At a location
Tied to Measures

33. Resource Flow Not just information and data (e.g., IER and SV-6)
Materiel, Personnel Type (training, the “T” and “L &e” in DOTMLPF), other Performers (e.g., in the Project views)
The Activity does the production and consumption, not the Performer, even if you choose not to show the Activities on a diagram
Measures and Rules apply throughout

34. IER “Matrix” in this Conceptualization

35. Goals

36. Rules

37. Measure All kinds of measures and metrics
The measure values are related to measure types, e.g., BAUD, max speed, probability of kill, accuracy, …
Those measure types have rules associated with them, e..g, the rule that Target Location Error is a 90% probability area

38. Activity Model in this Conceptualization
Measures and metrics
Performer A
Performer B
Activity 1A
Activity 1B
Resources
a, b, c
Resources
x, y, z
Activity 11A
Activity 11B
Performers to which applicable
Conditions in which applicable
Rules, constraints, standards, …

39. Location Not trying to re-create GML
Addresses are ways to get to physical locations, e.g., a URL gets you to a server, a postal address gets you to a mailbox
There NameTypes for Address names, e.g., “postal”, “URL”, “TADIL link address”, etc.

40. Information and Data
Information describes something; things can have multiple descriptions, e.g., by different sources, by different times, by different levels of detail
No intent to replicate a full metamodel – that would be in the DoD Metadata Registry
This is for support of the 6 core processes

41. Services Not just software, also business
OASIS definition adopted by DoD
Services are self describing
Service users interact with the accessed Performers via the Service Port
Rules (service policies, contracts)
Measures (QoS)

42. Project Presentation TWG recommended – based on NAF
Can be any kind of project, not just acquisition
Can be used as architecture metadata to describe the architecture project, i.e., structured AV-1

43. Information Pedigree
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

44. Physical Exchange Specification

45. Physical Exchange Specification
XSD’s
One per DoDAF model (52) with necessary and optional parts
1 comprehensive with all optional for “fit for purpose” models
2 reference – IDEAS Foundation and Security
Basic structure:
Wrapper, describing that the document is
Naming and aliases for independent entities
Associations

46. Mapping of Models Basis for XSDs
PRE-DECISIONAL WORKING DRAFT
Mapping of Models Basis for XSDs
In DoDAF Vol II
PRE-DECISIONAL WORKING DRAFT

47. DM2 Provides a Neutral Exchange Specification for Many Kinds of Architecture Data
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

48. PES
XSD
XML
Architecture
Data Files
Does not exist yet
XMI
SysML

49. OV-5b Necessary and Optional Data Elements

50. OV-5b XSD

51. OV-3 Necessary and Optional Data Elements

52. OV-3 XSD

53. Pilots Just started: JFCOM JACAE – MCSC MCAE – TRADOC AMID NAERG
OPNAV N6 “dashboard”
EISP
Candidates:
UCORE
IDEAS Coalition
UPDM 2

54. Where to learn more Join the Data TWG Share site for:
Baseline and working copy of models (CDM, LDM, PES)
IDEAS Foundation model
Lots of Reference and Research folders
Links to IDEAS, BORO
Weekly message with invitation to participate in DCO telecon
Stay in touch with ongoing evolution, pilots, and Configuration Management activities

55. Questions?

56. Training / Skill / Education

57. Security
This is the Intel Community Information Security Markings (IC-ISM, pronounced icky-sim.) We lifted from UCORE 1.1.

58. XSD’s are generated from UML model