Generating C4ISR Architecture
Products Using Systems Engineering
Processes
Presented by
Dr. Steven H. Dam
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
1
Agenda
Background
What Are the C4ISR Products?
Why Use Systems Engineering Processes to
Perform Architecture Development?
Packaging and Selling Your Architecture
Products
Summary
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
2
Background
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
3
Who Am I?
Dr. Steve Dam

25+ years of software development and systems
engineering experience
Participated in the development of version 2.0 of
the C4ISR Architecture Framework
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
4
What Is the C4ISR Architecture
Framework?
1996
1997
1998
1999
2000
2001
2002
2003
Draft
DoD AF V 1.0
????
C4ISR AF V 2.0
Improvements
Draft DoD AF V 2.1
OSD Memo
C4ISR AF V 1.0
Object-oriented methodology
Mandatory use
New Standard
For the purposes of this seminar we will focus on
version 2.0, with highlights from draft 2.1
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
5
Fundamental Linkages Among the
C4ISR Architecture Framework Views
Identifies Warfighter
Relationships and Information Needs
Systems
View
Relates Capabilities and Characteristics
to Operational Requirements
of
el s
ev ge
d L an
y
an c h
x
log d
no an
ing n E
ch t y e s
ess tio ts
Te bili iliti
oc a en
Pr formirem
sic rta ab
Ba ppo ap
In u
q
Su ew C
Re
N
Pr
Le ocess
E x v e l s i ng
Sy
cha of and
s
to te m
nge Info In
N
Ne od s As
Re rma ter-N
qui tio od
Re edlin es, A soci
re m n
al
qui es cti ati
o
ent
rem an vit ns
i
d
s
e
ent
s,
s
Operational
View
Specific Capabilities
Identified to Satisfy
Information-Exchange
Levels and Other
Operational Requirements
Technical Criteria Governing
Interoperable Implementation/
Procurement of the Selected
System Capabilities
© 2002 Systems and Proposal Engineering Company.
Reference:
C4ISR Architecture Framework, Version 2.0
All Rights Reserved.
Technical
View
Prescribes Standards and
Conventions
6
What Are the C4ISR Products?
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
7
C4ISR Views
Applicable
Product
Architecture Reference
View
All Views
(Context)
Architecture
Product
Mandatory
Joint
or
Supporting,
SpecificPurpose
General Description
AV-1
Overview and Summary
Information
Scope, purpose, intended users, environment depicted,analytical
Mandatory findings, if applicable
All Views
(Terms)
All Views
(Capabilities))
AV-2
Integrated Dictionary
Mandatory Definitions of all terms used in all products
AV-3
Capability Maturity
Profile
Supporting
Operational
OV-1
High-level Operational
Concept Description
High-level graphical and textual description of operational concept (highMandatory level organizations, missions, geographic configuration, connectivity, etc.)
Operational
OV-2
Operational Node
Connectivity Description
Operational nodes, activities performed at each node, connectivities &
Mandatory information
flow between nodes
Operational
OV-3
Operational Information
Exchange Matrix
Information exchanged between nodes and the relevant attributes of
Mandatory that exchange such as media, quality, quantity, and the level of
interoperability required.
Operational
OV-4 Organizational Relationships Supporting Command, control, coordination, other relationships among organizations
Chart
Operational
OV-5
Operational
OV-6a
Operational Rules Model
Operational
OV-6b
Operational
OV-6c
Operational State Transition Supporting One of the three products used to describe operational activity sequence and
Description
timing that identifies responses of a business process to events
Operational Event/Trace
Supporting One of the three products used to describe operational activity sequence and
Description
timing that traces the actions in a scenario or critical sequence of events
Operational
OV-7
Activity Model
Logical Data Model
Description of focus areas in terms of incremental capability
levels, consistent with a standard capability maturity scale.
Activities, relationships among activities,inputs and outputs. In addition
Mandatory overlays can show cost, performing nodes, or other pertinent information.
Supporting One of the three products used to describe operational activity sequence and
timing that identifies the business rules that constrain the operation
Supporting Documentation of the data requirements and structural business
process rules of the Operational View.
Reference: DoD Architecture Framework, Version 2.1 (draft)
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
8
C4ISR Views (continued)
SV-1
System Interface
Description
Mandatory Identification of systems and system components and their
interfaces, within and between nodes
Systems
SV-2
Systems Communications
Description
Supporting Physical nodes and their related communications laydowns
Systems
SV-3
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems
Systems2 Matrix
Relationships among systems in a given architecture; can be designed to show
Supporting relationships of interest, e.g., system-type interfaces, planned vs.
existing interfaces, etc.
Functions performed by systems and the information flow among
Supporting system functions
Systems Functionality
Description
Operational Activity to System
Mapping of system functions back to operational activities
SV-5 Function Traceability Matrix Supporting
Detailing of data exchanges among system elements, applications and
System Data
Supporting H/W allocated to system elements
SV-6
Exchange Matrix
System Performance
Performance characteristics of each system(s) hardware and software
SV-7
Supporting elements, for the appropriate timeframe(s)
Parameters Matrix
Planned incremental steps toward migrating a suite of systems to a more
System Evolution
Supporting efficient suite, or toward evolving a current system to a future
SV-8
Description
implementation
Emerging technologies and software/hardware products that are expected to
System Technology
Supporting be available in a given set of timeframes, and that will affect future
SV-9
Forecast
development of the architecture
One of three products used to describe systems activity sequence and
Supporting timing -- Constraints that are imposed on systems functionality due to
SV-10a Systems Rules Model
some aspect of systems design or implementation
SV- 10b Systems State Transition
Supporting One of three products used to describe systems activity
Description
sequence and timing -- Responses of a system to events
Systems Event/Trace
One of three products used to describe systems activity sequence and
Supporting timing -- System-specific refinements of critical sequences of events
SV -10c Description
described in the operational view
SV-4
SV-11
Physical Data Model
Supporting Physical implementation of the information of the Logical Data
Model, e.g., message formats, file structures, physical schema
Technical
TV-1
Technical Architecture
Profile
Mandatory Extraction of standards that apply to the given architecture
Technical
TV-2
Standards Technology
Forecast
Supporting Description of emerging standards that are expected to apply to the
given architecture, within an appropriate set of timeframes
Systems
Reference: DoD Architecture Framework, Version 2.1 (draft)
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
9
Conceptual Relationship Between
Architecture Purposes and Products
Reference: C4ISR Architecture Framework, Version 2.0
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
10
Why Use Systems Engineering
Processes to Perform Architecture
Development?
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
11
How Does SE relate to C4ISR
Architecture Development?
Architecture provides the broader context for a
specific set of systems
Systems engineering methodologies apply
The main difference
Architecture study - less decomposition
Systems Engineering - more decomposition
Remember, one person’s system is another person’s
component, is another person’s architecture
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
12
From Chapter 7. FURTHER EVOLUTION OF THE
DOD ARCHITECTURE FRAMEWORK 2.1
“The Framework does not advocate the use of
any one methodology/notation…
[Use] whatever methodology/notation is
appropriate.”
The Framework products are intended to come from the results of a
complete system engineering process
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
13
The Role of Methodology
Provides structure
Enables concurrent activity
The C4ISR Architecture Framework was intended to be
methodology independent, so we must select our own
methodology
14
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
A Variety of Methodologies to Choose
From
Structured Analysis with and without realtime extensions
Object-Oriented Analysis and Design
Unified Modeling Language (UML)
System/Software Requirements Engineering
Methodology (SREM/DCDS)
Zachman Framework
Ad infinitum
Make sure the methodology you choose with
provide a broad, complete foundation for analysis
and specification
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
15
Characteristics of a “Good”
Methodology
Addresses your full life cycle
Integrates a set of processes
Provide executable results
Uses appropriate software tools
Communicates well to all audiences
Extends ability to adjust to specific needs
Has been applied successfully
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
16
The Role of Tools
Tools help us keep track of the variety of
information
Before - paper and pencil
Today - wide variety of tools

