Architecture Architecture Ignore at your own riskIgnore at your own risk
(DODAF 2.0 – It’s the law for all future DOD programs)(DODAF 2.0 – It’s the law for all future DOD programs)
Architecture Architecture Ignore at your own riskIgnore at your own risk
(DODAF 2.0 – It’s the law for all future DOD programs)(DODAF 2.0 – It’s the law for all future DOD programs)
Dale WaldoDale Waldo Boeing Associate Technical Fellow - Boeing Associate Technical Fellow -
Systems EngineeringSystems [email protected]@Boeing.com
Lou PapeLou PapeBoeing Associate Technical Fellow - Boeing Associate Technical Fellow -
Systems EngineeringSystems [email protected] [email protected]
6/23/2010 22
Outline• What is System Architecture• DoDAF V2.0
6/23/2010 33
What is Systems Architecture
6/23/2010 44
Systems ArchitectureWikipedia• A system architecture or systems architecture is the
conceptual design that defines the structure and/or behavior of a system.
• An architecture description is a formal description of a system, organized in a way that supports reasoning about the structural properties of the system. It defines the system components or building blocks...and provides a plan from which component products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage...investment in a way that meets business needs
6/23/2010 55
Systems ArchitectureArchitecting: the art and science of designing
and building systems
Table 1: Four Architecting Methodologies
Normative (solution-based)Examples: building codes and communications standards
Rational (method based)Example: systems analysis and engineering
Participative (stakeholder based)Examples: concurrent engineering and brainstorming
Heuristic (lessons learned)Examples: Simplify, Simplify, Simplify… and Scope
Maier & Rechtin- “The Art of Systems Architecting”
6/23/2010 66
Systems Architecture• A system is a collection of different things that together
produce results unachievable by themselves alone. The value added by systems is in the interrelationships of their elements
• Architecting is creating and building structures, i.e., “structuring.” Systems architecting is creating and building systems. It strives for fit, balance, and compromise among the tensions of client needs and resources, technology, and multiple stakeholder interests
• Architecting is both an art and a science -- synthesis and analysis, induction and deduction, and conceptualization and certification - using guidelines from its art and methods from its science. As a process, it is distinguished from systems engineering in its greater use of heuristic reasoning, lesser use of analytics, closer ties to the customer, and particular concern with certification standards and readiness for use
Maier & Rechtin- “The Art of Systems Architecting”
6/23/2010 7
DoDAF DefinitionDoDAF V2.0 is the overarching, comprehensive
framework and conceptual model enabling the development of architectures to facilitate DoD managers at all levels to make key decisions more effectively through organized information sharing across Department, Joint Capability Areas (JCAs), Component, and Program boundaries
It doesn’t tell you how to architect, it tells you how to title and organize your system’s descriptive artifacts
7
6/23/2010 88
What is Good Architecture• A good architecture meets the needs of the
stakeholders (especially the users) to their satisfaction, does not violate principles of system architecture, and takes into account the relevant -ilities by allowing for maintenance, evolution, further development, embedding, etc. as the customer requires
• Really good architectures are also elegant (intellectually clean of unnecessary complexities or 'exceptions'), can direct a builder to cost-effective structures that can be completed within a reasonable time frame, conceptually pleasing to all stakeholders (especially the user), and provide some special advantage (such as a competitive advantage) or utility to the customer
6/23/2010 9
Some Powerful Systems Engineering Heuristics
• All designs are valid if they deliver the performance within the constraints
• System Level Architecture optimizes the specialist disciplines, and constrains them
• Systems need to be built to tolerate change and expansion beyond current stakeholder needs
• System Stakeholders are one more than you know about; and known stakeholders have at least one more need than you know about now
• You cannot economically satisfy all critical stakeholder needs, so the job is to increase value-to-cost ratios in the long term, over current systems
• Don’t ever try to build it all at once – evolve the system based on highest value early, and rapid learning about realities
• Manage the details through focus on high-level measurable objectives, not through bureaucracy
9
6/23/2010 1010
All Design Processes Should Involve
Iteration• All design processes can and should involve
iteration• Many systems are too complex, and many
architects are not competent enough, to do a perfect job on the first pass
• Many data points only become available later in the architecture or design process
• Therefore, every architecture design process should involve iteration; the process should be designed to be conducted over and over again until a satisfactory solution is reached
6/23/2010 1111
The Customer is the Judge of Quality
• An architecture that satisfies the architect but not the customer is useless
• The customer should be involved in the process as much as possible, giving frequent and honest feedback on all aspects of the system architecture
• While the architect may attempt to educate the customer to their mutual benefit, in cases of difference of opinion it is the customer's opinion that matters
6/23/2010 1212
KISS (Keep It Simple,Stupid)
• The architect should strive to adhere to the KISS principle, "keep it simple, stupid."
• The system architecture should be as simple as possible without conflicting with other design principles
• Architectures that are more complex than necessary will result in sub-optimal systems
• This principle is also known as Occam's Razor
6/23/2010 1313
Modeling as a Architectural Tool
• The “systems” we deal with are increasingly complex, as is the environment they operate in– Difficult to comprehend, understand, predict, control,
interface with, explain, etc.– Larger, more complex tasks– Increasingly “Systems of Systems”
• Modeling allows fuller, cheaper exploration of the design space (within limitations)
• Object Mgmt Group (OMG) and INCOSE are Driving Toward Model Driven Development (MDD)/Model Driven Architecture (MDA)– UML 2.0, SysML
6/23/2010 1414
Intro to DoDAF V2.0
Overview:http://cio-nii.defense.gov/sites/dodaf20/products/DoDAF_2-0_web.pdf
Slides:http://www.updm.com/document/OSD,%20EA&S,%20Brief%20to%20OMG,%20DoDAF%20V2,%2020090916.ppt
6/23/2010 1515
• The DOD is:– No longer telling the contractor the solution
they have chosen– Now seeking to leverage the expertise of
the contractor– Seeking to have a choice of the best
options available against which they will write the Systems Requirements Document (SRD)
– Stating their goals for the product in a Statement of Objectives (SOO)
– Asking the contractor to tell them what it really takes to achieve that SOO
DOD Acquisition Landscape has Changed
6/23/2010
Value of DoDAF V2.0 DoDAF V2.0 provides an overarching set of architecture
concepts, guidance, best practices, and methods to enable and facilitate architecture development in a way that will aid DoD managers
Fit-for-Purpose describes an architecture that is appropriately focused and directly supports customer needs or improves the overall process undergoing change. The models provide choices, based upon the decision-maker needs
Facilitates development of architectural descriptions under Service-Oriented Architecture (SOA) - related techniques and tools
Adheres to the DoD Acquisition Life Cycle methodologies contained in the DoD Acquisition Guide
Can be used in conjunction with Lean, Six Sigma and other Process Improvement methods
6/23/2010 1717
DoD Architecture Framework (DoDAF V2.0)
Original DoDAF Views have been expanded to better organize information and reflect data that practitioners
actually use
Modified Viewpoints• The original DoDAF Systems View has been separated into
a Systems Viewpoint (SV) and a Service Viewpoint (SvcV) to accommodate extension to both systems and software/services engineering practice
• All the models of data (Conceptual, Logical, and Physical) have been moved into the Data & Information Viewpoint (DIV)
• The Operational Viewpoint (OV) now describes rules and constraints for any function (business, intelligence, warfighting, etc)
• Technical View (TV) has been updated to the Standards Viewpoint (StdV) to describe business, commercial, and doctrinal standards in addition to technical standards
• The All Viewpoint (AV) is essentially the same
6/23/2010 18
DoD Architecture Framework (DoDAF V2.0)
New Viewpoints• Capability Viewpoint (CV) focuses on Capability data in
support of Capability development and to standardize the capture of capability data
• Project Viewpoint (PV) focuses on the Portfolio Management/Cost Performance information to explicitly tie architecture data to project efforts (what used to be called status charts)
A major new thrust of V2.0 is the term “fit for purpose”• The individual artifacts are intended to be “fit for their
purpose” of documenting, managing, and guiding the system development – not generated specially and uniquely for a high level review
6/23/2010 19
Data &
Information
Viewpoint
OV-7
Services
Viewpoint
SV-11
All “Service”
Versions of
SV Products
Systems
Viewpoint
All “Systems” Versions of SV Products
DoDAF V1.5
Capability
Viewpoint
Project
Viewpoint
Standards
Viewpoint
Operational
Viewpoint
Rest of OVs
All TVs
All
ViewpointAll AVs
DoDAF DoDAF V2.0V2.0
NewUpdated Moved DoDAF Metamodel (DM2)
Fit ForPurpose
PresentationDashboards GraphicalDepictions
ReferenceModels
FusionProducts
CompositeProducts
6/23/2010
Perspectives: Viewpoints That Fit-the-Purpose
Architecture viewpoints are composed of data that has been organized to facilitate understanding.
All V
iew
poin
tO
vera
rchin
g a
spects o
f arch
itectu
re co
nte
xt th
at re
late
to
all m
odels
Data
and In
form
atio
n V
iew
poin
tA
rticula
te th
e d
ata
rela
tionsh
ips a
nd a
lignm
ent stru
cture
s in
the a
rchite
cture
conte
nt
Sta
ndard
s Vie
wpoin
t A
rticula
te a
pplica
ble
Opera
tional, B
usin
ess, T
ech
nica
l, and
Industry
policy
, standard
s, guid
ance
, constra
ints, a
nd
fore
casts
Systems ViewpointArticulate the legacy systems or
independent systems, their composition, interconnectivity, and context providing
for, or supporting, DoD functions
Services Viewpoint Articulate the performers, activities,
services, and their exchanges providing for, or supporting, DoD functions
Operational ViewpointArticulate operational scenarios,
processes, activities & requirements
Capability Viewpoint Articulate the capability requirement,
delivery timing, and deployed capability
Pro
ject V
iew
poin
tD
escrib
es th
e re
latio
nsh
ips b
etw
een o
pera
tional a
nd
capability
require
ments a
nd th
e v
ario
us p
roje
cts bein
g
imple
mente
d; D
eta
ils dependencie
s betw
een ca
pability
m
anagem
ent a
nd th
e D
efe
nse
Acq
uisitio
n S
yste
m p
roce
ss.
6/23/2010 21
DoDAF V2.0 Focus: TermsDoDAF V1.5 DoDAF V2.0
Architecture Architectural Description
Architecture data
Architectural data
Product Model (a template for collecting data)
Product View (a model with data for an architecture)
View Viewpoint• Models are templates for organizing and displaying data in DoDAF 2.0
– Previous versions of DoDAF referred to these as ‘Products’ – An example of a Model is an OV-2, OV-5, SV-1, CV-5
• Views are the result of collecting and populating Models with data and then presenting it
– Views are a Model populated with specific data• Viewpoints are a collection of models/views
– Previous versions of DoDAF just referred to these as ‘Views’– Examples include: All Viewpoint (AV), Operational Viewpoints (OV), Capability
Viewpoint (CV)• The collection of information, specifically Views and/or Viewpoints, used to document
the architecture is referred to as an Architectural Description– Previous versions of DoDAF referred to these as just an ‘Architecture’
Alignment with ISO 42010 and 15407
6/23/2010 22
Methodology: DoDAF V2.0 Six-Step Architecture Development Process
Determine theintended use of the architecture
Determine theintended use of the architecture
1
Determinescope of
architecture
Determinescope of
architecture
2Determine data
required tosupport
architecturedevelopment
Determine datarequired to
supportarchitecturedevelopment
3Collect, organize,
correlate, andstore architecture
data
Collect, organize,correlate, and
store architecturedata
4Conduct
analyses insupport of
architectureobjectives
Conductanalyses insupport of
architectureobjectives
5Document
Results IAWDecision-Maker
needs
DocumentResults IAW
Decision-Makerneeds
6
Provide list of data needed and use
cases
Provide list of data needed and use
cases
3.1
Model toDM2 Concept
List
Model toDM2 Concept
List
Review list of architecture dataand determine if it meets the use
cases
Review list of architecture dataand determine if it meets the use
cases
3.2
DM2 ConceptualData Model &
Logical Data Model
DM2 ConceptualData Model &
Logical Data Model
Assist with the Architect’s
data collectionprocesses
Assist with the Architect’s
data collectionprocesses
4.1
List of architecture
data
List of architecture
data
PotentialCollectionMethods
PotentialCollectionMethods
SelectedCollectionMethods
SelectedCollectionMethods
Verify the datacollected meetsthe use cases
Verify the datacollected meetsthe use cases
5.1
ExampleUses
ExampleUses
Fit-for-PurposeUse
Fit-for-PurposeUse
Determine howdata needs to be
presented
Determine howdata needs to be
presented
6.1
LegacyProducts
LegacyProducts User
Requirements
UserRequirements Example
Presentations
ExamplePresentations
Fit-for-PurposePresentations
Fit-for-PurposePresentations
Detailed Steps forDecision-Maker
With the updated process, DoDAF V2.0 describes Roles and Responsibilities for the Decision-maker throughout the architecture development effort.
6/23/2010 2323
OV -1 is:• Graphical in nature• An easy way to understand what is trying to be
explained by the architecture as a whole• Provides an excellent summary of the architecture
when combined with AV-1• A mission and highlighted primary operational
nodes
•Graphical in nature•One of the work products required for an integrated architecture•A way to track the need to exchange information from specific Operational Nodes (that play a key role in the architecture) to other Nodes
OV -2 is:
6/23/2010 2424
GIG Tactical Theater Communications Infrastructure (OV-1 Example)
Lower TI
Tactical LAN
Upper TI
Link-11
Link-16
Connexion (GMS)Mobile ATM SATCOM
Broadband LOS "Thinroute" Links
Wideband LPI/LPDMobile Ad-hoc Network
Wideband LPI/LPDMobile Ad-hoc Network
Broadband LOS Backbone
Wideband MANET LOSRadio Access Points
Satellite GroundEntry Point
TMIG LOSRadio Access
Point
Fixed Infrastructure
Satellite GroundEntry Point
JTRS
TMIG LOSRadio Access
Point
JTRS
JTRS
UFO / DAMAMILSTAR
(LDR/MDR/AEHF)MUOS
GPS
GPS
AWT(JTRS)
DSCS/Gapfiller(Advanced Wideband)
JTRS
Broadband LOSRadio Access
Point
Broadband LOSRadio Access
Point
Wideband Networking Waveform Capability
Central to Tactical GIG
6/23/2010 2525
Operational Node Connectivity Description OV-2 Example
6/23/2010 2626
The Development Process for Operational Views
OV-1OV-2OV-3OV-4OV-5OV-6aOV-6bOV-6cOV-7
Who Input Process Steps for Operational View Development Output
Use cases
Intended uses
Trace to Requirements
Generate CADM compliant
descriptions
Planner
Owner
Designer
Implementer
Contractor
Develop high level concept
graphic
OV-1
Develop operational
rule
OV-6a
Determine operational state
transition description
OV-6b
Determine operational
activity model
OV-5
Determine operational node
connectivity
OV-2
Develop operational event trace description
OV-6c
Develop information exchange
requirements
OV-3
Capture in integrated model
OV-4
OV-7
Develop Logical Data Model
Develop Organizational
Relationship chart
6/23/2010 2727
A (Not Exactly) Fortuitous Coming Together of UML & DoDAF…
OV-1 High-Level Operational Concept Graphic
HLOC High-Level Operational Concept Graphic (not really UML; more .ppt)
OV-2 Operational Node Connectivity Description
NCD Node Connectivity Description
OV-3 Operational Information Exchange Matrix
SOS System Operational Sequence
OV-4 Organizational Relationships Chart NRD Node Relationship Diagram
OV-5 Operational Activity Model UCD Use Case Diagram or Activity Diagram
OV-6a Operational Rules Model UCS Use Case Specification (Text)
OV-6b Operational State Transition Description
StCD State Chart Diagram
OV-6c Operational Event-Trace Description
OTS Operational Trace Sequences
OV-7 Logical Data Model(Related to AV-2, Dictionary)
CRD, LDM
Class Relationship Diagram, Logical Data Model
DoDAF UML
6/23/2010 2828
Systems Engineering Management and Analysis• Plans/Schedules• Requirements Management• Risk Management• SEIT Coordination
• Subcontractor Management• Closed Loop Corrective Action• TPMs
Customer Requirements
SRR
Requirements Analysis• Mission Requirements
• Requirements Trades
• TPMs
• Requirements Capture
SDR Optimized
System Design
Functional Analysis/ Allocation
• Functional Analysis
• Functional Trade Studies
• Requirements Flowdown
System Synthesis• Design Trade Studies
• Specialty Engineering Integration
• CAIV
• Subsystem Requirements Flowdown
Legacy Program
Information
System Definition
DetailedDesign
System Verification & Evaluation
PrototypeI&T
Design Reviews
SystemIntegratio
n
System Test
Validated System
Systems Engineering Process
6/23/2010 2929
Systems Engineering Management and Analysis• Plans/Schedules• Requirements Management• Risk Management• SEIT Coordination
• Subcontractor Management• Closed Loop Corrective Action• TPMs
Customer Requirements
SRR
Requirements Analysis• Mission Requirements
• Requirements Trades
• TPMs
• Requirements Capture
SDR Optimized
System Design
Functional Analysis/ Allocation
• Functional Analysis
• Functional Trade Studies
• Requirements Flowdown
System Synthesis• Design Trade Studies
• Specialty Engineering Integration
• CAIV
• Subsystem Requirements Flowdown
Legacy Program
Information
System Definition
DetailedDesign
System Verification & Evaluation
PrototypeI&T
Design Reviews
SystemIntegratio
n
System Test
Validated System
Systems Engineering Process
6/23/2010 30
Down Select Was Based Upon Critical
Measures,their Weighting,and the selected
Figureof Merit (FOM)
RequirementsAnalysis
(S&C SEPM 1.2)
RequirementsAnalysis
(S&C SEPM 1.2)
Functional Analysis(S&C SEPM 1.2)
Functional Analysis(S&C SEPM 1.2)
System Synthesis(S&C SEPM 1.3)
System Synthesis(S&C SEPM 1.3)
Down Select Was Based Upon All Measures,
their Weighting, and the selected
Figureof Merit (FOM)
• Determine Which Measures Should Be Used In the Selection
Process• Establish Weights For
Each Measure
Architecture-1
Architecture-2
Architecture-(N)
Concept-1A
Concept-1B
Concept-1N
Concept-2A
Concept-2B
Concept-2N
Testability
Risk
Maintainability
LCC
Non-Recurring
Cost
Schedule
CompetitiveDiscriminators
CustomerBias
Producibility
System A
System B
System (M)
“Best Value”System Concept
System Analysisand Control
(S&C SEPM 1.4)
System Analysisand Control
(S&C SEPM 1.4)
FunctionalPerformance
Cost Estimate(DTUPC)
Concept-NN
Concept-NA
Perform Sensitivity Analysis
Perform Sensitivity Analysis
System Architecture Development
Process
Verification Loop
Document theProcess
Risk Analysis ofFinal System
Concept
Modify concepts tocombine the best features of each
LegacyComponents
Testability
Risk
Maintainability
LCC
Non-Recurring
Cost
Schedule
CompetitiveDiscriminators
CustomerBias
Producibility
FunctionalPerformance
Cost Estimate(DTUPC)
LegacyComponents
TransformArchitectures(Functional to Physical)
• Define Alternative System Concepts• Define Physical Interfaces
Grade Each Concept For The SelectedCritical Measures
Select PreferredProduct andProcess Solutions
Grade Each CandidateConcept for All Measures
Concept-NB
Design Loop
System Architecture Selection Process Steps
System Architecture Selection Process Steps
6/23/2010 3131
"YOU ARE THE STEWARD OF THE WHOLE,NOT THE OWNER OF THE PART.” Dr. John
Pickering