dodaf-dm2 wg orientation brief 13 april 2011 dodaf development team

DoDAF-DM2 WGOrientation Brief

13 April 2011

DoDAF Development Team

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

1. Model (view) specifications• Operational• Capabilities• Services• Systems• Data and Information• Standards• Projects

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

* 52 DoDAF models X 250 DM2 data elements, referred to as the “monster matrix” because it has ~ 13,000 decision cells

OPS DAS SE CPMJCIDS PPBE

Capabilities

Services

Performers

Resource Flows

Rules Reification

Projects

PedigreeLocations

OperationalOperational

Temporal Parts, Boundaries, Before-

After

Sum, Fusion, Union, Intersection,

Partition, & Disjoint

Naming & Description

Parts and overlaps

Type instances, super-subtypes, &

powertypes

Properties & Measures

4-D Mereotopology Set Theory

Temporal Parts, Boundaries, Before-

After

Sum, Fusion, Union, Intersection,

Partition, & Disjoint

Naming & Description

Parts and overlaps

Type instances, super-subtypes, &

powertypes

Properties & Measures

4-D Mereotopology Set Theory

Process Supported

Views

Data

Ontology

FFP Legacy

4

ViewsModels Descriptions Models Descriptions

AV-1 : Overview and Summary Information

Scope, purpose, intended users, environment depicted, analytical findings

AV-1: Overview and Summary Information

Describes a Project's Visions, Goals, Objectives, Plans, Activities, Events, Conditions, Measures, Effects (Outcomes), and produced objects.

AV-2 : Integrated Dictionary Architecture data repository with definitions of all terms used in all products

AV-2: Integrated Dictionary

An architectural data repository with definitions of all terms used throughout the architectural data and presentations.

CV-1: VisionThe overall vision for transformational endeavors, which provides a strategic context for the capabilities described and a high-level scope.

CV-2: Capability Taxonomy

A hierarchy of capabilities which specifies all the capabilities that are referenced throughout one or more Architectural Descriptions.

CV-3: Capability Phasing

The planned achievement of capability at different points in time or during specific periods of time. The CV-3 shows the capability phasing in terms of the activities, conditions, desired effects, rules complied with, resource consumption and production, and measures, without regard to the performer and location solutions.

CV-4: Capability Dependencies

The dependencies between planned capabilities and the definition of logical groupings of capabilities.

CV-5: Capability to Organizational Development Mapping

The fulfillment of capability requirements shows the planned capability deployment and interconnection for a particular Capability Phase. The CV-5 shows the planned solution for the phase in terms of performers and locations and their associated concepts.

CV-6: Capability to Operational Activities Mapping

A mapping between the capabilities required and the operational activities that those capabilities support.

CV-7: Capability to Services Mapping

A mapping between the capabilities and the services that these capabilities enable.

DIV-1:Conceptual Data Model

The required high-level data concepts and their relationships.

PV-1: Project Portfolio Relationships

It describes the dependency relationships between the organizations and projects and the organizational structures needed to manage a portfolio of projects.

PV-2: Project TimelinesA timeline perspective on programs or projects, with the key milestones and interdependencies.

PV-3: Project to Capability Mapping

A mapping of programs and projects to capabilities to show how the specific projects and program elements help to achieve a capability.

DoDAF 1.5 DoDAF 2.02

5

Views

Models Descriptions Models DescriptionsTV-1: Technical Standards Profile

Listing of standards that apply to Systems and Services View elements in a given architecture

StdV-1 Standards Profile

The listing of standards that apply to solution elements.

TV-2 : Technical Standards Forecast

Description of emerging standards and potential impact on current Systems and Services View elements, within a set of time frames

StdV-2 Standards Forecast

The description of emerging standards and potential impact on current solution elements, within a set of time frames.

OV-7 : Logical Data Model Documentation of the system data requirements and structural business process rules of the Operational View

DIV-2: Logical Data Model

The documentation of the data requirements and structural business process (activity) rules. In DoDAF V1.5, this was the OV-7.

SV-11: Physical SchemaPhysical implementation of the Logical Data Model entities, e.g., message formats, file structures, physical schema

DIV-3: Physical Data Model

The physical implementation format of the Logical Data Model entities, e.g., message formats, file structures, physical schema. In DoDAF V1.5, this was the SV-11.


6

Views

Models Descriptions Models DescriptionsOV-1 : High-Level Operational Concept Graphic

High-level graphical/textual description of operational concept

OV-1: High-Level Operational Concept Graphic

The high-level graphical/textual description of the operational concept.

OV-2 : Operational Node Connectivity Description

Operational nodes, connectivity, and information exchange need lines between nodes

