1. DoDAF In-Depth DoD CIO Architecture and Interoperability Directorate
Briefing to JTSO Director
May 2013
DISTRIBUTION STATEMENT D: Distribution authorized to DoD and DoD contractors only. Critical Technology (4/10/2007). Other U.S. requests shall be referred to the DoD CIO, Architecture and Interoperability Directorate
WARNING: This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C. Sec Et. Seq.) or Executive Order Violations of these export laws are subject to severe criminal penalties.
DESTRUCTION NOTICE: Destroy by any method that will prevent disclosure of contents or reconstruction of the document.

2. Agenda DoDAF Basics DoDAF Engineering presentation
Why DoDAF?
DoD CIO DoDAF Policy Overview
DoDAF Basics
DoDAF Engineering presentation
Reification, allocation, and traceability across the development levels
Re-cap brief on IDT architecture development
Summary from a JIE perspective -- DoDAF Artifacts and JIE
25 Feb 2013 2

3. Why DoDAF? Original and ongoing purposes:
Standardization across Components
Reuse of data across DoD’s six core processes:
JCIDS
DAS
PPBE
CPM SE
OPs
Support enterprise analytics, e.g.,
Interoperability assessment (early in SDLC)
Portfolio Management
Capacity planning
AoA
Capability gaps and overlaps
Line-of-sight from rqmts to implementations to resourcing

4. DoDAF Evolution 4 19 June 2012 4 DoDAF v1.5 1995 C4ISR F/W v1.0 v2.0
UAF
v2.05
2003
2007
JCIDS & NR-KPP
Applicability beyond C4ISR
Use-based
Integrated Architecture
2009
2010
2012
2014
v2.01
v2.02
v2.03
DoDAF/DNDAF
v2.04
1997
2016
2013
Joint Interoperability
DoDAF v1.0
C4ISR F/W v2.0
Net-centricity and SoA
SvcV views
26 AV/OV/SV/TV views
Linked to I&S policies
CADM 2.0
Fit-for-purpose
Data-centric architecture
Improved models of systems, services, capabilities, rules, measures
DoDAF Meta Model (DM2) based on IDEAS
Urgent CRs
52  1 XSD
IDEAS Foundation v1.0 fixes
TECHEDITS
DM2 OWL
Federal Common Approach
DNDAF Security Views
MODEM – DM2 Harmonization (IDEAS Domain Level)
NATO NAF
UDAF
Standardization, e.g.,
ISO
OMG
OASIS
Framework Objective:
Achieve a single integrated Architecture Framework for interoperability.
Achieve a US, Canada, and United Kingdom single Framework with a common Data Meta Model
Achieve alignment with the US Government Common Approach to Enterprise Architecture
19 June 2012 4 4

5. Enabler – Layers to Separate Evolving Policies from Enduring Architectural Concepts
DoDAF Models
Operational
Capabilities
Services
Systems
Data and Information
Standards
Projects
DM2
The 52 DoDAF models use the DM2 concepts
19 June 2012

6. DoDAF Basics

7. DoDAF Concepts = Concepts of DoD’s Six Core Processes
anything can have Measures
Condition
Guidance
is-performable-under
Rule
Activity
Capability
Standard
Agreement
constrains
requires-ability-to-perform
Backup slide has term definitions
has
consumes-and-produces
is-performed-by
is-realized-by
Project
achieves-desired-effect (a state of a resource)
is-the-goal-of
Resource
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.
describes-something
Information
Not shown but implied by the IDEAS Foundation:
Everything is 4-D and so has temporal parts, i.e., states
Everything has parts
Everything has subtypes
Materiel
Performer
Data
System
Organization
is-at
Location
GeoPolitical
Service
PersonRole
is-part-of

8. Definitions
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.

