Architecture Ignore at your own risk (DODAF 2.0 – Its the law for all future DOD programs) Dale Waldo Boeing Associate Technical Fellow - Systems Engineering.

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