OV-2: Operational Resource Flow Description

A description of the Resource Flows exchanged between operational activities.

OV-3 : Operational Information Exchange Matrix

Information exchanged between nodes and the relevant attributes of that exchange

OV-3: Operational Resource Flow Matrix

A description of the resources exchanged and the relevant attributes of the exchanges.

OV-4 : Organizational Relationships Chart

Organizational, role, or other relationships among organizations

OV-4: Organizational Relationships Chart

The organizational context, role or other relationships among organizations.

OV-5a: Operational Activity Decomposition Tree

The capabilities and activities (operational activities) organized in a hierarchal structure.

OV-5b: Operational Activity Model

The context of capabilities and activities (operational activities) and their relationships among activities, inputs, and outputs; Additional data can show cost, performers, or other pertinent information.

OV-6a : Operational Rules Model

One of three products used to describe operational activity-identifies business rules that constrain operation

OV-6a: Operational Rules Model

One of three models used to describe activity (operational activity). It identifies business rules that constrain operations.

OV-6b : Operational State Transition Description

One of three products used to describe operational activity-identifies business process responses to events

OV-6b: State Transition Description

One of three models used to describe operational activity (activity). It identifies business process (activity) responses to events (usually, very short activities).

OV-6c : Operational Event-Trace Description

One of three products used to describe operational activity-traces actions in a scenario or sequence of events

OV-6c: Event-Trace Description

One of three models used to describe activity (operational activity). It traces actions in a scenario or sequence of events.

DoDAF 1.5

OV-5 : Operational Activity Model

Capabilities, operational activities, relationships among activities, inputs, and outputs; overlays can show cost, performing nodes, or other pertinent information

DoDAF 2.02

7

Views

Models Descriptions Models DescriptionsSvcV-1 Services Context Description

The identification of services, service items, and their interconnections.

SvcV-2 Services Resource Flow Description

A description of Resource Flows exchanged between services.

SvcV-3a Systems-Services Matrix

The relationships among or between systems and services in a given Architectural Description.

SvcV-3b Services-Services Matrix

The relationships among services in a given Architectural Description. It can be designed to show relationships of interest, (e.g., service-type interfaces, planned vs. existing interfaces).

SV-4b : Services Functionality Description

Functions performed by services and the service data flow among service functions

SvcV-4 Services Functionality Description

The functions performed by services and the service data flows among service functions (activities).

SV-5c : Operational Activity to Services Traceability Matrix

Mapping of services back to operational activities SvcV-5 Operational Activity to Services Traceability Matrix

A mapping of services (activities) back to operational activities (activities).

SvcV-6 Services Resource Flow Matrix

It provides details of service Resource Flow elements being exchanged between services and the attributes of that exchange.

SvcV-7 Services Measures Matrix

The measures (metrics) of Services Model elements for the appropriate time frame(s).

SvcV-8 Services Evolution Description

The planned incremental steps toward migrating a suite of services to a more efficient suite or toward evolving current services to a future implementation.

SvcV-9 Services Technology & Skills Forecast

The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future service development.

SvcV-10a Services Rules Model

One of three models used to describe service functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation.

SvcV-10b Services State Transition Description

One of three models used to describe service functionality. It identifies responses of services to events.

SvcV-10c Services Event-Trace Description

One of three models used to describe service functionality. It identifies service-specific refinements of critical sequences of events described in the Operational Viewpoint.


8

ViewsModels Descriptions Models Descriptions

SV-1 : Systems Interface DescriptionServices Interface Description

Identification of systems nodes, systems, system items, services, and service items and their interconnections, within and between nodes

SV-1 Systems Interface Description

The identification of systems, system items, and their interconnections.

SV-2 : Systems Communications DescriptionServices Communications Description

Systems nodes, systems, system items, services, and service items and their related communications lay-downs

SV-2 Systems Resource Flow Description

A description of Resource Flows exchanged between systems.

SV-3 : Systems-Systems MatrixServices-Systems MatrixServices-Services Matrix

Relationships among systems and services in a given architecture; can be designed to show relationships of interest, e.g., system-type interfaces, planned vs. existing interfaces, etc.

SV-3 Systems-Systems Matrix

The relationships among systems in a given Architectural Description. It can be designed to show relationships of interest, (e.g., system-type interfaces, planned vs. existing interfaces).

SV-4a : Systems Functionality Description

Functions performed by systems and the system data flows among system functions

SV-4 Systems Functionality Description

The functions (activities) performed by systems and the system data flows among system functions (activities).

SV-5a : Operational Activity to Systems Function Traceability Matrix

Mapping of system functions back to operational activities

