1. DoDAF Meta Model (DM2) Update -- Version 2.01
26 February 2010
DAVE MCDANIEL
Contractor, Enterprise Architecture & Standards
Office of the DoD Deputy Chief Information Officer +1 (619) 1

2. Outline of Presentation
Recap of DM2
DM2 Configuration Management (CM) Process
What’s improved in DM2 2.01
DM2 Adoption and Implementation Status
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.

3. DM2 Recap

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

5. (see “DM2 CDM Description document” for definitions)
CDM (DIV-1) Graphic
23 (+ 24 &25)
20 (+ 21 & 22) 30 1 2 3 4 5 7 6 8 9 18 10 11 13 15 12 16 17 20 19 22 14 21 24 23 25 26 27 28 29 31 32 33 34 36 35 37
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.
Person Type
(see “DM2 CDM Description document” for definitions)

6. LDM (DIV-2) Sample Graphic

7. Physical Exchange Schema (PES) (a form of DIV-3) Sample

8. Where is the DM2 DoD Meta Data Registry (MDR)1 DoDAF Web Site
DM2 Collaboration Site2
. working copy of the DM2 is maintained on a TWG collaboration site, along with all reference and research materials and the current action item tracker.
ARCH namespace. ARCH namespace has CDM (eap and xmi), LDM (eap, xmi, and xls), and PES (xsd’s). Can be accessed via DoD EA COI.

9. The DM2 is under Configuration Management (CM) by the DM2 WG
DM2 WG has three responsibilities1:
Configuration Management (CM) of the DM2
Data management for the DoD EA COI
Review of architectural descriptions for suitability for federated data exchange
The DM2 WG meets every Friday and has over 180 members
1. ASRG Management Plan

10. DM2 Configuration Management
FAC
DM2 CRs
COI Guidance
Architectural Description Review Tasks
DM2 Baseline Release Direction
DM2 CSAR
COI Metrics and Progress Report
Architectural Description Reviews
DM2 Baseline Release Request and Status
DM2 WG
Govt
Military
Industry
Academia
vendors
DoDAF WG
DARS WG
Referred CRs
Referred CRs
COI Coordination Groups
DoD MDR WG
DoD COI Forum
Vendors
EA/ITA Tool
M&S
Data Analysis
Repository
Data Integration
Data Exchange
Pilots
Early Adopters
Federation
Framework & Ontology Groups
OMG / INCOSE / NDIA
IDEAS / NAF
UCORE
Enterprise Vocabularies
Core Process Stakeholders
CJCSI revs
AT&L SoSE & Acq Reform
Combatant Command architectures
CPM Governance
PA&E

11. Outreach and Tutorial DM2 Description Documents and Briefings

12. What’s improved in 2.01 Many minor model updates
Stereotypes, definitions, cardinalities, etc.
Desired Effect structure
Design reification and requirements traceability
International Defence Enterprise Architecture Specification (IDEAS) alignment
We were developing the IDEAS Foundation, version 1.0, and DM2 in parallel and so there were a few disconnects.
XML Schema Description (XSD) Format
Only 1 XSD to implement, instead of 52!
(two others with foundation metadata and one with IC-ISM)
Beginning absorption of latest OASIS & Object Management Group (OMG) SoA concepts

13. Desired Effect structure

14. Levels of Abstraction – (reifications) 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
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
Rules
constrain
Rules
constrain
Rules
constrain
constrain
constrain
Worker
Technician
Engineer
Architect
Executive
Strategic
Op Rqmt TLR SLR A-Spec/SSS B-Spec/SSDS C-Specs/SRS
JCD
time
IOC
Got this one for free!

15. IDEAS Recap - Top-Level Foundation
Developed by an international group of computer scientists, engineers, mathematicians, and philosophers under defense sponsorship.
See or
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.

16. XSD format

17. XSD format

18. XSD format

19. Beginning absorption of latest OASIS & OMG SoA concepts
From OASIS SoA RAF

20. Relationship Between Action and Service Description

21. Service Descriptions
So a Service Description can have all the structure of an Architectural Description
Activities
Before-After
Rules
Conditions
Data structures
Locations
Dependencies
Etc.

22. DoDAF 2 Exemplars What are they How are we doing them
Collections of architectural views and their corresponding DM2 PES XML document examples
From coherent datasets, e.g., UPDM S&R, NCES ISP
How are we doing them
DoDAF Journal
DoDAF Outreach Brief - Views
Discuss Candidate Datasets with Process Owners
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

23. Adoption and Implementation Status

24. Tool Vendors
Unified Profile for MODAF and DoDAF (UPDM)1 (see next slide)
Joint working sessions:
DM2 participation in OMG Technical Meeting UPDM sesssions
UPDM Team participation in DM2 WG
Ongoing Plan:
Map UPDM Domain Meta Model (DMM) to/from DM2
Use to develop DM2 PES generator / exporter
Test and validate DM2 PES XML documents so generated
Other vendors2
DoDAF Team briefings and DM2 PES conformance
DM2 meetings
Comment and question submissions
Tool vendor members: Adaptive (Adaptive Metadata Manager, Adaptive IT Portfolio Manager, Artisan (Artisan Studio), ASMG (mdPortal, mdParser, mdBrowser), Embedded Plus Engineering UPDM Toolkit (for IBM RSDP), IBM (Telelogic SA, Rhapsody, RSA), No Magic (MagicDraw), Sparx Systems (Enterprise Architect),
MetaStorm (ProVision), IBM (RSA, System Architect, Rhapsody), Artisan (Artisan Studio), MicroFocus (Borland Together), ViTech (CORE), METRON (Naval Simulation System), Siemens (TeamCenter), Enterprise Elements, Salamander (MooD), Sybase (PowerDesigner), QualiWare (QualiWare Enterprise Architecture), IDS Sheer (ARIS), alfabet (planningIT), MicroFocus (Borland Together), Casewise (Corporate Modeler), Mega (Mega Suite), Troux (Troux Architect). (Other interested vendors please contact Mike Wayson,

25. DoDAF 2 Conformance: DM2 PES is the Neutral Standard
Interoperability Layers
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

26. DM2 / DoDAF Testing Levels

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

28. Implementation
JFCOM Joint Integrated Architectures Working Group (JIAWG) Federation Sub Working Group (SWG)
Enhanced ISP (EISP)
Naval Architecture Repository System (NARS) / Naval Architecture Elements Reference Guide (NAERG)
DM2 Database used for exemplar generation
Universal Core (UCORE)1 Coordination
EA data exchange between DoD – IC – DHS – DoJ
Formal ontology 1.

29. Questions