“State of DoD Architecting”
2006 Fall
CISA Worldwide Conference
October 17, 2005
Steven J. Ring
MITRE Corporation
[email protected]
Overall Mission Outcome Process:
Aligning Architectures to Mission Outcomes
Mission
Outcomes
Architectures are a
means to an end
and not an
end to themselves
mission
decisions
Decisions
courses
of action
)
Decision
Making Process
analysis
data
Alignment
Analytics:
Tools/Methods
architecture
data
Integrated
Architectures
Executable
Architectures
2
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
DoDAF v1.0 Views
5/6 Interrogatives, OV=People, SV=System
?
WHY
WHAT
Operational
View
HOW
System
View
System
Function
Data
Technical
Standards
View
WHEN
Op Node/Organization/Role
Operational
Processes
Op Activity
Information
All
View
(AV)
WHERE - WHO
Standards
System
Node
System
System
Processes
5
6
DoDAF v1.5
HOW
FUNCTIO
N
WHO
ACTOR
WHER
E
LOCATIO
N
WHY
WHEN
CONDITION
RULE
WHAT
PRODUCT
7
DoDAF v1.5 Recommendations
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
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
WHAT
HOW
PRODUCT
FUNCTION
Operational
(Requirements)
View
Product
System
(Solution)
View
WHERE
LOCATION
WHO
WHEN
ACTOR
WHY
CONDITION
Undifferentiated/ Unallocated/ UnSpecified Resource
RULE
?
Function at Location by Resource
Function
Location
Performer (only) View
Resource
Condition
Rule
Performer + Asset View
+
Function at Location by Performer
Performer
Information,
Material, Data
Function
Location
Condition
Asset
Asset (only) View
Function at Location by Asset
Technical Standard View
Standards
Features
Performance
Features
Rule
9
Net-Centric DoDAF Transformation
From this
SV-5
Sys Node
Op Node
Info
Operational
Activity
Info
Data
System
Function
Data
To this
Location
Item
FUNCTION
Item
+
Node
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
10
11
Conceptual Requirement Objects
Requirement
Concepts
functionRequirement
Function
FunctionUOM
ActorRole
actorRequirement
Requirements
Given a Threat to the world…
1) have a Superhero
2) Save the World
3) within 1 minute
4) at a cost not to exceed $500
Solution
Concepts
Function
Save the World
Actor
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
actorUOM
● Speed is faster or slower
than speeding bullet
● Cost per engagement in $
actorFeature
Runs &
Runs
Runs
Flies
faster
slower
faster
than
than
than
speeding
speeding
bullet speeding
bullet
bullet
@ $250
@
$100
@ $500
12
Separating “Requirements” from “Solutions”
Conceptual Object Model
Requirements
function
(from how)
1
0..1
(from abstractMeasure)
0..1
0..1
1
references
functionRequirement
specified by
1
responsible for
provides UOM
comprises
0..1
functionByActor
satisfies
(from how)
0..1
0..1
achieved through
actorRole
functionUOM
(from abstractMeasure)
(from how)
comprises
accomplishes
plays
0..1
1
actor
(from who)
actorFeature
1
0..1
satisfies
actorRequirement
(from abstractMeasure)
(from abstractMeasure)
provides UOM
0..1
measured by
provides UOM
Solution
0..1
actorUOM
(from abstractMeasure)
13
Separating “Requirements” from “Solutions”
Instances
functionRequirement
Requirements
function
function
“Save
the
World”
(from
how)
references
● Given a Threat to the World…
● Have a Super Hero
● functionRequirement
Save the World
● in(from
1 minute
abstractMeasure)
● at a cost not to exceed $500
specified by
provides UOM
responsible for
comprises
functionByActor
actorRole
functionByActor
“Save the World
satisfies
by [Superman?]”
(from how)
functionUOM
achieved through
actorRole
“Superhero”
(from how)
Completion…
functionUOM
● (from
Time
in Minutes
abstractMeasure)
● Cost in $
comprises
accomplishes
actor
Superman
actor
(from who)
Flash
Batman
plays
actorRequirement
actorFeature
Able to Run & Fly faster
actorFeature
than speeding
bullet @ $500
satisfies
(from abstractMeasure)
Able to Run faster
than speeding bullet @ $250
Able to Run slower than
speeding bullet @$100
measured by
provides UOM
Solution
Solution
● Able to Move (Fly?, Run?)
actorRequirement
Faster
than Speeding Bullet
● Cost
per engagement not to
(from abstractMeasure)
exceed $500
provides UOM
actorUOM
● Speed is faster or slower
actorUOM
than speeding bullet
abstractMeasure)
●(from
Cost
per engagement in $
Requirements