SV-5a Operational Activity to Systems Function Traceability Matrix

A mapping of system functions (activities) back to operational activities (activities).

SV-5b : Operational Activity to Systems Traceability Matrix

Mapping of systems back to capabilities or operational activities

SV-5b Operational Activity to Systems Traceability Matrix

A mapping of systems back to capabilities or operational activities (activities).

SV-6 : Systems Data Exchange MatrixServices Data Exchange Matrix

Provides details of system or service data elements being exchanged between systems or services and the attributes of that exchange

SV-6 Systems Resource Flow Matrix

Provides details of system resource flow elements being exchanged between systems and the attributes of that exchange.

SV-7 : Systems Performance Parameters MatrixServices Performance Parameters Matrix

Performance characteristics of Systems and Services View elements for the appropriate time frame(s)

SV-7 Systems Measures Matrix

The measures (metrics) of Systems Model elements for the appropriate timeframe(s).

SV-8 : Systems Evolution DescriptionServices Evolution Description

Planned incremental steps toward migrating a suite of systems or services to a more efficient suite, or toward evolving a current system to a future implementation

SV-8 Systems Evolution Description

The planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation.

SV-9 : Systems Technology ForecastServices Technology Forecast

Emerging technologies and software/hardware products that are expected to be available in a given set of time frames and that will affect future development of the architecture

SV-9 Systems Technology & Skills Forecast

The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future system development.

SV-10a : Systems Rules ModelServices Rules Model

One of three products used to describe system and service functionality-identifies constraints that are imposed on systems/services functionality due to some aspect of systems design or implementation

SV-10a Systems Rules Model

One of three models used to describe system functionality. It identifies constraints that are imposed on systems functionality due to some aspect of system design or implementation.

SV-10b : Systems State Transition Description Services State Transition Description

One of three products used to describe system and service functionality-identifies responses of a system/service to events

SV-10b Systems State Transition Description

One of three models used to describe system functionality. It identifies responses of systems to events.

SV-10c : Systems Event-Trace DescriptionServices Event-Trace Description

One of three products used to describe system or service functionality-identifies system/service-specific refinements of critical sequences of events described in the Operational View

SV-10c Systems Event-Trace Description

One of three models used to describe system functionality. It identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint.


9

Conceptual Level of DM2 is Simple

anything can have Measures

Guidance

Rule

Standard Agreement

Activity

Resource

PerformerSystem

Service

Organization

PersonRole

Materiel

Information

Data

Capability

Project

Location

GeoPolitical

Condition

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

is-performable-under

requires-ability-to-perform

achieves-desired-effect (a state of a

resource)

is-part-of

describes-something

is-at

consumes-and-

produces

has

is-the-goal-of

constrains

is-performed-

by

is-realized-by

Backup slide has

term definitions

Backup slide has

term definitions

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 StructurePlanned for future interoperability

with IDEAS

• 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”.

Architecture data – tag names and definitions are exactly from DM2 LDM

Extra goodies for Dublin Core (optional)

Packaging, e.g., overall classification marking

XML stuff -- unimportant

Screen-scrape of the actual PES XSD

Screen-scrape of the actual PES XSD

This could be made optional

This could be made optional

12

DoDAF-DM2 WG history

• DoDAF 2.0 development in 2008-2009 was done via 3 technical working groups:

1. Presentation2. Methods3. 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 DevelopmentCOI1

COIn

CO

I C

oo

rdin

atio

n

PPBE Process Information

Requirements

JCIDS Process Information

RequirementsOps Planning

Process Information

Requirements

SE Process Information

Requirements

DoD Core Process Information Requirements Collection

UCORE

DAS Process Information

RequirementsCPM Process Information

Requirements

14

Case

Meronymic Classification

Ontology Relationship

Types

DependencyInfluence

Spatial

Temporal

12/3Strawman – list of important or recurring “core” words/terms/concepts with source definition(s)

3/3CDM version 0.11. Concepts (defined)2. Relationships (some

typing, e.g., super/sub, cardinality)

1/3Partial Draft – proposed definitions, some harmonization (e.g., via super/subtyping, determining aliases)

2/3Interim Draft – Initial relationships (e.g., "performs", "part-of", ...)

1. Overviews of Models 2. Collect the terms3. Make a pass on the “Core” Terms

4. Gather authoritative definitions for “Core” terms

1 = Core, critical to process or very common in architectures2 = Derived or less common3 = TBD4 = TBD5 = TBD 5

432

1

6. Proposed definitions (+rationale, examples, and aliases)

7. Relationships8. Relationship Types

5. Group related terms

Conceptual Data Model Process

