1. “State of DoD Architecting”
2006 Fall
CISA Worldwide Conference
October 17, 2005
Steven J. Ring MITRE Corporation

2. Overall Mission Outcome Process: Aligning Architectures to Mission Outcomes
Architectures are a means to an end and not an end to themselves
Mission
Outcomes
mission
decisions
Decisions
courses
of action
Decision
Making Process )
analysis
data
Alignment
-The decision could be regarding JCIDS, BCIDS, Portfolio Management, etc.
-The decision making process produces a decision.
-Analytic analysis supports the decision making process.
-Analytic analysis needs DATA, which the architecture provides.
-Ideally, the architecture represents the fundamental data set for the entire decision-making process. Your go-to stop for data.
Analytics: Tools/Methods
architecture
data
Integrated Architectures
Executable
Architectures

3. 2005 Architecture Survey - DoDAF Weaknesses - 1/2
Lack of an architectural development process
Emphasis on architecture products and not analytical process (fundamental IM and IT analysis)
Not enough emphasis on architecture data…Lack of enforcement
integration among the products
Products lack information about action timing and sequencing
Requiring products instead of focusing on the underlying data of entities and there relationships
As values in architectures are not standardized, analytical capability across the enterprise is extremely reduced
DOTLMPF analysis techniques of integrated architectures is lacking
Higher echelons don't understand value of DoDAF architectures - therefore there is a constant battle to kill the requirement for DoDAF products
Architectures need to be capability focused…decision makers needs to know that if I cut these funds I will lose this capability that is planned to be used by this group of individuals
Diagrams too complex to present to senior leadership and strategic planners without modification
Focus is on just a single architecture…no discussion on best practices to defining architectures to insure they can be integrated and federated into an enterprise
Focused on stovepipe systems…needs to focus on enterprise services including humans

4. 2005 Architecture Survey - DoDAF Weaknesses - 2/2
Lack of common lexicon, taxonomy....e.g. COAL/UTL and CSFL issues
Lack of direction on how net-centric arch products should be developed ==> metadata, xml schema, services
Does not enable one to answer the question "so what?" as in, “we've spent $XXX to collect the info necessary to describe our XX architecture--so now what?”
Just describing an architecture is not adequate and, while DoDAF makes it clear up front that one should have a reason for describing an architecture, it still does not help make the leap to what one should do with it, once it's been described
Needs to move to "top-down" (capabilities) approach vice "bottom-up (requirements)
Clearer guidance on using UML
Does not address new layer of Service Oriented Architecture…the Service Views
Very little emphasis on requirements development as entry criteria for design of an architecture, and how to translate requirements into design of DoDAF views

5. DoDAF v1.0 Views 5/6 Interrogatives, OV=People, SV=System
WHY ?
System Function
Data
System
Node
System Processes
View
Technical Standards
Standards
Operational
Op Activity
Information
Op Node/Organization/Role
Operational Processes
WHEN
WHERE - WHO
HOW
WHAT
All
(AV)

6. DoDAF v1.5 HOW FUNCTION WHERE LOCATION WHO ACTOR WHEN CONDITION
WHAT PRODUCT
WHY RULE

7. DoDAF v1.5 Recommendations
Provide data-centric approach to integrated architecting
Single, holistic model of architecture concepts
Be unambiguous & semantically rich…eliminate semantic overloading
WHO, WHAT, WHERE, HOW, WHEN, WHY
Architecture data elements
Operational View
Requirements and solutions
Identify core set of architecture elements - WHO, WHAT, WHERE, HOW
Ensure DoDAF architectures do not become dis-integrated- workflow
Support executable architecture development and analysis
Enable linking (“Federating”) producing and consuming architectures
Capture sufficient architectural detail for full DOTMLPF analysis (not just Material)
Support more than just Information Technology architecting – material
Support cost-benefit analysis through cost & constraint entities
Support multiple architecture methodologies including Service Oriented Architectures (SOA)
Support COI requirements for linking Information (data) perspectives to processes and system perspectives
Support all phases of JCIDS Capability-Based Planning and Analysis (capabilities, effects, ways and means)
Elevate DoDAF to Enterprise Architecture Level – strategic vision goals
Support other Structured/Object Methodologies – BPMN, UML,…
Support More Than Single Relationship In OV-4 – commands, etc.
Extend TSV (Guidance, Standards, Etc) to All Architecture Elements

8. Three System Sub-Views: Performer, Asset , Performer + Asset
Asset (only) View
System (Solution)
View
Technical Standard View
Standards
Features
Performance Features
WHY RULE
WHEN CONDITION
WHO ACTOR
WHERE LOCATION
HOW
FUNCTION
WHAT PRODUCT
Information, Material, Data
Operational (Requirements)
Undifferentiated/ Unallocated/ UnSpecified Resource
Performer
Asset
Product
Resource
Function at Location by Resource
Function at Location by Asset
Function at Location by Performer ?
Function
Location
Performer (only) View
Rule
Condition
Performer + Asset View +

9. Net-Centric DoDAF Transformation
From this
SV-5
Data
System Function
Sys Node
Info
Op Node
Operational Activity
To this
Location
Item
FUNCTION +
Node

10. Separating “Requirements” from “Solutions” Not Possible with DoDAF v1.0
Given a Threat to the World, have a Superhero Save the World in 1 minute at a cost not to exceed $500
Superhero
Fictional character noted for feats of courage and nobility
Usually possesses abilities beyond those of normal human beings
Has colorful and distinctive names and costumes

11. Conceptual Requirement Objects
functionRequirement
Function
FunctionUOM
actorRequirement
ActorRole
Requirement Concepts
Requirements
Actor
Solution Concepts
actorUOM
● Speed is faster or slower than speeding bullet
● Cost per engagement in $
actorFeature
Runs & Flies faster
than speeding bullet
@ $500
Runs faster
@ $250
Runs slower
@ $100
Function
Save the World
Given a Threat to the world…
have a Superhero
Save the World
within 1 minute
at a cost not to exceed $500
Save the World
Completion…
● Time in Minutes…1
● Cost in $...500
Superhero
● Able to Move (Fly?, Run?) Faster than Speeding Bullet
● Cost per engagement not to exceed $500

12. Separating “Requirements” from “Solutions” Conceptual Object Model
provides UOM
measured by
satisfies
responsible for
plays
comprises
achieved through
specified by
accomplishes
references
(from who)
actor
actorFeature
(from abstractMeasure)
actorUOM
functionByActor
(from how)
actorRequirement
function
actorRole
functionRequirement
functionUOM
Solution
Requirements
0..1 1

13. Separating “Requirements” from “Solutions” Instances
functionRequirement
provides UOM
measured by
satisfies
responsible for
plays
comprises
achieved through
specified by
accomplishes
references
(from who)
actor
actorFeature
(from abstractMeasure)
actorUOM
functionByActor
(from how)
actorRequirement
function
actorRole
functionRequirement
functionUOM
Solution
Requirements
● Given a Threat to the World…
● Have a Super Hero
● Save the World
● in 1 minute ● at a cost not to exceed $500
“Save the
World”
function
Able to Run & Fly faster
than speeding $500
actorFeature
Able to Run faster
than speeding $250
Able to Run slower than speeding
Superman
Flash
actor
Batman
functionByActor
“Save the World
by [Superman?]”
● Speed is faster or slower than speeding bullet
● Cost per engagement in $
actorUOM G
Requirements
Solution
functionUOM
actorRole
Completion…
● Time in Minutes
● Cost in $
“Superhero”
actorRequirement
● Able to Move (Fly?, Run?)
Faster than Speeding Bullet
● Cost per engagement not to exceed $500