netViz
System Architect
DOORS

CORE
ERWIN/BPWIN
Rational Rose
Choose the tool that best implements the
methodology you want to use
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
17
Characteristics of a “Good” Tool
Supports your chosen methodology
Provides several integrated functions
Employs rule-based standards
Enforces consistency
Uses an integrated, common database
Permits simulation capability
Facilitates exporting data and products
Enables flexible reconfiguration
Applies to multiple lifecycle phases
Supports multiple disciplines
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
18
The “V” Model for Systems
Engineering
Current Operations
and Maintenance
Future Operations
and Maintenance
n
itio
pos
om
Dec
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
System
Design
Operational
T&E and
Transition
Inte
grat
ion
Architecture
Development
Demolition
and Disposal
Integration
and Test
Hardware/Software
Acquisition
Program
Management
19
How Do We Approach an
Architecture?
To
p
System
Analysis and
Control
Requirements
Analysis
Do
wn
Best Use:
“Classical SE”
Adapted from EIA-632
Functional
Analysis and
M
id
dl Allocation
e
Ou
Best Use:
Architecture
t
Development
Bo
Synthesis
tto
Best Use: m
Up
Reverse
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
Engineering
20
Architecture Development Process
and Products
AV-3
1. Capture and Analyze Related Documents
2. Identify Assumptions
Requirements Analysis
Functional Analysis
OV-4
Synthesis
5. Develop the Architecture Contexts
OV-1
OV-7
6. Develop Operational Scenarios
OV-2
System Analysis
OV-3
7. Derive Operational Views (OV)
and Control
OV-5
8. Derive
System Views (SV) SV-6 SV-5
SV-1
SV-8 SV-9
9. Allocate OV toSV-4
SV
SV-11
TV-2
SV-2
AV-1
4. Capture Technical Views (TV)TV-1
10. Prepare Interface Diagrams
SV-3
14. Provide Options
3. Identify Existing/Planned Systems
OV-6
SV-10
AV-2
12. Perform Dynamic Analysis SV-7
11. Define Resources, Error Detection & Recovery
13. Develop Operational Demonstration Master Plan
15. Generate Operational and System Architecture Graphics, Briefings and Reports
This implementation of the middle-out approach has
been proven on a variety of architecture projects
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
21
Who Should Be Part of My
Architecture Team?
Need someone with vision
Need someone who can perform the detailed
system engineering
Need someone who understands the domain
Need someone familiar with the methodology
and tools
Need someone who understands the process
Team: Pooled expertise…reduces risk
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
22
Packaging and Selling Your
Architecture Products
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
23
What have I been told to use?
Standards (e.g. C4ISR Architecture
Framework, Joint Technical Architecture, DII
COE, ISO 9000, DoD 5000)
Guidance documents and Directives (e.g.
JV 2020, Defense Planning Guidance, DoD
Directives)
Capability Maturity Models (standards for
your process; e.g. SEI SW CMM; CMMI)
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
24
What might be useful to choose to
use?
Other standards (not required)
System engineering tools (e.g., CORE, Slate,
System Architect)
Simulation and Modeling tools (e.g., CORE,
OpNet, COMNet, engagement models)
Word processing tools (e.g., MS Word)
Spreadsheets (e.g., MS Excel)
Drawing tools (e.g., PowerPoint, netViz,
Adobe Illustrator)
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
25
Who is my target audience?
Users
Developers
Acquisition personnel
Warfighters
…
Recognize that you may have to tailor individual
products for different audiences … and most will
not understand any system engineering diagrams,
except the OV-1
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
26
Example: EFFBD vs. PowerPoint
C.1
Perform
Customer
Functions
requests
status
Perform
Customer
Functions
products
AND
data
tasking
C.2
sts
Operate C4ISR
Management
System
ucts
; prod
AND
Perform
Collector
Functions
reque
status
0
Operate
C4ISR
Management
System
ta
da
t
k
as
ing
Perform
Collector
Functions
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
27
What questions does your target
audience ask?
How does this help me understand the
architecture better?
How does this help me make a decision?
How does this help me get the best “bang for
the buck?”
How does this enhance National Security?
How does this get me my next promotion?
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
28
How do we put together an effective
architecture?
Do the systems engineering right, then
produce any required documentation (e.g.
C4ISR AF Views)
Summarize the results in an easy to read
section, then provide detail in appendices
Provide a simple briefing that focuses on the
findings, not how you got there