15

Sources

Modelsa. CADM 1.5b. IDEASc. UPDMd. BMMe. Hay/Zachmanf. ASMg. CRISh. Conceptual CADM in DoDAF 1.0 /

prototype CADM 2.0i. M3j. NAF Meta Modelk. DoI Meta Modell. JC3IEDMm. GMLn. UCORE 1.1o. GEIA 927p. AP233q. SUMO and ISO 15926 (via IDEAS)r. FEA Reference Modelss. JFCOM JACAE

Definitions1. IEEE2. ISO3. W3C4. OMG5. EIA6. DODD & DODI7. JCS Pubs, especially CJCSI's8. Models in the

Source_Candidates_071115.ppt9. DoDAF10.Other frameworks: Zachman,

MODAF, TOGAF, NAF, ...11.FEA12.BMM13.Worknet14.Wikipedia15.English dictionaries16.DoDAF Glossary

16

Definition Phase Example 1

Category Capability

Technical Term Capability

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 5025.12, 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

ConsensusRule Name Description

Terms and Definitions All model and alias terms proposed for inclusion in the data dictionary shall be researched for multiple source definitions. DoD definitions shall be included. Other Federal Government, industry and academic and common definitions should also be included. The WG shall formulate a baseline definition based on the multiple sources, core process requirements, and model structural meaning. The source definitions and the rationale for the baseline definition shall be maintained in the data dictionary as well.

Aliases Terms representing concepts that are represented in a semantically equivalent way by other terms and concepts in the model shall be maintained as aliases and shall not be introduced into the model. Multiple source definitions shall be maintained as with other model terms and a consensus definition shall be derived from the sources.

Core Process Requirement

All concepts included in the DM2 shall be necessary to support the information requirements of one or more core processes (PPBE, DAS, JCIDS, CPM, SE, OPS). All DoDAF models shall be applicable to one or more core processes. Core process information requirements shall be as explicitly or implicitly specified in current or planned DoD governance. All model terms and concepts not necessary for core process support with architectures shall be removed. All core process information requirements for architectural descriptions shall be modeled and contained in one or more DoDAF models.

Aggregation Rule If a term representing a concept differs structurally from some other term representing some concept only in level of aggregation, it shall not be included in the model. Whole-part relationships cover the need without different names for different types of wholes and parts. The term may be included as an alias.

Subtype Rule If a term representing a subtype concept has no structural difference from its supertype, it shall not be included in the model. Super-subtype relationships cover the need without different names for different types of supertypes and subtypes. The term may be included as an alias.

Typed Relationships All relationships shall be typed, ultimately up to IDEAS foundation. The typing shall be determined using BORO analysis of spatio-temporal examples.

Attributes and Properties

All attribute and property relationships shall be explicit, that is, by an association class that is typed according to the Typed Relationships rule. The only exceptions are for representational exemplars.

DoDAF model specification

All DoDAF models shall be specified using terms from the data dictionary. Aliases may be used. If new terms are required, they shall undergo the process for new term inclusion in the data dictionary as described by the Terms and Definitions and Aliases rules. All DoDAF models shall be mapped to the DM2 classes (base and associative) that represent the information contained in the view the model specifies.

Logical Correctness The DM2 LDM shall pass all logical consistency tests enforced by the Proctor, an IDEAS consistency tool. Information Pedigree There shall be a provision to provide pedigree (and provenance) for every piece of data IAW NCDS Security classification marking

There shall be a provision to provide a classification marking for every piece of data and for DM2 PES XML documents overall IAW NCDS

XSD The PES XSD shall adhere to XML standards and best practices.

18

DoDAF Must Relate to Core Processes

Core Process Primary ProductsPrimary Directive, Instruction, or

Decision Authority

Pe

rfo

rme

r

Re

so

urc

e F

low

Info

rma

tio

n A

nd

Da

ta

Re

ific

ati

on

Le

ve

ls

Org

an

iza

tio

na

l S

tru

ctu

re

Ca

pa

bil

ity

Se

rvic

es

Pro

jec

t

Pe

dig

ree

Ru

les

Me

as

ure

Lo

ca

tio

n

Work Breakdown Structure (WBS)

DoD 5000.2-R DoDD 5000.4Mil-HDBK-881A

Integrated Master Plan and Schedule (IMP/IMS)

Integrated Master Plan and Integrated Master Schedule Preparation and Use Guide, Version 0.9 October 21, 2005

Risk Management Plan (RMP)

DoD 5000.2-R DoDD 5000.4Defense Acquisition Guidebook (DAG), Section 11.4)RISK MANAGEMENT GUIDE FOR DOD ACQUISITION, Version 0.9October 21, 2005

