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. 2751 Et. Seq.) or Executive Order 12470. 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.

Agenda Re-cap brief on IDT architecture development Reification, allocation, and traceability across the development levels Expected Results Next Steps 25 Feb 2013 2

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

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

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

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

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

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

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

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

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

Next Steps 25 Feb 2013

Reification, allocation, and traceability across the development levels

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

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

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

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

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

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

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

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

Questions? 25 Feb 2013 22

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

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

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

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

Cont’d 25 Feb 2013

FFP Workflow Examples 25 Feb 2013 28

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

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

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