1. DoDAF-DM2 WG Orientation Brief
13 April 2011
DoDAF Development Team 1 1

2. Agenda DoDAF-DM2 WG history DoDAF-DM2 WG Objectives
Current DoDAF-DM2 WG Participants
DoDAF-DM2 WG Challenges
DoDAF-DM2 WG Way Ahead

3. Lay of DoDAF Land Model (view) specifications DM2 Operational
Capabilities
Services
Systems
Data and Information
Standards
Projects
DM2
Conceptual Data Model – very simple
Logical Data Model
Because of IDEAS there are only ~250 total data elements compared to the less-expressive CADM that had ~16,000!
Physical Exchange Specification is
Automatically generated from the LDM (an IDEAS plug-in, already paid-for)
Slightly-dumbed-down LDM in XML so if you know the LDM, PES is simple
PES tags and definitions are identical to DM2 LDM
No new structures are introduced other than XML-isms
The 52 DoDAF models and the DM2 are related via a matrix*
* 52 DoDAF models X 250 DM2 data elements, referred to as the “monster matrix” because it has ~ 13,000 decision cells

4. Views

5. Views

6. Views

7. Views

8. Views

9. 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
Backup slide has term definitions
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

10. DoDAF 2 Conceptual Data Model Terms
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.

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

12. DoDAF-DM2 WG history
DoDAF 2.0 development in was done via 3 technical working groups:
Presentation
Methods
Data
Data TWG methodology during DoDAF 2.0 development
Top-down from DoD’s six core processes and their information requirements collected as part of the requirements workshops
Bottoms-up from ~ two dozen existing data models
Business rules enabled great success – DM2 has only ~ 250 pieces compared to predecessor CADM’s ~ 16,000
DoDAF 2.0 publication in May 2009
Only Data TWG established a significant membership and meeting tempo and so it was a resource of opportunity to assume DoDAF configuration management recommendations

13. 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
CPM Process Information Requirements

14. Conceptual Data Model 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.

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

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

17. WG Business Rules Essential for Broad Community Consensus

18. DoDAF Must Relate to Core Processes
DRAFT
DRAFT

19. DoDAF Must Relate to Core Processes
DRAFT
DRAFT

20. DoDAF Must Relate to Core Processes
DRAFT
DRAFT

21. DoDAF Must Relate to Core Processes
DRAFT

22. DoDAF Must Relate to Core Processes
DRAFT

23. DoDAF Must Relate to Core Processes
DRAFT
DRAFT

24. DoDAF Must Relate to Core Processes
DRAFT
DRAFT

25. DoDAF Must Relate to Core Processes
DRAFT
DRAFT

26. DoDAF-DM2 WG Objectives

27. DoDAF-DM2 is under formal configuration control
Architecture Standards Review Group CONOPS
Roles, Responsibilities, and Processes
ASRG -- FOGO / SES level
Federated Architecture Council – 06 level
DoDAF and DM2 CM Plan
Configuration Identification
Organizational Roles, Responsibilities, and Interactions
CM Processes and Procedures
CM Business Rules
IN REVISION PER FAC DIRECTION

28. FAC is Small Formal Voting Body WG is Large & Collaborative
NSA AF
DoN
Army
Marine Corps
DISA
DISA
DISA
* Some C/S/A have multiple members
FAC – Voting – 23* votes
DoD CIO
DoDAF-DM2 Configuration Status Accounting Report (CSAR)
DoDAF-DM2 Baseline Status
DoDAF-DM2 WG Activity Summaries
COI Metrics and Progress Report
JFCOM
CR Technical Redirectoin •
CR Prioritization Redirectoin •
STRATCOM
JCS J6
DCMO
USD(I)
P&R
AT&L
DNI CIO
DoDAF-DM WG – Collaborative – Agreed-upon business rules enable analysis of different opinions
Framework Groups
OMG / INCOSE / NDIA
MODAF / NAF / TOGAF
FEA / FSAM
Core Process Stakeholders
CJCSI revs
AT&L SoSE & Acq Reform
Combatant Command architectures
CPM Governance
PA&E
Framework & Ontology Groups
OMG / INCOSE / NDIA
IDEAS / NAF
UCORE
Enterprise Vocabularies
400+ members + ~12 new each week
Meets bi-weekly
Vendors
EA/ITA Tool
M&S
Data Analysis
Repository
Data Integration
Data Exchange
Pilots
Early Adopters
Federation
COI Coordination Groups
DoD MDR WG
DoD COI Forum
To join, go to DoDAF 2.0 website

29. Bi-weekly WG Meetings Collaboration site Readaheads and notebooks
References folders
Discussion groups
CR Submission
Tools

30. Monthly Report to FAC Purposes: Action Item / Change Request Status
Full visibility of WG activities and plans
Opportunity for FAC re-direction
Technical
Prioritization
Action Item / Change Request Status
Configuration Status Accounting Report
Summary of WG activities
Change Request Summary
Detailed status of all open Change Requests

31. DoDAF-DM2 Change Request Processing
DRAFT
DRAFT

32. DoDAF CR Detailed Processing
DRAFT
TBD
DRAFT

33. DM2 CR Detailed Processing
DRAFT
DRAFT

34. DoDAF-DM2 Version Process
DRAFT

35. Current DoDAF-DM2 WG Participants
Over 450 members
Military, Government, Industry, Vendors, Academia, and professional organizations
Operators, architects, tool developers, repository operators, and data analysts
All FAC Components represented + IC
Monthly participants and full member list reported to FAC in monthly CSAR
Imminent tasker to Components to identify their WG representative(s)
Multiple reps will be OK, e.g., Navy could choose SPAWAR, NAVSEA, NAVAIR, OPNAV, and ASN RDA

36. DoDAF-DM2 WG Challenges
WG growth – from a dozen members to over 400, adding ~ 12 / week
A new member orientation package to be automatically sent upon registration is being developed
Separating material that needs to be controlled from that that doesn’t
E.g., “History of the DoDAF” probably does not warrant formal review by Components and control by the FAC
Conversely, the viewpoints/views and DM2 do
Cleanup of legacy text and focus of viewpoints/views towards six core processes
Wordsmithing is insufficient to resolve
Tools that will help: FEAF, Core Process information analyses, and DM2 disambiguation power

37. DoDAF-DM2 WG Way Ahead ASRG & FAC Governance to be updated
FAC Component reps formal tasker soon to be issued
Version tempo to slow to annual or semi-annual
Versions will go through review by Components by formal tasker
Predicted future CR sources:
Coordination with FEAF, JARM, and CUDEAF
Core process initiatives, e.g., IT Acquisition Reform

38. DoD Architectures COI WG is being considered
DRAFT
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
DRAFT

39. Welcome! We look forward to your participation.