Technology Development Strategy (TDS)DoDI 5000.02 Enclosure 2Defense Acquisition Guide, Section 2.2

Milestone and Gate Reviews

Acquisition Strategy (AS)OMB Circular No. A-11Chapter 2 Defense Acquisition Guidebook

DoD Core Process/

Sub-Process

De

fen

se

Ac

qu

isit

ion

Sy

ste

m (

DA

S)

Es

se

nti

al

Ac

qu

isit

ion

In

str

um

en

ts

DRAFT

DRAFT

19



Decision Authority

Pe

rfo

rme

r

Re

sou

rce

Flo

w

Info

rmat

ion

An

d D

ata

Re

ific

ati

on

Le

vels

Org

an

iza

tio

na

l S

tru

ctu

re

Ca

pa

bili

ty

Se

rvic

es

Pro

ject

Pe

dig

ree

Ru

les

Me

asu

re

Lo

cati

on

System Engineering Plan (SEP) Systems Engineering Plan Preparation Guide, Version 2.01, April 2008

Specification Development Plan (SDP) DoD 5000.2, DoD Acquisiton Guide Book, Chapter 4

System Segment or SoS SpecificationsDoD 5000.2, DoD Acquisiton Guide Book, Chapter 4

Interface Requirement Document (IRD)--May be part of SoS Specification

DoD 5000.2 DoD Acquisiton Guide Book, Chapter 4

Statement of Work/Performance (SOW/P)DoD 5000.2 DoD Acquisiton Guide Book, Chapter 4

Test and Evaluation Master Plan (TEMP)DoD 5000.2DoD Acquisiton Guide Book, Chapter 4,7,9

Interoperability Test Proeedures (Tied to ISP and NR-KPP)-JITC Joint Interoperability Certification

DoDD 4630.05, May 5, 2004 CJCSI 6212.01E/F DoD Acquisiton Guide Book, Chapter 4,7

Operational Test Procedures (Mission Thread Oriented)

DoD 5000.2DoD Acquisiton Guide Book, Chapter 4,7,9Measures Development Standard Operating Procedure (SOP) ,September 15, 2010, Director, Operational Test and Evaluation (DOT&E) sponsored Joint Test and Evaluation Methodology - Transition (JTEM-T)

DoD Core Process/

Sub-Process

Sy

stem

s E

ng

inee

rin

g-A

cqu

isit

ion

-

DRAFT

DRAFT

20



Decision Authority

Pe

rfo

rme

r

Re

so

urc

e F

low

Info

rma

tio

n A

nd

Da

ta

Re

ific

ati

on

Le

ve

ls

Org

an

iza

tio

na

l S

tru

ctu

re

Ca

pa

bil

ity

Se

rvic

es

Pro

jec

t

Pe

dig

ree

Ru

les

Me

as

ure

Lo

ca

tio

n

Info

rma

tio

n P

ed

igre

e

Joint Programming Guidance (JPG)Strategic Planning Guidance (SPG)OMB Fiscal guidanceNational Strategy for Homeland Security (NSHS)Quadrennial Defense Review (QDR)

OSD (PA&E)

DoD Directive 7045.14, The Planning, Programming, Budgeting, and Execution System(PPBE), (PBBE) Integrated PBBE Guide, DSN 785-0071, 23 May 1997

Other--E-GOV, President’s Management Agenda; High interest projects with Congress, GAO, OMB, or the general public; Cross-cutting initiative, e.g., Homeland Security.

Program Objective Memo (POM)Budget Estimate Submission (BES)

Service/Agency Submissions

Chairman's Program Assessment (CPA)Joint Staff Review:CJCSI 8501_01 JOINT STAFF PARTICIPATION IN THE PPBE

POM Issue Papers and Reclama's Services, Joint Staff, and OSD directorates Program Decision Memoranda (PDMs) DEPSECDEF

Pla

nn

ing

an

d P

rog

ram

min

g

Pla

nn

ing

, P

rog

ram

min

g,

Bu

dg

eti

ng

an

d

Ex

ec

uti

on

(P

PB

E)

DoD Core Process/

Sub-Process

DRAFT

DRAFT

21



Decision Authority

Pe

rfo

rme

r

Re

so

urc

e F

low

Info

rma

tio

n A

nd

Da

ta

Re

ific

ati

on

Le

ve

ls

Org

an

iza

tio

na

l S

tru

ctu

re

Ca

pa

bil

ity

Se

rvic

es

Pro

jec

t

Pe

dig

ree

Ru

les

Me

as

ure

Lo

ca

tio

n