You will need the how you got there to back up
the findings
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
29
How can I show that elements of my
architecture provide value?
One of the recent “standards” adopted by the
General Accounting Office (GAO) is “Balanced
Scorecard*”
Balanced Scorecard is an approach to provide
decision makers with a way to make investment
strategy decisions
Balanced Scorecard has three major steps:

Step 1. Define Mission and Desired Outcomes
Step 2. Measure Performance Practices * GAO Report GAO/AIMD98-89, “Measuring
Step 3. Use Performance Information
Performance and
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
Demonstrating Results of
Information Technology
Investments”
30
Balanced Scorecard Form
Concept/Program Element:
Evaluation
Criteria
Key Functional
Requirements
Baseline
Proposed Concepts/
Elements
Cost
Concept/
Technology Maturity
Schedule for
Implementation
Performance
Note that this scorecard is just a way to portray cost, schedule and
performance (and risk) – the basis for systems engineering
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
31
Part 5: Summary
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
32
Key Decisions
A proven methodology
A set of easy-to-use, integrated tools that
support the methodology
An architecture development process
Other Factors

An achievable schedule
The right people
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
33
C4ISR Products Needed
Depend on the phase that you are applying
the Framework
These products should be a natural part of
your methodology
Remember: Good Systems Engineering is your
methodology… C4ISR products are your output
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
34
Questions ?????
Discussion !!!!!
© 2002 Systems and Proposal Engineering Company.
All Rights Reserved.
35