9. Logical Organization of Architectural Descriptions ≠ the DoDAF List
Models
AV-1: Overview and Summary Information
AV-2: Integrated Dictionary
CV-1: Vision
CV-2: Capability Taxonomy
CV-3: Capability Phasing
CV-4: Capability Dependencies
CV-5: Capability to Organizational Development Mapping
CV-6: Capability to Operational Activities Mapping
CV-7: Capability to Services Mapping
DIV-1:Conceptual Data Model
DIV-2: Logical Data Model
DIV-3: Physical Data Model
OV-1: High-Level Operational Concept Graphic
OV-2: Operational Resource Flow Description
OV-3: Operational Resource Flow Matrix
OV-4: Organizational Relationships Chart
OV-5a: Operational Activity Decomposition Tree
OV-5b: Operational Activity Model
OV-6a: Operational Rules Model
OV-6b: State Transition Description
OV-6c: Event-Trace Description
PV-1: Project Portfolio Relationships
PV-2: Project Timelines
PV-3: Project to Capability Mapping
SvcV-1 Services Context Description
SvcV-2 Services Resource Flow Description
SvcV-3a Systems-Services Matrix
SvcV-3b Services-Services Matrix
SvcV-4 Services Functionality Description
SvcV-5 Operational Activity to Services Traceability Matrix
SvcV-6 Services Resource Flow Matrix
SvcV-7 Services Measures Matrix
SvcV-8 Services Evolution Description
SvcV-9 Services Technology & Skills Forecast
SvcV-10a Services Rules Model
SvcV-10b Services State Transition Description
SvcV-10c Services Event-Trace Description
StdV-1 Standards Profile
StdV-2 Standards Forecast
SV-1 Systems Interface Description
SV-2 Systems Resource Flow Description
SV-3 Systems-Systems Matrix
SV-4 Systems Functionality Description
SV-5a Operational Activity to Systems Function Traceability Matrix
SV-5b Operational Activity to Systems Traceability Matrix
SV-6 Systems Resource Flow Matrix
SV-7 Systems Measures Matrix
SV-8 Systems Evolution Description
SV-9 Systems Technology & Skills Forecast
SV-10a Systems Rules Model
SV-10b Systems State Transition Description
SV-10c Systems Event-Trace Description
The list was not intended to imply development order
In many cases, a number was assigned because others were already taken, e.g.,
SV-4 which in standard SE is done as part of functional architecture, before allocation which would lead to interface specification (SV-1/2/3/6)
SV-7 which was equivalent to the Performance Characteristics section of the Mil-Std 490 “A-Spec” which is typically done early on
In many cases, the same information is just presented differently, e.g., SV-3 is just a summary of SV-1
In several cases, the information is traceability information, not actual architectural description, e.g., SV-5
There are also several views that have been superseded, e.g., SV-8&9, superseded by PV’s.

10. Possible Logical Organizations
Weapons System
Operational Capabilities
High-Level Operational Concept (OV-1)
Capability
Capability Vision and Activities (CV-1 & 6)
System Capabilities (CV-2 & SV-7)
Operational Analysis
Organizational Relationships (OV-4)
Activity Hierarchy (OV-5a)
Organizational and Task Resource Flows and Sequencing (OV-2, 3, 5, & 6c)
Logical Information / Data Description (DIV-2)
Functional Architecture
Functionality Description (SV-4a)
Traceability of Organizational Activities Supported by System and Service Functions (SV-5a)
Functional Resource Flows (SV-4, 6, and 10c)
System Architecture
System Composition and Interfaces
System Standards (StdV-1 & 2)
Project and Deployment Plans
Project Timelines and Dependencies (PV-2)
Organizational Deployment of Capabilities (CV-5)
Capability Schedules (CV-3)
Capability Dependencies (CV-4)
FEA Common Approach
Strategic
OV-1, CV’s
Business Services
OV’s, SvcV-1
Data and Information
DIV-1/2, OV-2/3/5, SV/SvcV-4, StdV’s
Enabling Applications
SvcV’s, functional / logical SV’s
Host Infrastructure
SV’s
Security
OV-6a, SV/SvcV-10a, StdV’s

11. Views

12. Views

13. Views

14. Views

15. Views