BES Review:Program Budget Decisions (PBDs)

USD(C) office and OMB

Major Budget Issues (MBIs)

USD (Acquisition, Technology & Logistics) and D, PA&EUSD (Acquisition, Technology & Logistics) and D, PA&E, Services, PEOs, PMs

President's Budget--FYDP:

FYDP Program Structure Handbook (DoD 7045.7-H)Summarizes forces, resources, and equipment associated with all DoD programs approved by the SECDEF: Budget Exhibits- -Major Force Program (MFP)--Macro-level force mission or a support mission of DoD and contains the resources necessary to achieve a broad objective or plan -Program Element (PE)--Primary data element in the FYDP and normally the smallest aggregation of resources controlled by the Office of the Secretary of Defense (OSD) --R-Forms, P-Forms, Other Forms

DoD Regulation 7000.14-R, Financial Management Regulation, Volume 2

DoD Regulation 7000.14-R, Financial Management Regulation, Volume 2

Submission to Congress:DoD submits a biennial budget in which the first two years of the six-year FYDP period are submitted to Congress as fully supported "stand alone" budgets.

OSD

Program Change Proposals (PCPs)Budget Change Proposals (BCPs)

Services, Defense Agencies, and COCOMs

Execution ReviewConcurrent with the Program and Budget reviews

Bu

dg

eti

ng

an

d E

xe

cu

tio

n

Pla

nn

ing

, P

rog

ram

min

g,

Bu

dg

eti

ng

an

d E

xe

cu

tio

n (

PP

BE

)

DoD Core Process/

Sub-Process

DRAFT

22



Decision Authority

Pe

rfo

rme

r

Re

so

urc

e F

low

Info

rma

tio

n A

nd

Da

ta

Re

ific

ati

on

Le

ve

ls

Org

an

iza

tio

na

l S

tru

ctu

re

Ca

pa

bil

ity

Se

rvic

es

Pro

jec

t

Pe

dig

ree

Ru

les

Me

as

ure

Lo

ca

tio

n

Component Portfolio--IT investments align to Mission Area, and subportfolio or capability area portfolios as appropriate: -Warfighting Mission Area (WMA) -Business Mission Area (BMA) -DoD portion of Intelligence Mission Area (DIMA) -Enterprise Information Environment (EIE) Mission Area (EIEMA)

DoDDoDD 8115.01 October 10, 2005, Information Technology Portfolio ManagementOMBCircular A-11, Exhibits 53 and 300Congressional -E-Government Act of 2002 (Public Law 107-347), December 17, 2002 -FY03 DoD Appropriation House Report 4546, Title III, Section 351 -FY05 National Defense Authorization Act, "Defense Business Enterprise Architecture, System Accountability, and Conditions for Obligation of Funds for Defense Business System Modernization," Sec 332 § 2222 (h) Budget Information

Note: Investments > $30M, information similar to EX 300/Capital Investment Report (CIR)For Investment >$10M but <$30M, minimal program information (Name, Description, Funding request)

Identify opportunities for IT investments, and resolve cross-Mission Area issuesEstablish guidance for managing portfoliosProvide strategic direction for the Enterprise portfolio

Info

rma

tio

n T

ec

hn

olo

gy

Po

rtfo

lio

Ma

na

ge

me

nt

Do

DD

81

15

.01

Ca

pp

ab

ilit

y P

ort

foli

o M

an

ag

em

en

t (C

PM

)

DoD Core Process/

Sub-Process

DRAFT

23



Decision Authority

Pe

rfo

rmer

Re

sou

rce

Flo

w

Info

rmat

ion

An

d D

ata

Re

ific

ati

on

Lev

els

Org

an

iza

tio

na

l S

tru

ctu

re

Ca

pab

ility

Se

rvic

es

Pro

jec

t

Pe

dig

ree

Ru

les

Me

asu

re

Lo

cati

on

Joint Capability Profiles (JCA Tier 1): -Command and Control -Battle Space Awareness -Net Centric -Logistics -Building Partnerships -Protection -Force Support -Force Application -Corporate Management and Support

DoDD 7045.20 Capability Portfolio Management 2008 -Deputy’s Advisory Working Group (DAWG) -Joint Requirements Oversight Council (JROC) -Defense Acquisition Board (DAB)JCA Management Plan (JCAMP), 27 January 2010

Capability Portfolio Strategic PlansCPM Recommendations

DoDD 7045.20 Capability Portfolio Management 2008 -Deputy’s Advisory Working Group (DAWG) -Joint Requirements Oversight Council (JROC) -Defense Acquisition Board (DAB)

Ca

pp

ab

ilit

y P

ort

foli

