(DoD) Architecture Framework (DODAF)

DoD Architecture
Framework
Dr. Fatma Dandashi
dandashi@mitre.org
l
ica
hn
Tec
The MITRE Corporation
Sys
tem
s
Huei-Wan Ang
Operational
hwang@mitre.org
October, 2003
© 2002 The MITRE Corporation. All rights reserved.
Outline
l Framework Definitions and Purpose
l Comparability to other Federal Frameworks
l DODAF Applicability Beyond DoD
l Changes In Product Definitions
l Architecture Uses – Capabilities Based Methodology
l Example Architecture - US NORTHCOM Architecture
l Standards Initiatives
l The Way Ahead
2
Framework Definitions and
Purpose
© 2002 The MITRE Corporation. All rights reserved.
Architecture Framework
l “An architecture framework is a tool… It should describe a
method for designing an information system in terms of a set
of building blocks, and for showing how the building blocks
fit together. It should contain a set of tools and provide a
common vocabulary. It should also include a list of
recommended standards and compliant products that can be
used to implement the building blocks.” [TOGAF 8,
OpenGroup]
l The Department of Defense (DoD) Architecture Framework
(DODAF)
–
4
Defines a common approach for describing, presenting, and
integrating DoD architectures
DoD Architecture Framework 1.0
l The Department of Defense (DoD) Architecture Framework
(DODAF)
–
–
Defines a common approach for describing, presenting, and
comparing DoD architectures
Facilitates the use of common principles, assumptions and
terminology
l The principal objective of the Framework is to
–
5
Ensure that architecture descriptions can be compared and related
across organizational boundaries, including Joint and multi-national
boundaries
DODAF Basic Principles - An Integrated
Architecture with Three Views
Activities/
Tasks
Operational
View
Operational
Elements
•
•
• W
• W ha
In ho t N
•
Re form Do eed
Sy
qu at es s t
th s
ire ion It o B
Inf e A tem
dt E
eD
or ct s t
o G xc
m ivi ha
on
ha
ati tie t
e
e
t It ng
on s a Su
e
D
s
Ex nd pp
o
ne
or
ch
t
Data Flow
Systems
X
Y
Systems
View
X
Standards
Y
Communications
Rules
Technical
Standards View
Z
Relates Systems and
Characteristics Yto
Operational
X
Needs
6
ility
tab
or s
pp itie
Su bil
gy pa
an
ge
s
Information Flow
lo a
al ts s
no l C
on en tie
ch ica
ati m ili
Te chn
er ire pab
sic Te
Op qu a
Ba w
Re nd C
• Ne
a
•
Identifies What Needs To Be
Done And Who Does It
• Technical Standards Criteria
• Specific Capabilities
Governing Interoperable
Required to Satisfy
Information Exchanges Implementation/Procurement
Prescribes Standards and
Conventions
of the Selected System Capabilities
Conventions
Architecture Framework Views and Viewpoints*
TOGAF
Views
7
Kruchten’s
4+1 Architecture
views
RM-ODP
Viewpoints
DoD Framework Views &
Applicable Products
View Concerns
Business
Architecture
View
Scenarios
Enterprise
Viewpoint
Operational View
Stakeholders, Business Process,
And Information Flow Models
Describes Enterprise and required capability
from the Stakeholder’s perspective
Data
Architecture
View
None
Information
Viewpoint
Operational/ Systems View
Logical Data Models, Physical
Schema
Describes information and data needed to
provide capability
Applications
Architecture
View?
Logical
Computational
Viewpoint
Systems View
System Interfaces And
Communications Models
Describes distribution of components,
networking; developing and integrating the
various software components
Applications
Architecture
View
Development
Engineering
Viewpoint
Systems View
System Functions, Control, And
Information Flow Models
Describes architecture of system functionality
(software and Hardware) needed to provide
capability
Technology
Architecture
View
Process
Technology
Viewpoint
Systems Technical Views
Performance And Standards
Models
Processes in acquisition cycle
* The Open Group Architectural Framework©, The OpenGroup, www.opengroup.org
* P. Kruchten, "The 4+1 View Model of Architecture," IEEE Software, 12 (6), November 1995, IEEE, pp. 42-50
* Viewpoints are aligned with ISO standard ISO/IEC 10746-1: Reference Model – Open Distributed Processing (RM-ODP)
Comparability to other Federal
Frameworks
© 2002 The MITRE Corporation. All rights reserved.
Federal Architecture Frameworks
DODAF
TEAF
General Description
Defines a common approach for
describing, presenting, and
integrating DoD
architectures
Defines a common approach for
describing, presenting, and
integrating
Treasury/bureau
architectures
Provides ability to look across
federal government
projects and identify
opportunities to
collaborate, consolidate,
and identify Information
Technology (IT)
investments
How widespread is its use?
Required across DoD
•
Adaptations in use by
NRO, NATO, multiple
foreign countries
•
In use for eight years
•
Influenced other
Frameworks
Was used by Treasury and
Bureaus for 3 years.
“No longer supported”
Embryonic, still evolving
How much guidance is there for
the Architect?
•
•
Provides categories into which
aspects of individual
project proposals can be
mapped
•
•
9
Prescribes a very highlevel process for getting
started
Products very specific for
detail work
New “Desk Book”
(Includes “As-Is” to “ToBe” transition strategy,
example processes,
reference resources)
•
•
Provides more details than
FEAF
Most products borrowed
from DoD FW
Adds some IA products to
the DoD set
FEA Reference Models
Federal Architecture Frameworks
DODAF
10
TEAF
FEA Reference Models
Structure
Three Views — Operational,
Systems, Technical — with
various model types assigned to
Views
Zachman-like matrix
Functional, informational,
organizational, and infrastructure
columns
DODAF-like products,
Comprised of five reference models —
Performance, Business, Service Component,
Technical, and Data Reference Models
Integration
within the
Framework
Explicit connections between
elements across products
Explicit connections between
elements across products
• Business Reference Model (BRM) linked to
Budget Function Codes, which can serve as
useful starting point to align IT investments to
BRM
• Simple association rules between models, e.g.,
each Line of Business (BRM) should have an
associated performance measure from the PRM
Level of
detail
addressed
Level of detail captured in each
product left to Architect in
accordance with purpose and
scope of architecture
Level of detail captured in each
product left to Architect in
accordance with purpose and scope
of architecture
Simple hierarchical decomposition within each
reference model
DODAF Applicability Beyond
DoD
© 2002 The MITRE Corporation. All rights reserved.
Enterprise Architecture
l Elements of an enterprise include:
–
–
–
–
–
–
–
Business processes
Organizations responsible for them
Information and systems data they need to inter-operate
Information technology (IT) capabilities
Systems
Infrastructure
Specific technical standards that facilitate enterprise inter-operation
l An Enterprise Architecture (EA) describes these elements, their
structures, and inter-relationships to facilitate capital planning and
IT development sequencing
Enterprise
Architecture
12
=
Current
Architecture
+
Target
Architecture
+
Strategy
Supports: Current State
+
Roadmap for transition to target
environment
Relationship of Software to Systems Engineering
and to Enterprise Architectures
Enterprise
Architecture
Enterprise
Engineering
Systems Architecture
Systems
Engineering
Software Architecture
Software
Engineering
13
Aspects of Modeling
Functions
(How)
Data
(what)
Software
Architecture
System
Architecture
Software
Engineering
Systems
Engineering
• Process Flow
• Data Flow
• ER Diagrams
Functions
Data
• Use Case Diagrams
• Activity Diagrams
• Class Diagrams
• Sequence Diagrams
Time
(When)
Zachman
Primitives
DODAF
Modeling
Elements
Enterprise
Engineering
Functions
• Process Flow
• Data Flow
• ER Diagrams
Data
• Use Case Diagrams
• Activity Diagrams
• Class Diagrams
• Sequence Diagrams
Network
(where)
14
• Process Flow
• Data Flow
• ER Diagrams
Enterprise
Architecture
• Use Case Diagrams
• Activity Diagrams
• Class Diagrams
• Sequence Diagrams
Network
• Network Diagrams
Time
• Network Diagrams
• Hardware Layout Diagrams
• Hardware Layout Diagrams
• Modeling & Simulation
• Modeling & Simulation
People
(Who)
• Organizational Diagrams
• Enterprise Vision
Motivation
(Why)
Context and Relationship To These Scopes
Operational
View
Enterprise/Mission Needs Information Interoperability
Requirements
Systems
View
Implementation
Domain
System of Systems
Architecture
(Software Intensive)
Information
(Software Parts)
Manufacturing
(Hardware Parts)
Software Engineering
Systems Engineering
Design and Development Processes
Design and Development Processes
Technical
View
15
Industry Standards
Changes In Product Definitions
© 2002 The MITRE Corporation. All rights reserved.
DODAF Architecture Products
17
Applicable View
Framework Product
Framework Product Name
All Views
AV-1
Overview and Summary Information
All Views
AV-2
Integrated Dictionary
Operational
OV-1
High-Level Operational Concept Graphic
Operational
OV-2
Operational Node Connectivity Description
Operational
OV-3
Operational Information Exchange Matrix
Operational
OV-4
Organizational Relationships Chart
Operational
OV-5
Operational Activity Model
Operational
OV-6a
Operational Rules Model
Operational
OV-6b
Operational State Transition Description
Operational
OV-6c
Operational Event-Trace Description
Operational
OV-7
Logical Data Model
Systems
SV-1
Systems Interface Description
Systems
SV-2
Systems Communications Description
Systems
SV-3
Systems-Systems Matrix
Systems
SV-4
Systems Functionality Description
Systems
SV-5
Operational Activity to Systems Function Traceability Matrix
Systems
SV-6
Systems Data Exchange Matrix
Systems
SV-7
Systems Performance Parameters Matrix
Systems
SV-8
Systems Evolution Description
Systems
SV-9
Systems Technology Forecast
Systems
SV-10a
Systems Rules Model
Systems
SV-10b
Systems State Transition Description
Systems
SV-10c
Systems Event-Trace Description
Systems
SV-11
Physical Schema
Technical
TV-1
Technical Standards Profile
Technical
TV-2
Technical Standards Forecast
Operational View Captures Critical Mission
Relationships and Information Exchanges
High-Level
Operational
Concept
Description
Operational
Node Connectivity
Description
Operational
Information
Exchange Matrix
From
External
Node
Information Exchange 1
STATE
VECTOR
Operational
Activity Model
•Information Description
•Name/Identifier
•Definition
•Media
•Size
•Units
•Information Exchange
Attributes
•Frequency,
Timeliness,
Throughput
•Security
•Interoperability
Requirements
•Information Source
•Information Destination
Node
B
Information
Activity 2
Activity 3
Inputs
Operational
Activity 1
Outputs
Information
Node
C
Inputs
Operational
Activity 2
Activity 3
Activity 1
Activity 2
Node
A
To
External
Node
High-level graphical
description of the
operational concept
of interest
18
Operational nodes,
activities performed at
each node, node-to-node
relationships, and
information needlines
Operational
activities, information
inputs and outputs,
conditions
Summary of
Information exchanged
between nodes with
attributes, such as
security, timeliness
Systems View Captures Systems, Functions
Performed, Data, and Network Layout
Can include systems,
H/W & S/W Items,
Interfaces (conceptual),
System Functions
System Nodes,
Systems, Links
Station
Base
Can include systems,
communications nodes,
networks, paths,
Links forming path,
protocols supported
System
C
Systems Interface Description SV-1
System
A
System
B
Communication Pathways and
Networks, Configuration Detail
Systems Communications
Description SV-2
External
Source
Data Flow 1
System
Function 1
Data Flow 2
System
Function 2
Data Repository
Data Flow Among
System Functions
Includes data sources
and sinks, repositories,
data flows between
system functions
Systems Functionality Description SV-4
Cap 1
Cap 2
V 1.0
V2.0
Cap 3
Cap 4
Describes planned
systems evolution
over time
Capability Evolution and
Migration
Systems Evolution Description SV-8
19
TV-1 Correlates Standards To Systems View
Architecture Elements
Systems Interface
Description (SV-1) &
Systems Communications
Description (SV-2)
Systems Data Exchange
Matrix (SV-6)
Technical Standards
Profile (TV-1)
Items - SW & HW
Physical Schema
SV-11
Data
Exchanges
JTA
STANDARDS
Data
Elements
Human
Systems Functionality
Description SV-4
E1
P1
Computer
Interface
Functions
AS-IS Service
Areas, Services &
Applicable
Standards
To-BE Service
Areas, Services &
Applicable
Standards
Technical Standards
Forecast (TV-2)
R1
P2
E2
Systems Technology
Forecast (SV-9)
Systems Performance
Parameters Matrix
SV-7
TO-BE
System
Technology
20
Systems
Technology
Forecast (SV-9)
Systems Evolution
Description SV-8
TO-BE
System
Technology
Architecture Uses
Capabilities-Based Methodology
© 2002 The MITRE Corporation. All rights reserved.
Capabilities-Based Methodology*
l The new Capability-Based Methodology:
–
–
–
–
–
–
Drive “jointness” from the top-down, strengthening joint warfighting
capabilities
Links strategic direction to strategic investment decision making and
acquisition policy
Enables a more responsive acquisition system
Integrates materiel and non-materiel solutions to capability gaps and
shortfalls
Frames discussions of alternatives using common language of metrics
Provides an engine for force transformation
*Source: J8
22
Today’s Process
Guidance
Interoperability?
Requirements
Based?
JR
Impact on:
Doctrine?
Organizations?
1
Training?
Leadership?
Facilities?
(DOTLPF)
JROC
Bottom up, Proposed
Materiel (M)
Solutions
*Source: J8
23
Decisions Based on
• Experience
• Staff Support
• Judgement
• Intuition
Platforms
Capabilities-Based Methodology*
Today
Integrated at
at
Integrated
Department
Department
Proposed
National
National
MilitaryStrategy
Strategy
Military
Systems
Systems
Joint
Joint
Vision
Vision
Joint
Joint
Operations
Operations
Concepts
Concepts
Requirements
Requirements
JointOperating
Operating
Joint
Concepts
Concepts
Functional
Functional
Concepts
Concepts
ServiceOperating
Operating
Service
Concepts
Concepts
Functional
Functional
Concepts
Concepts
“Born Joint”
Bottom up, “Stovepiped”
ü Improved analytical rigor will better define the capabilities we need and those we no longer need.
ü Capabilities-based planning counters threats that pose the greatest danger without predicting
specific contingencies.
ü Scenarios illuminate possible outcomes of potential contingencies and test capability needs.
ü Resource constraints impact implementation plans, not capability needs determinations.
ü Focusing leadership earlier in the decision process ensures a more coordinated implementation
effort within resource constraints.
24
*Source: J8
Capabilities-Based Methodology
l Capability-based analysis:
25
–
A capability is described by Operational Activity Model + DOTMLPF
Attributes + Operational Activity Sequence and Timing Descriptions
–
New SV-5 Matrix relates Operational Activities to System Functions,
Operational Activities (in an operational thread) to Capabilities, and
Capabilities to Systems
System 2
System 1
26
System
Function
A
System
Function
B
System
Function
C
System
Function
B
System
Function
D
System
Function
E
System
Function
F
Operational
Activity H
Operational
Activity G
Capability 2
Operational
Activity E
Operational
Activity A
Operational
Activity F
Operational
Activity E
Capability 1
Operational
Activity D
Operational
Activity C
Operational
Activity B
Operational
Activity A
SV-5 Maps Capabilities to Systems
Capability 3
Architecture Development and Assessment*
There are dependencies between the architecture
products that are not shown. Many of the products
are developed Iteratively
Concept Development
OV-1
OV-2
Capabilities
Capabilities
OV-5
OV-6c
1st Order Analysis: System Functionality
System Functional Mapping
Functional
Assessment
OV-3
SV-1
SV-4
Gaps
Duplications
SV-5
System Interfaces & Data Flow
SV-1
OV-3
SV-3
SV-2
SV-6
TV-1
2nd Order Analysis:
Connectivity & Interoperability
Static
Interoperability
Assessment
Interoperability
3rd Order Analysis: Dynamic Interoperability
System Performance & Behavior
SV-10b/c
SV-7
Executable
Model
27
Dynamic
Performance
Assessment
Mission Area
Performance
*Source: J8
Capabilities-Based Methodology
Joint
Joint
Operations
Operations
Concepts
Concepts
system 2
ServiceOperating
Operating
Service
Concepts
Concepts
Functional
Functional
Concepts
Concepts
Functional
Functional
Concepts
Concepts
system 3
Command & Control
system 4
Capabilities
system 5
system 6
2004
2006
2008
2010
2012
2014
2016
sys 3
SLEP
capability
sys 1
block
upgrade
new sys
FOC
sys 2
end of svc life
Activity a
capability
Activity b
Activity c
2004
training
change
*Source: J8
2006
2008
2010
2012
field new
organization
2014
FEEDBACK
Resource Strategy
Capability Roadmap
28
Activity g
Activity f
Activity e
capability
system 1
Force Protection
Focused Logistics
JointOperating
Operating
Joint
Concepts
Concepts
Activity c
Battle Space
Awareness
capability
Activity d
capability
Force Application
Joint
Joint
Vision
Vision
Activity a
National
National
Military
Military
Strategy
Strategy
Assessment
Architectures
Activity b
Concepts
Example Architecture
NORTHCOM Architecture
© 2002 The MITRE Corporation. All rights reserved.
NORTHCOM Architecture Approach*
Requirements
CONOPS
CRDs
iew
V
al
n
o
i
1
at
r
e
Op
0
ion
t
olu
v
n
E
ls
a
r
i
Sp
Incr
ew
i
n
sV
m
te
s
Sy
Incr
1
n
Incr
0
iew
V
s
rd
a
d
an
t
S
ion
t
lu
o
Ev
1
0
*Source: NORTHCOM Arch
30
al
c
i
hn
c
Te
Standards
Joint Technical Architecture
DoD Technical Reference Model
NORTHCOM Architecture Approach*
1
A
A Use
Use Case
Case
Specification
Specification
discusses
discusses
behavior
behavior in
in aa
series
of
series of
transactions,
transactions,
which
which are
are
further
further detailed
detailed
in
in associated
associated
artifacts.
artifacts.
Sequence
Sequence Diagram
Diagram (OV-6c)
(OV-6c)
Node
Node Connectivity
Connectivity Description
Description (OV-2)
(OV-2)
Use
Use Case
Case Specification
Specification
(UCS)
(UCS)
CCIC2S
CCIC2S Actor
Actor
Library
Library associated
associated
with
with OV-4
OV-4 Command
Command
Relationships
Relationships Chart
Chart
Information
Information Exchange
Exchange Requirement
Requirement (IER)
(IER)
Matrix
Matrix associated
associated with
with OV-3
OV-3 Operational
Operational
Information
Information Exchange
Exchange Matrix
Matrix
2
Usecase
Usecase Diagram
Diagram (UCD)
(UCD) associated
associated with
with
OV-5
OV-5 Operational
Operational Activity
Activity Model
Model
31
*Source: NORTHCOM Arch
OA
OA develops
develops Use
Use Cases
Cases
and
relationships
and relationships to
to
each
each other
other
•• extend
extend [do
[do on
on aa
condition
condition from
from parent]
parent]
•• include
[do
always
include [do always
with
with parent]
parent]
Usecase
Usecase Relationship
Relationship Diagram
Diagram (UCRD)
(UCRD)
associated
with
OV-5
Operational
associated with OV-5 Operational Activity
Activity Model
Model
NORTHCOM Architecture Approach*
4
3
Use
Use Case
Case
transactions
transactions are
are
modeled
modeled and
and
expanded
expanded to
to show
show
flows,
flows, decision
decision
logic
logic and
and key
key data
data
elements
in
an
elements in an
activity
activity diagram.
diagram.
Use
Use Case
Case Activity
Activity
Models
are
Models are used
used to
to
create
Operational
create Operational
Threads
Threads to
to process
process
flow
through
flow through the
the OA.
OA.
Operational
Operational Threads
Threads
associated
associated with
with OV-6c
OV-6c
Operational
Operational Event/Trace
Event/Trace
Description
Description
5
A
A specific
specific path
path through
through
the
the Activity
Activity Diagram
Diagram
isis made
made to
to describe
describe aa
performance
performance allocation
allocation
identifying
key
identifying key
conditions
conditions and
and aa step
step
range
range across
across each
each Use
Use
Case
Activity
Model
Case Activity Model
identifying
identifying aa specific
specific
behavior.
behavior.
inputs
These
These items
items are:
are:
-- operationally
operationally significant
significant
elements
elements
-- system
system stressing
stressing elements
elements
-- critical
data
critical data elements
elements
32
AFOTEC/17TS
AFOTEC/17TS Test
Test
Planning
Planning support
support
*Source: NORTHCOM Arch
Operational
Operational Threads
Threads
for
for performance
performance
metrics
metrics
NORTHCOM Architecture Approach*
6
7
33
Use
Use case
case transactions
transactions
and
decision
and decision logic
logic from
from
the
Use
Case
Activity
the Use Case Activity
Diagram
Diagram are
are further
further
decomposed
and
decomposed and
allocated
allocated in
in the
the Black
Black
Box
(System
Box (System
Responsibilities)
Responsibilities) view
view
called
called the
the Systems
Systems
Operational
Operational Sequence
Sequence
diagram
diagram to
to identify
identify the
the
system
boundary
system boundary
The
The Black
Black Box
Box (system
(system
responsibilities)
responsibilities) are
are
extracted
from
Rational
extracted from Rational
Rose
Rose and
and synchronized
synchronized
with
developer's
with developer's
requirements
requirements tool
tool to
to
show
traceability
across
show traceability across
originating
originating business
business use
use
case
case transaction,
transaction, IER
IER
association
association and
and realrealworld
world actor/role
actor/role
*Source: NORTHCOM Arch
System
System Operations
Operations
Sequence
Sequence (SOS)
(SOS)
Rose
Script
Black
Black Box
Box (System
(System
Responsibilities)
Responsibilities) Table
Table
These
These items
items are:
are:
•• operationally
operationally significant
significant
elements
elements
•• system
system stressing
stressing elements
elements
•• critical
data
critical data elements
elements
Architecture Uses Summary
Architectures
Architectures Provide
Provide the
the Framework
Framework
for
for FoS/SoS
FoS/SoS Systems
Systems Engineering
Engineering &
&
Acquisition
Acquisition
34
Standards Initiatives
© 2002 The MITRE Corporation. All rights reserved.
l
ica
hn
Tec
Sys
tem
s
Pillars for a Common Approach for Developing
Architectures
Operational
DoD Architecture Framework (DODAF)
Common approach for developing an architecture description
Common Underlying Meta Model
Common underlying structure for capturing
architecture data & Relationships
36
Benefits of Architecture Meta-Data
Standardization
l Reuse of data
l Consistency that facilitates integration
l Flexibility in partitioning of data from different points of view
l Ability to use automated architecture and modeling tools
interchangeably
l Better support for analysis and decision-making
Increased emphasis on development of integrated architectures
De-emphasis of an architecture product-by-product approach
37
Architecture Modeling Standards
l Architecture modeling standards are still evolving, chance to
help define and contribute
l Initiatives underway to address this need
–
–
ISO 10303 (AP-233) standards effort for SE data interchange and tool
interoperability
INCOSE / OMG effort to extend UML to modeling of systems
* Sanford Friedenthal, 2003
38
The Way Ahead
© 2002 The MITRE Corporation. All rights reserved.
Areas for Possible Research
l Validate and Clarify the information definitions provided by
the DoDAF
–
–
To capture the architecture data elements (object and relationships)
described by DoDAF
Use DoDAF definitions to define an object model
l Validate and Clarify the notation definitions intended by
DoDAF
–
Adjust the object and relationship definitions to include graphics (e.g.,
modeling notation) and/or formatting characteristics that are required
to be common
l Facilitate the common usage of such a model
–
–
40
Define an ontology: identify the generalizations / specializations
(supertypes / subtypes) that are appropriate
Provide clear, concise descriptions for all the data elements
Areas for Possible Research (Cont’d)
l Benefits - A DODAF model will:
–
Provide a common set of objects and relationship definitions
(requirements) that can be used by tool vendors to supply software
tools that support the development of DoDAF-Compliant architectures
–
Provide a common set of objects and relationship definitions against
which a standard interface can be defined to:
v
v
41
Enable the sharing of architecture model / products between different tools
Enable the implementation of a common repository for architecture data
References
42
l
ANSI/IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive
Systems
l
Clements, P., F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, J. Stafford. Documenting
Software Architectures: Views and Beyond. Addison-Wesley, Boston, 2002
l
Friedenthal, OMG SE DSIG Chair, Lockheed Martin Corporation, Aerospace Product Data
Exchange Workshop, April 8, 2003
l
Joint Staff, J8, “Introduction to the Joint Capabilities and Integration Development System,”
Briefing, 2003, http://dod5000.dau.mil/
l
Maier and Rechtin, The Art of Systems Architecting, CRC Press, 2000
l
Maier, “Architectures, Architecture Description, and Layered Models,” briefing at the SPC
workshop, 4-5 March 2003
l
NORAD/USSPACECOM, “Migrating Stovepipe Systems to Integrated/Interoperable Platforms
Using the Technical Reference Model and Object-Oriented Operational Architectures,” January
2003, Contact: tfolk@mitre.org
l
P. Kruchten, "The 4+1 View Model of Architecture," IEEE Software, 12 (6), November 1995, IEEE,
pp. 42-50
l
The OpenGroup, “The Open Group Architectural Framework© (TOGAF) Version 8: Enterprise
Edition," http://www.opengroup.org
l
ISO/IEC 10746-1:1998, Information Technology -- Open Distributed ProcessingReference Model,” 1998
l
Workshop on DoD Architectural Framework and Software Architecture, Technical Note CMU/SEI2003-TN-006, March 2003
Deskbook
© 2002 The MITRE Corporation. All rights reserved.
Deskbook: Supplementary Material Areas
Addressed
l Several techniques for developing architectures
–
–
–
–
–
–
44
Two architecture development processes
Notional examples of selected products portraying Network Centric
Operations Warfare (NCOW)
Representing the role of humans in architectures
Description of a Capability Maturity Profile
Security and Information Assurance Architecture
Developing architecture descriptions at increasing levels of detail
Deskbook: Supplementary Material Areas
Addressed
l Analytical techniques for using architecture information to support
DoD processes
Air Force’s Task Force capability-based analysis
Navy’s Mission Capability Package analysis approach
OASD(NII)/J6 Key Interface process for addressing interoperability at
interfaces
Architecture input to C4I Support Plans
The role of architectures in Capital Planning and Investment Control
–
–
–
–
–
SV-9
OV-4
Type A
TV-2
OV-3
TV-1
SV-8
OV-2
Type B
KIP
Capabilities
KIP
Activities/
Activities
TV-2
AV-1
TV-1
OV-1
OV-5
SV-4
SV-1
SV-7
As-Is
To-Be
SV-2
OV-6a
OV-6b
OV-6c
AV-2
OV-7
SV-5
SV-10a
SV-10b
SV-10c
SV-6
SV-3
Type AB
SV-11
KIP
45
Requirements
Systems/
Functions
Deskbook: Supplementary Material Areas
Addressed
l
Additional information
CADM support of architectural
concepts
– Criteria and approach for
assessing architecture tools
– Alignment with The Federal
Enterprise Architecture (FEA)
Reference Models
– Updated Universal Reference
Resources
–
Strategic
Outcomes
Customer
Results
Results
Business
Results
Results
Processes and
Activities
People
Technology
Value
46
Other Fixed
Assets