16. Capability Introduction
Capability is the organizing concept for force management in response to mission orders. The Joint Staff defines capability as,
The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks. [[i]]
Thus, the capability requirement has 6 components: 1) the desired effects, 2) measures associated with the effects, 3) tasks to be performed, 4) standards of performance (metrics) for the tasks, 5) conditions under which the tasks must be performed, and 6) measures associated with the conditions. Capability configurations that can provide or support intermediate, contributing, partial, and end effects are then modeled and evaluated against actual reported readiness data. These are modeled in the DoD capability model as shown in the next slide
[i] Joint Chiefs of Staff; Joint Capabilities Integration and Development System (JCIDS); CJCSI H; January 2012
6 Feb 2013

17. DoDAF Meta Model (DM2) of Capability
6 Feb 2013

18. Some important things to note about this model
Desired effects are resource states. This simplification is enabled by the formal ontology on which the model is founded (described briefly in DoDAF Vol III). Specifically, 1) because the ontology is four-dimensional, all instances are spatio-temporal extents so a resource has a temporal extent and has possible future extents, and 2) because the ontology is meronymic, resources have wholes and parts so that a resource can be a complex aggregate of all types of things, in principle including Political, Military, Economics, Social, Infrastructure, and Information (PMESII).
Desired resource states are ontologically synonymous with goals, objectives, and outcomes. Extensive research by the DoD working group that developed this model concluded that there was no objective distinction between the concepts because only subjective terms such as “more”, “greater”, “longer term”, “broader”, etc. were used to distinguish them. Since the foundation ontology is spatio-temporally mereologic, this distinction is not necessary.
Desired resource states can be for resource states of adversarial or neutral parties as well as blue force. For example, for a Joint Suppression of Air Defenses (JSEAD) mission, the desired effects might include that the resource state of the target area’s air defenses reaches some desired measures of destruction, denial, disruption, degradation, and / or deception (D5). For a humanitarian assistance mission, the desired effects might include that the resource state for the victim population reaches nutrition, shelter, health, and low casualty rates.
Activities, including operational activities, are considered ontologically synonymous with Tasks. Though arguable, the DoD capability modeling group could not determine an objective distinction.
6 Feb 2013

19. Some important things to note about this model (cont’d)
Measures enable modeling of the quantifiable aspects of the desired effect as well as the performance of tasks and the conditions under which they must be performed. The concept of measure is this model derives from [[i]]. The ability to ascribe measures to what may seem unmeasureable effects is inspired by [[ii]] but is substantiated by measures in the Universal Joint Task List (UJTL) [[iii]] associated with every task and by the measures standard operating procedures established by DOT&E [[iv]].
In addition to measures associated with task performance, specified standards also imply conformance with guidance, rules, etc., shown as a constraint on the performance of the tasks.
Conditions are modeled in accordance with the UJTL conditions and, therefore, measures are also associated with conditions.
A related resource flow model, of which core elements are shown above (Activity, activityProducesResource, activityConsumesResource, and Resource) links Activities to produced resources (i.e., resource states and typically complex aggregates of resources) so that the tasks to produce the desired effects are modeled as resource flows. This enables not only linkage of the tasks with the desired effects but also modeling of intermediate (e.g., causal) desired effects that can lead to the end-state desired effect. Activities and their performers are the core of the ways and means – capability configuration – that is the focus of the presentation and algorithmic work proposed herein.
Capability configuration that might provide such a capability are modeled as performers, which are typically aggregates of, for example, air, space, and cyber assets that are located geo-spatially and that have measures associated with their overall performance and readiness as well as the individual elements that comprise them, including the personnel.
[i] Ellis, Brian; Basic Concepts of Measurement; Cambridge University Press, Oct 1, 1968
[ii] Hubbard, Douglas; How to Measure Anything: Finding the Value of "Intangibles" in Business; John Wiley & Sons, Aug 3, 2007
[iii] Joint Chiefs of Staff; Universal Joint Task Manual; CJCSM E; August 2008
[iv] Director, Operational Test and Evaluation (DOT&E), Joint Test and Evaluation Methodology (JTEM); Joint Mission Thread Measures Development Standard Operating Procedures (SOP); May 3, 2010
[v] DoDAF CV-2: This model identifies and describes one or more hierarchies of capabilities provided by an architecture, and it specifies the types of hierarchical relationships between these capabilities.
6 Feb 2013