o M

an

age

men

t (C

PM

) D

oD

D 7

045

.20

Ca

pp

ab

ilit

y P

ort

foli

o M

an

age

men

t (C

PM

)

DoD Core Process/

Sub-Process

DRAFT

DRAFT

24



Decision Authority

Pe

rfo

rme

r

Re

so

urc

e F

low

Info

rma

tio

n A

nd

Da

ta

Re

ific

ati

on

Le

ve

ls

Org

an

iza

tio

na

l S

tru

ctu

re

Ca

pa

bil

ity

Se

rvic

es

Pro

jec

t

Pe

dig

ree

Ru

les

Me

as

ure

Lo

ca

tio

n

Joint Capabilities Document (JCD) CJCSI 3170-01G Initial Cpabilities Document (ICD) CJCSI 3170-01G

Cpabilities Development Document (CDD) CJCSI 3170-01G Cpabilities Production Document Document (CPD)

CJCSI 3170-01G

Net Readiness Key Performance parameter (NR-KPP) (Mission Analysis (MA) , Information Analysis (InA), Systems Engineering (SE))

CJCS 6212_01E/F

Information Support Plan (ISP)Enhanced Information Support Plan (EISP)Tailored Information Support Plan (TISP)

CJCS 6212_01E/F

DoD Core Process/

Sub-Process

Jo

int

Ca

pa

bil

itie

s I

nte

gra

tio

n a

nd

D

ev

elo

pm

en

t S

ys

tem

(J

CID

S)

Re

qu

ire

me

nts

D

ev

elo

pm

en

tIn

tero

pe

rab

ilit

y

DRAFT

DRAFT

25



Decision Authority

Pe

rfo

rme

r

Re

so

urc

e F

low

Info

rma

tio

n A

nd

Da

ta

Re

ific

ati

on

Le

ve

ls

Org

an

iza

tio

na

l S

tru

ctu

re

Ca

pa

bil

ity

Se

rvic

es

Pro

jec

t

Pe

dig

ree

Ru

les

Me

as

ure

Lo

ca

tio

n

-National Military Strategy (NMS) -Joint Strategic Capabilities Plan (JSCP) -Guidance for Employment of The Force (GEF) -CJCS Risk Assessment -Unified Command Plan (UCP)

CJCSI 3100_01B

Guidance for the Development of the Force (GDF)

CJCSI 3100_01B

Operations Plans (OPLANS) -Time-Phased Force and Deployment Data (TPFDD) -ROE/Rules for the Use of Force (RUF) -Commander’s Critical Information Requirements (CCIRs)

CJCSM 3122.02BCJCSM 3122.01CJCSM 3122.03

Communications System Estimate (CSE) CJCSM 3122.01

Functional Plans (FUNCPLAN) CJCSM 3122.01 Operation Orders (OPORDs) CJCSM 3122.01

Op

era

tio

ns

Pla

nn

ing

Jo

int

Str

ate

gic

Pla

nn

ing

S

ys

tem

(J

SP

S)

Jo

int

Op

era

tio

ns

Pla

nn

ing

a

nd

Ex

ec

uti

on

Sy

ste

m

(JO

PE

S)

DoD Core Process/

Sub-Process

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 R

EVISIO

N PER

FAC DIR

ECTION

28

FAC is Small Formal Voting BodyWG is Large & Collaborative

FAC – Voting – 23* votes

AF

Do

N

Arm

y

Ma

rin

e

Co

rps

DIS

A

DIS

A

DIS

A

DoD CIO

DN

I C

IO

AT

&L

P&

R

US

D(I

)

DC

MO

JC

S J

6

ST

RA

TC

OM

JFC

OM

NS

A

* Some C/S/A have multiple members

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

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

DoDAF-DM WG – Collaborative – Agreed-upon business rules enable analysis of different opinions

CR Technical Redirectoin •CR Prioritization Redirectoin •

• DoDAF-DM2 Configuration Status Accounting Report (CSAR)

• DoDAF-DM2 Baseline Status• DoDAF-DM2 WG Activity Summaries• COI Metrics and Progress Report

• 400+ members + ~12 new each week

• Meets bi-weekly

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:– 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

DM2 DoDAF PESOBE 2 2 0 0

Defer to 2.04 37 32 2 3In Progress for 2.03 50 30 15 5

Unassigned 66 35 25 6Consult IDEAS Group 19 16 2 1

Defer 90 80 5 5In Ver 2.03 31 29 2 0

Rejected 3 2 1 0No Action Required 0 0 0 0

298 226 52 20

CI

31

DoDAF-DM2 Change Request Processing

DRAFT

DRAFT

