1. DoD Architecture Framework Application
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 Re-cap brief on IDT architecture development
Reification, allocation, and traceability across the development levels
Expected Results
Next Steps
25 Feb 2013 2

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

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

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

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

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

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

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

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

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

12. Next Steps
25 Feb 2013

13. Reification, allocation, and traceability across the development levels

14. Reification in DoDAF is formally superSubtype, wholePart, or ovelap
By extension (specialization) or decomposition
By mapping or allocation
DM2 super-subtype or whole-part
DM2 overlap
Reification in DoDAF is formally superSubtype, wholePart, or ovelap

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

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

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

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

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

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

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

22. Questions?
25 Feb 2013 22

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

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

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

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

27. Cont’d
25 Feb 2013

28. FFP Workflow Examples
25 Feb 2013 28

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

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

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