20. Capability Data Group and the Capability Views
CV-1 Vision
CV-2 Capability Taxonomy
CV-3 Capability Phasing
CV-4 Capability Dependencies
CV-5 Capability To Organizational Development Mapping
CV-6 Capabilities to Operational Activities Mapping
CV-7 Capabilities to Services Mapping
6 Feb 2013

21. Core Components of Capability (red outline)
CV-1 Vision
CV-2 Capability Taxonomy
CV-3 Capability Phasing
CV-4 Capability Dependencies
CV-5 Capability To Organizational Development Mapping
CV-6 Capabilities to Operational Activities Mapping
CV-7 Capabilities to Services Mapping
6 Feb 2013 21

22. Concepts in OV-2 Operational Resource Flow Description
Guidance
Measure
Information
Materiel
Organization
Performer
Resource
Concepts that could be
what used to be “Node”

23. Concepts in StdV-1 Standards Profile
Activity
Agreement
Condition
Constraint
Data
Guidance
Location
Materiel
Measure
Organization
Performer
Project
Resource
Rule
Service
Skill
Standard
System
Vision

24. Concepts in SV-1 Systems Interface Description
Guidance
Information
Location
Materiel
Measure
Performer
Person Type
Resource
Rule
Standard
System

25. DoDAF Engineering presentation Reification, allocation, and traceability across the development levels

26. Common Semantics Required to Manage Requirements, Design and Test Complexity

27. Common Lexicon Facilitates Auditable Traceability and Reduces Ambiguity
Vision
Guidance
Capability
Activity
Information
Rules
Desired Effect
Conditions
Locations
Measures
Resources
Performers
Organizations
PersonTypes
Skill
Standards
Agreements
Project
MeasureTypes
Systems
Services
Information

28. SE Primary Requirements Documents -Common Requirement Types-
Example
Operating Environment
The system shall operate under the conditions -50°F to +120°F ambient air temperature.
Operational Capabilities
The unit shall perform air assault operations under the conditions listed in Table 2.1.
System Performance Metrics
The system shall process a personnel change request in less than 0.1 seconds.
System Interface Requirements
The system shall exchange Call For Fire with Field Artillery via MIL-STD-2167.
System Functional Requirements
The system shall present, to the operator, patient medical records based on military ID.
Support (Non-Functional) Requirements
The system shall have a mean time between system abort of not less than 310 hours.
Verification and Test
The system shall be tested for salt fog per MIL-STD 810F Method 509.4
Traceability
All requirements in Section 3.3 of this document shall be traced to a requirement in the CDD.

29. Establishing Relationships -System Specifications- -Common Requirement Types-

30. Next: Systems Engineering and Architecture Harmonization and Efficiency
DoDAF Viewpoints
All (AV)
Capabilities (CV)
Operational (OV)
Data / Information (DIV)
Systems (SV)
Services (SvcV)
Standards (StdV) AV
CBA
System
O & M
Validation &
Acquisition Model Decisions & Milestones CV
MS-C
TEMPcapabilities
MSA
System Validation
CPD
Capabilities Based Assessment (CBA)
Material Solutions Analysis (MSA)
JCIDS Documents
Initial Capabilities Doc (ICD)
Capabilities Design Doc (CDD)
Capabilities Production Doc (CPD)
Information Support Plan (ISP)
Verification
Technology Development (TD)
MS-A OV
DIV1
SVR
ICD
TEMPoperational
Engineering &
Manufacturing Development (E&MD)
Prototyping
System Verification
SRR
SRD,OCD,SPS,SCS
Typical Systems Engineering Work Products
System Requirements Document (SRD)
Operational Concept Description (OCD)
System Capability Specifications (SCSs)
Systems Performance Specification (SPS)
System Design Specification (SDS)
System/Subsystem Specification (SSS)
System/Subsystem Design Description (SSDD)
Software Requirements Specification (SRS)
Software Design Description (SDD)
Software Product Specification (SPS)
Data Base Design Document (DBDD)
Interface Requirements Specification (IRS)
Interface Control Document (ICD) / Interface Design Document (IDD)
Test and Evaluation Master Plan (TEMP)
System Engineering Technical Reviews
System Requirements Reviews (SRR)
System Functional Reviews (SFR)
Preliminary Design Reviews (PDR)
Critical Design Reviews (CDR)
Test Readiness Review (TRR)
System Verification Review (SVR) SV
SvcV
DIV2
StdV
TRR
TEMPsystem
SFR
System Design
Subsystem Verification
SSS,SDS, SRS,IRS
CDDprelim; ISPprelim
MS-B SV
SvcV
DIV2
StdV
Component Design
Component Verification
PDR
CDDfinal; ISPfinal
SSS, SDD,IDD
CDR
DIV3
SSDD, IDD, SPD, DBDD
Unit Test
Build
Notional Systems Development “V”