Change Request submitted via WG

web

Change Request communicated to WG CR Tracker

Enter into system as

“unassigned”

Record: “defer” and planned

version (if known)Reject

CoA and actionee(s)

Update status (defer, reject, in-progress) and, if necessary,

CoA and actionee(s)

Record as “done in v2.xx”

Prepare readahead:§ Next batch of

“unassigned”§ Topics selected at

last meeting§ Material submitted

by Actionee(s)§ FAC redirects

Conduct Meeting

Call for “unassigned” originators to brief

their CRs and facilitate discussions

Discuss problem and CoA: defer, reject, or select

CoA and actionee(s)

Present and prepared to

discuss

Yes

Move to bottom of queue

No

Facilitate CoA updates by actionee(s)Facilitate

topic discussions

Provide research findings, possible

solutions, etc.

More work

Minority member non-

concurr?

WG Business RulesData Dictionary

Current and working baselinesCR databaseDM2 models

Core process requriements

Report non-currence to

FAC

No

YesYes

Call for topics for

next meeting

Report to FAC:WG activity summary

CSARFAC redirect

impacts

Facilitate FAC redirect

CoA revisions

FAC vote to redirect?

Impact:Biz rulesProgramsVendors

Discuss new CoA and

actionee(s)

Yes

FA

CC

I & C

R

Cus

todi

anC

R O

rigin

ator

s an

d A

ctio

nee(

s)W

G S

ecre

tary

Yes

Bi-weekly

Monthly

See “Detailed CR Processing” for

amplification

32

DoDAF CR Detailed Processing

DRAFT

DRAFT

TBD

33

CR requests new term or definition change

CR requests DM2 relationship change

New relationship

Evaluate restitch impact: what

definitions and other rqmts effected

Can a supertype be determined

Determine supertype using BORO analysis

Should it be an alias?

Collect source definitions and

enter in DD

Review and pick or formulate

definition

New or alias?

Enter mapped terms

Determine relationships in

DM2

Determine supertype using BORO analysis

Negative impact

Yes

NewAlias

No

No

Yes

AlternativesYes

No

Mark CR as Rejected

Make change to DM2

Yes

NoAdd as alias to DD

Make change to DM2, add to DD,

and define

No

Yes

Yes

No

START

END

END

END

DM2 CR Detailed Processing

DRAFT

DRAFT

34

Record:Date of WG

approval

Update status (defer, reject, in-progress) and, if necessary,

CoA and actionee(s) Restatus as “in progress”

for next version

Prepare for technical cutoff:

§ CR’s actionee(s) consider complete & ready for WG review

§ CR’s in progress§ FAC redirects

Conduct Technical Cutoff Meeting

Call for “done” actionee(s) to brief their CRs

Present solution and discuss

Majority present agree?

Yes

No

Call for “in progress”

actionee(s)

Provide status of solution(s)

Can make cutoff and / or priority for

version

Minority member non-

concurr?

Report non-currence to

FAC

NoYes

Yes

Report to FAC:§ CR’s “done”

for version§ CR’s

planned for version

§ Version release timeline & any issues

FAC vote to redirect?F

AC

CI &

CR

C

usto

dian

CR

Orig

inat

ors

and

Act

ione

e(s)

WG

Sec

reta

ry

Yes Update date of status update

Conduct production of

draft for Component

review: document,

IDEAS model, XSD, VDD

Conduct QA: tech edit,

IDEAS tools, XML tools

Request entry of draft version into

SACP & tasker to

Components to review

Issue tasker for Component review

Collect Component comments

Re-status affected CR

Facilitate normal CR

processing of re-statused

CR’s

Report to FAC

FAC vote to re-prioritize?

Yes

All comments resolved & no FAC redirects

No

Conduct production of

final: document,

IDEAS model, XSD,

VDD

Conduct QA: tech

edit, IDEAS tools,

XML tools

Post to DoDAF

website & MDR;

deprecate prior version

Archive “dones”

Request promulgation

notice

Notify Components

of new version

Technical cutoff & no FAC re-

prioritizations or redirects

No

Yes

Yes

Monthly

Bi-weekly

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

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

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

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

1. ASRG & FAC Governance to be updated

2. FAC Component reps formal tasker soon to be issued

3. Version tempo to slow to annual or semi-annual

4. Versions will go through review by Components by formal tasker

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

• 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

DRAFT

39

Welcome!We look forward to your

participation.

dodaf-dm2 wg orientation brief 13 april 2011 dodaf development team

Documents

dm2 data elements

views slide

backup slide

dodaf development team

dodafdm2 wg orientation

total data elements

single piece of data

term definitions slide