dodaf-dm2 wg orientation brief 13 april 2011 dodaf development team
TRANSCRIPT
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.
DoDAF 1.5 DoDAF 2.02
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.
DoDAF 1.5 DoDAF 2.02
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.
DoDAF 1.5 DoDAF 2.02
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
DoDAF Must Relate to Core Processes
Core Process Primary ProductsPrimary Directive, Instruction, or
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
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
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
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
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
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
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
DoDAF Must Relate to Core Processes
Core Process Primary ProductsPrimary Directive, Instruction, or
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
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
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
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
-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.