31. Reification in DoDAF is formally superSubtype, wholePart, or ovelap
Reification is the general term used in DoDAF to mean “refinement” through the SDLC
By extension (specialization) or decomposition
By mapping or allocation
Artifact1
Artifact11
Artifact12
Artifact13
DM2 super-subtype or whole-part
DM2 overlap
Reification in DoDAF is formally superSubtype, wholePart, or ovelap

32. Reification of Activities “Work, not specific to a single organization, weapon system or individual that transforms inputs (Resources) into outputs (Resources) or changes their state.”
In architectures, Activities are structures (see diagram to right)
Hence, to reify them means to reify the structure
For example, in an OV-5a, “Activity-1.1 reifies Activity-1”, means it reifies Activity-1’s structure:
Activity-1
consumedResources-A1.i
producedResources-A1.j
Rules-A1.k
Performers-A1.l
Measures-A1.m
Where “reify” means:
superSubtype,
wholePart, or
overlap

33. Reification of Capabilities “The ability to achieve a Desired Effect under specified [performance] standards and conditions through combinations of ways and means [rules, activities, and resources] to perform a set of activities.”
In architectures, Capabilities are structures (see diagram to right)
Hence, to reify them means to reify the structure
For example, in an CV-2, “Capability-1.1 reifies Capability-1” means it reifies the Capability-1 structure:
Capability-1
desiredEffects-C1.i
Tasks-C1.j
Rules-C1.k
Conditions-C1.l
Measures-C1.m
Where “reify” means:
superSubtype,
wholePart, or
overlap

34. Reification of Resource Flow “The behavioral and structural representation of the interactions between activities (which are performed by performers) that is both temporal and results in the flow or exchange of things such as information, data, materiel, and performers...”
For example, in an SV-1, each element of a reified resource flow must be a reification of elements from ordinate resource flows
More complex reiying across allocation levels (e.g., OVSV) because of typical many-many allocations
Some flows get rolled-up
New ones get created

35. The Reification can be in the form of different types of artifacts
e.g., SV/SvcV-7 Data
e.g., CV-x Data
The mapping is at the leaf level but some mapping to the “parents” is implied
This is the traditional MOE to MOP relationship

36. The Reification (and hence traceability) span from requirements to implementation
CV-x
SvcV-7
Notional example
SvcV-4
SvcV-5
OV-2/4/3/5
SV-1
SvcV-3

37. Component implementations
Notionally, for JIE, the upper pieces tend to flow from the ICD & EA through the RA’s to the SA’s and eventual implementations
ICD/ EA
RAs
Notional example
SAs
Component implementations
This is similar to the “yellow brick road” diagram but applied to the JIE at the enterprise level rather than each reification level

38. Example: Capabilities Reification Traceability Criteria
superSubtype reification: Capability11 reifies Capabilitiy1 iff:
wholePart reificaiton:
Proper wholePart:
Improper wholePart:
typeInstance:
overlap:

39. Re-cap Feb 2013 DoD CIO A&I brief on IDT architecture development

40. SoS Functional Allocation Theory
Black lines = ideal
+ Orange = reality
Black lines = ideal
+ Orange = reality
Orange is sometimes inevitable but should be avoided otherwise
25 Feb 2013 40

41. As Applied to JIE “Spec Tree”
Requirements documents*
* See notes for list
JIE ICD
IDEAL
JIE EA
Corrections and improvements
IDT Tech Archs
Component System/Service Specs for RFPs, working capital fund taskers, etc.
Joint & Service Doctrine, TTP, training, etc.
Test and compliance plans and procedures
25 Feb 2013 41

42. Focus at each tier Requirements documents System JIE ICD JIE EA+RA’s
End-state objectives are paramount
System
JIE ICD
JIE EA+RA’s
SoS
In SoSE, interfaces and common components are paramount
SoS Elements
IDT Tech Archs
Adherence to the the SoS element specifications is paramount
FoS of SoS Elements
Component System/Service Specs for RFPs, working capital fund taskers, etc.
Joint & Service Doctrine, TTP, training, etc.
Test and compliance plans and procedures
25 Feb 2013 42

43. Aligned JIE Spec Tree
1. The ICD X EA layer is collapsed and mappings no longer exist
2. Many-to-manys (orange lines) from EA Op Acts to RAs to IDT no longer exist
3. EA X RA Op Acts mapping no longer exists
Only orange lines left are those due to legacy
4. EA/RA X IDT Op Acts mapping no longer exists
25 Feb 2013 43 43

44. Recommended Streamlining
JIE ICD to JIE EA
JIE EA Op Acts one-to-one with RAs which are one-to-one IDTs
RA Op Acts = JIE EA Op Acts for their branch
IDT System Functions respond to RA Op Acts
25 Feb 2013 44

45. Notional Interface Matrix
In other words, it can be done at the SoS (EA/RA) level
25 Feb 2013 45

46. Functional Allocation EA to IDTs
In other words, it can be done at the SoS (EA/RA) level but may need to go below tier 3 in some cases
25 Feb 2013

47. IDT Arch Scoping: DoDAF “Fit for Purpose”
* In DoDAF 2, operators are part of the system or service
Fit-for-purpose (FFP) architecture tailored to the focus of the IDT
25 Feb 2013 47

48. Next Steps
25 Feb 2013

49. Questions?
25 Feb 2013 49

50. IDT Architectural Artifact POA&M*
Current Situation
IDT Architectural Artifact POA&M*
143 DoDAF views total across IDTs
* Source: EXCOM Brief
Above is simplification of 
25 Feb 2013 50

51. Risks Large number of views (143) to be developed in a “Stove Pipe”
Possible redundant artifacts in views
Views may become inconsistent
Configuration management of artifacts becomes intractable
No integration between IDTs
25 Feb 2013 51

52. JIE Spec Tree As-is
A related problem is “building from” views (reports) rather than the whole model (data)
25 Feb 2013 52

53. Risk Mitigation # 2: RA/IDT Boundaries
At the SoS (EA/RA) level, the interfaces have not been defined sufficiently
25 Feb 2013 53

54. Cont’d
25 Feb 2013

55. FFP Workflow Examples
25 Feb 2013 55

56. Risk Mitigation #4: Shared Architecture Data
Shared use cases / scenarios / vignettes*
EOC might lead many
Master AV-2 from ICD to IDTs and across all rocks, RAs, and IDTs
Probably federated CM
* SV/SvcV-10bc flow down’s from EA OV-6bc’s
25 Feb 2013 56

57. Expected Results Current Plan Proposed Plan
From 143 DoDAF views total across IDTs to 81 with:
Boundaries defined
Metrics defined
25 Feb 2013 57

58. Expected Results/Benefits
Can reduce DoDAF views substantially and produce a higher quality and more usable product
From 143 DoDAF views total across IDTs to 81 with:
Boundaries defined
Metrics defined
Redundant artifacts in views reduced through tailoring
Improve consistency
Configuration management of models (data) rather than views (reports)
Boundaries between IDTs definitized
Align and simplify the tiers from EA to RA to IDT
Build from models and data, not views
Practice SoSE and use DoDAF to establish boundaries
Tailor IDT Technical Architecture scope to fit-for-purpose
Shared vignettes and master AV-2
25 Feb 2013 58