architecture-based drivers for system-of-systems and family-of- systems cost estimating gan wang,...

Architecture-Based Drivers for System-of-Systems and Family-of-

Systems Cost Estimating

Gan Wang, Phil Wardle, Aaron Ankrum

BAE Systems

June 25, 2007

Presented to the INCOSE 2007 Symposium page 2

Wisdom of Dilbert


Agenda

Problem

Two Perspectives of Capability

Architecture-Based Cost Drivers

Conclusions and Further Work


It’s Your and My Tax Dollars!

Program AgencyAcquisition

CostUnit Cost

Acquisition Cycle Time

Joint Strike Fighter (JSF)*

Joint $224B $91M 16 years

Future Combat Systems (FCS)*

Army$164B - $234B

$8.8B 12 years

Future Aircraft Carrier CVN-21*

Navy $30B $10B 12 ½ years

Global Hawk Unmanned Aircraft*

Air Force $9B $168M 6 ½ years

Tornado Airframe Availability

MoD £1.5B 10 years

*Source: GAO reports


IssueRFP

Submit Proposal

Award of Contract

Design Reviews

EnterService

End ofService

PDR CDR FCA/PCA

70% ofTotal Ownership Cost Committed 85% of

Total Ownership Cost Committed 90% of

Total Ownership Cost Committed

CONCEPT ASSESSMENT MANUFACTURE IN SERVICE DISPOSALDEMONSTRATION

SDR

SDR = System Design ReviewPDR = Preliminary Design ReviewCDR = Critical Design ReviewPCA = Physical Configuration AuditFCA = Functional Configuration Audit

IOC/FOC

FOC = Full Operational CapabilityIOC = Initial Operational Capability Affordability Under

Regular Review

Affordability in Decision Making

Is this capability affordable if we adopt

the proposed solution?


Life Cycle Decision Trade Framework

LCC EstimatesEconomicAnalysisROI, NPVPortfolio Mngt.…

Program RisksTechnical MaturityVulnerability…

Program Schedule OperationalRoadmaps…

PerformanceFunctionalityInteroperabilityKPPs, MOEs …

FeasibilityStudy

…

Go/No-goMake/Buy

…

Go/No-goMake/BuyContract

…

DeploymentIOC, FOC

…

Lifecycle Support

…

Tech Insertion

…


Problem Statement

Develop architecture-based estimating methods/models to provide rough order of magnitude (ROM) estimates for Life Cycle Cost (LCC) of system-of-systems (SoS) and family-of-systems (FoS)

US DoD: “Total Ownership Cost” (TOC)

UK MoD: “Through Life Cost” (TLC)

Provide basis for decision making in capability-based acquisition

Cost of Capability, rather than just the System

Applied in concept/pre-concept phases

This presentation addresses only part of this problem


Agenda

Problem





AircraftCarrier

AircraftSquadron

DocksideFacility

Operational View of capabilities, roles, missions

e.g. supports the ‘top-table’ discussion between system integrator and the customer

Understanding Capability

CJCSI 3170.01E Definition: “The ability to achieve a desired effect under specified standards and conditions through combinations of means and ways to perform a set of tasks.

Two perspectives on Capability: “Operational” and “Material”

Material View of systems and people

e.g. supports discussions between system integrator and major subcontractors

Source: US Army


Activity 1

Activity 6 Activity 5

Activity 8Activity 3

Activity 7

Activity 4

Activity 2

Capability Thread B.1




Operational Perspective

Mission Thread A.1

Mission Thread A.1

Mission Thread A.1

Mission Thread A.1


Material PerspectiveSoS / FoS Work Breakdown Structure

Le

vel 1

Le

vel 2

Le

vel 3

ConceptPhase WBS

Technology Phase WBS

SDD Phase WBS

P&D Phase WBS

O&S Phase WBS

Phase/Spiral Plan

Capability Model

Lifecycle Support

Operational Requirements

Member Systems

Peer Systems

Comms Infrastructure

ValidatedSoS

Integrated & Verified SoS

Deployed SoS

Customer Acceptance

Processes and Resources

Existing Infrastructure

AddedInfrastructure

Current Systems 1..n

Trading System

Architecture Alternatives

Processes, Facilities and Resources for

Project Delivery

Performance, Cost, and Time Requirements

– “shalls”, “shoulds”

Current Systems 1 .. n

Retired Systems n+1 .. n+k

PeerSystems 1 .. n

Test and Integration


Operational Facilities and

Resources


Connecting The ViewsArchitecture Based Cost Estimation

Operational Perspective Material Perspective

DOTMLPF Representation(similarly UK MoD “lines ofdevelopment” - TEPIDOIL)

Captured in DoDAF(similarly MoDAF)

CERs

Mapping

SoS / FoS Work Breakdown Structure

Lev

el 1

Lev

el 2

Lev

el 3

ConceptPhase WBS

Technology Phase WBS

SDD Phase WBS

P&D Phase WBS

O&S Phase WBS

Phase/Spiral Plan

Capability Model

Lifecycle Support

Operational Requirements

Member Systems

Peer Systems

Comms Infrastructure

ValidatedSoS

Integrated & Verified SoS

Deployed SoS

Customer Acceptance


Existing Infrastructure

AddedInfrastructure

Current Systems 1..n

Trading System

Architecture Alternatives

Processes, Facilities and Resources for

Project Delivery

Performance, Cost, and Time Requirements

– “shalls”, “shoulds”

Current Systems 1 .. n

Retired Systems n+1 .. n+k

PeerSystems 1 .. n

Test and Integration


Operational Facilities and

Resources


Agenda

Problem





Architecture Based Cost Drivers

1. Number of Operational Nodes

2. Number of Mission-level Operational Scenarios

3. Number of Operational Activities

4. Number of Nodal Information Exchange Boundaries

5. Number of Key (Enabling) Technologies

6. Number of Member Systems

7. Number of Peer Systems

8. Operational Resource/Staffing Level

Capturing the Size of SoS/FoS From Life Cycle PerspectiveCapturing the Size of SoS/FoS From Life Cycle Perspective


AV

-1

AV

-2

OV

-1

OV

-2

OV

-3

OV

-4

OV

-5

OV

-6a

OV

-6b

OV

-6c

OV

-7

SV

-1

SV

-2

SV

-3

SV

-4

SV

-5

SV

-6

SV

-7

SV

-8

SV

-9

SV

-10a

SV

-10b

SV

-10c

SV

-11

TV

-1

TV

-2

AV OV SV TV

Source and Traceability

DoDAF Views

ConceptRefinement

TechnologyDevelopment

System Development& Demonstration

Production &Deployment

Operations &Support

Pre-Systems Acquisition Systems Acquisition Sustainment

Life CycleImpact

OV

-2

SV

-1



Operations &Support

Operational Nodes

An Operational Node is an organizational structure that may represent an operational role, an organization, or an organizational type, whichever is appropriate for the context; typically, it consists of human operators and systems that they operate on

Operational Nodes can be defined by geographic locations (e.g., fixed or mobile sites), or functional and logical groupings (e.g., logistic function, intelligence function)

Count the “Operational Nodes” at the SoS / FoS level using the OV-2 view


Use Case Example (1)

Tier 1 Ashore &Support Sites

Tier 1 Afloat

Tier 2 Ashore & Support Sites

Tier 2 Afloat

Concentrator

BUC

Physical

External

Logical

T1:AshDCGS-N

T1:AflDCGS-N

T2:AshDCGS-N

T2:AflDCGS-N

DCGS-NEnterprise

ConcDCGS-N

OV-02 D1.1_L0_NormalOperations (OV-02 Op. NodeConnectiv ity), READ ONLY

System ArchitectFri Jul 22, 2005 07:57

Comment

UNCLASSIFIED**DRAFT**

LEGEND

T1:Ash W eaponsand Mission

Planning

T1:Afl W eaponsand Mission

Planning

T2:Ash W eaponsand Mission

Planning

T2:Afl W eaponsand Mission

Planning

SCI ExternalCustomer

TheaterData

Source

SecretExternal

Customer

T1:AshCommand and

Control

T1:AflCommand and

Control

T2:AshCommand and

Control

T2:AflCommand and

Control

BUCDCGS-N

T1:Ash UHFReceiver

T1:Afl UHFReceiver

T2:Ash UHFReceiver

T2:Afl UHFReceiver

SIGINTData

Source

OrganicData

Source

GEOINTData

Source

NTMData

Source

CollectionPlanning

Conc DCGS-N-DCGS-N Enterprise

SIGINT Data Source-T1:Ash DCGS-N

SIGINT Data Source-T1:Afl DCGS-N

SIGINT Data Source-T2:Ash DCGS-N

SIGINT Data Source-T2:Afl DCGS-N

T1:Ash DCGS-N-DCGS-N Enterprise

DCGS-N Enterprise-T1:Ash DCGS-N

T2:Afl DCGS-N-DCGS-N Enterprise

DCGS-N Enterprise-T2:Afl DCGS-N

T2:Ash DCGS-N-DCGS-N Enterprise

DCGS-N Enterprise-T2:Ash DCGS-N

T1:Afl DCGS-N-DCGS-N EnterpriseDCGS-N Enterprise-T1:Afl DCGS-N

T1:Ash UHF-T1:Ash DCGS-N T1:Ash DCGS-N-

T1:Ash C2

T1:Ash C2-T1:Ash

DCGS-N

T1:AshDCGS-N-

T1:AshW eapons

T1:AshW eapons-

T1:AshDCGS-N

T1:AflW eapons-

T1:AflDCGS-N

T1:Afl DCGS-N-T1:Afl

W eaponsT1:Afl C2-

T1:AflDCGS-N

T1:Afl DCGS-N-T1:Afl C2

T1:Afl UHF-T1:Afl DCGS-N

T2:Ash UHF-T2:Ash DCGS-N T2:Ash DCGS-N-

T2:Ash C2

T2:Ash C2-T2:Ash

DCGS-N

T2:AshDCGS-N-

T2:AshW eapons

T2:AshW eapons-

T2:AshDCGS-N

T2:AflW eapons-

T2:AflDCGS-N

T2:AflDCGS-N-

T2:AflW eapons

T2:Afl C2-T2:Afl

DCGS-N

T2:AflDCGS-N-T2:Afl C2

T2:Afl UHF-T2:Afl DCGS-N

Manual Transfer

Organic Data Source-T1:Afl DCGS-N Manual

Organic Data Source-T1:Ash DCGS-N Manual

Organic Data Source-T2:Afl DCGS-N Manual

Organic Data Source-T2:Ash DCGS-N Manual

GEOINT-T1:Ash DCGS-N

GEOINT-T2:Afl DCGS-N

GEOINT-T2:Ash DCGS-N

GEOINT-T1:Afl DCGS-N

SCI External Customer-T1:Ash DCGS-N

SCI External Customer-T1:Afl DCGS-N

SCI External Customer-T2:Ash DCGS-N

SCI External Customer-T2:Afl DCGS-N

S External Customer-T1:Ash DCGS-N

S External Customer-T2:Afl DCGS-N

S External Customer-T2:Ash DCGS-N

S External Customer-T1:Afl DCGS-N

SIGINT Data Source-T1:Ash UHF

SIGINT Data Source-T1:Afl UHF

SIGINT Data Source-T2:Ash UHF

SIGINT Data Source-T2:Afl UHF

T2:Afl DCGS-N-S External Customer

T2:Ash DCGS-N-S External Customer

T1:Afl DCGS-N-S External Customer

Organic Data Source-T2:Afl DCGS-N

Organic Data Source-T1:Afl DCGS-N

Organic Data Source-T2:Ash DCGS-N

NTM Data Source-Conc DCGS-N

Conc DCGS-N-NTM Data Source

Conc DCGS-N-BUC DCGS-N

Conc DCGS-N-T1:Afl DCGS-NT1:Afl DCGS-N-Conc DCGS-N

Conc DCGS-N-T2:Afl DCGS-N

T2:Afl DCGS-N-Conc DCGS-N

T1:Ash DCGS-N-Conc DCGS-N

Conc DCGS-N-T1:Ash DCGS-N

T2:Ash DCGS-N-Conc DCGS-N

Conc DCGS-N-T2:Ash DCGS-N

Theater Data Source-T1:Afl DCGS-N

Buc DCGS-N-Conc DCGS-N

Collection Planning-T2:Afl DCGS-N

Collection Planning-T2:Ash DCGS-N

Collection Planning-T1:Afl DCGS-N

T2:Ash DCGS-N-SCI External Customer

T1:Afl DCGS-N-SCI External Customer

T2:Afl DCGS-N-SCI External Customer

T1:Ash DCGS-N-SCI External Customers

Collection Planning-T1:Ash DCGS-N

Theater Data Source-T1:Ash DCGS-N

Organic Data Source-T1:Ash DCGS-N

T1:Ash DCGS-N-S External Customer

Theater Data Source-Conc DCGS-N

1

2 3

4

5

6

7

There are three types of nodes: Logical, Physical, and External

We use Logical Nodes for our driver quantity – total is seven

There are also have six physical nodes and eight external nodes

Source: US Navy

OV-2


AV

-1

AV

-2

OV

-1

OV

-2

OV

-3

OV

-4

OV

-5

OV

-6a

OV

-6b

OV

-6c

OV

-7

SV

-1

SV

-2

SV

-3

SV

-4

SV

-5

SV

-6

SV

-7

SV

-8

SV

-9

SV

-10a

SV

-10b

SV

-10c

SV

-11

TV

-1

TV

-2

AV OV SV TV


DoDAF Views

ConceptRefinement




Operations &Support


Life CycleImpact

Information Exchange Boundary

OV

-2

OV

-3

SV

-2

SV

-3



The boundary between two operational nodes in the SoS/FoS for information exchange purposes; a boundary describes the information exchange needs from a producing node to a consuming node; it isn’t necessarily a physical data channel

The base measure is a count of pairs of producing and consuming nodes; if the information flow is bi-directional then the boundary count is two

Derived measures may include the number of data elements, data types, and the number protocols required to support the information exchange


Use Case Example (2)

External Boundaries

There are two types of boundary: Internal and External

Total of 19 Internal Total of 65 External Overall total = 84

Source: US Navy


Agenda

Problem





Conclusions

Architecture based cost drivers based on DoDAF views have been identified to be the “big movers” for LCC; the proposition is that these can be used for parametric estimating of ROM costs of future SoS / FoS projects

One step in developing a Architecture Based Cost Estimating model/method

The concept has been presented to stakeholder groups within BAE SYSTEMS, the academic community, and customer community in the US and UK

Stakeholders have acknowledged

a definite need for ROM estimating methodology at pre-concept/concept phase of life cycle

the potential for an architecture-based approach to SoS / FoS estimating for the earliest stages of the lifecycle and as a basis for senior-level decision making, e.g., go/no-go, AoA trades

the potential for improving our strategic decision making capability


Further Work

Strawman model(s) and CERs for architecture based estimating method, based on combination of heuristic-based analysis and data validation

Bridge between architecting and estimating communities; guidelines and process to better capture architecture for estimating purposes

Interactive trade space where cost and performance are linked to enable AoA tradeoffs and communications of decisions to stakeholders


Questions & Comments

Gan WangGan Wang

[email protected]

Phil Wardle Phil Wardle

[email protected]

Aaron Ankrum Aaron Ankrum

[email protected]

mailto:[email protected]




Operational Scenarios

AV

-1

AV

-2

OV

-1

OV

-2

OV

-3

OV

-4

OV

-5

OV

-6a

OV

-6b

OV

-6c

OV

-7

SV

-1

SV

-2

SV

-3

SV

-4

SV

-5

SV

-6

SV

-7

SV

-8

SV

-9

SV

-10a

SV

-10b

SV

-10c

SV

-11

TV

-1

TV

-2

AV OV SV TV


DoDAF Views

ConceptRefinement




Operations &Support


Life CycleImpact

An “operational Scenario” is a sequence of interconnected activities or course of action at mission level that is triggered by an external situation or event, such as a threat alert or emerging need, resulting in the achievement of a mission objective or outcome

Count the “Operational Scenarios” in terms of end-to-end threads at mission level

It is possible that a given objective or outcome may be achieved by multiple operational scenarios


Operational Activities

AV

-1

AV

-2

OV

-1

OV

-2

OV

-3

OV

-4

OV

-5

OV

-6a

OV

-6b

OV

-6c

OV

-7

SV

-1

SV

-2

SV

-3

SV

-4

SV

-5

SV

-6

SV

-7

SV

-8

SV

-9

SV

-10a

SV

-10b

SV

-10c

SV

-11

TV

-1

TV

-2

AV OV SV TV


DoDAF Views

ConceptRefinement




Operations &Support


Life CycleImpact

Operational Activities are major tasks performed in support of a mission objective or outcome; they can be subdivided - a single activity can be decomposed to a series of activities at the next level breakdown

Count the “Operational Activities” for each mission-level operational scenario

We define Operational Activities at the mission level and they are building blocks of the Operational Scenarios


Key Technologies

AV

-1

AV

-2

OV

-1

OV

-2

OV

-3

OV

-4

OV

-5

OV

-6a

OV

-6b

OV

-6c

OV

-7

SV

-1

SV

-2

SV

-3

SV

-4

SV

-5

SV

-6

SV

-7

SV

-8

SV

-9

SV

-10a

SV

-10b

SV

-10c

SV

-11

TV

-1

TV

-2

AV OV SV TV


DoDAF Views

ConceptRefinement




Operations &Support


Life CycleImpact

Technologies that enable and underpin the mission capabilities under consideration

An example of a “technology” might be the Service-Oriented Architecture for an integrated Intelligence, Surveillance, and Reconnaissance (ISR) capability

A technology could be either under development for the SoS / FoS being estimated, or could be an established technology but with rework issues such as refresh or mitigation of obsolescence


Member Systems

AV

-1

AV

-2

OV

-1

OV

-2

OV

-3

OV

-4

OV

-5

OV

-6a

OV

-6b

OV

-6c

OV

-7

SV

-1

SV

-2

SV

-3

SV

-4

SV

-5

SV

-6

SV

-7

SV

-8

SV

-9

SV

-10a

SV

-10b

SV

-10c

SV

-11

TV

-1

TV

-2

AV OV SV TV


DoDAF Views

ConceptRefinement




Operations &Support


Life CycleImpact

“Member Systems” comprise component parts of the SoS / FoS

Count the “Operational Systems” and “Life Cycle Support Systems” at each Operational Node; these may be created from scratch (to achieve new capabilities) or enhanced (to improve legacy capabilities)

Operational Systems directly contribute to the achievement of a SoS / FoS mission objective or outcome

Life Cycle Support Systems typically contribute to ongoing system development, integration, calibration, and maintenance


Peer Systems

AV

-1

AV

-2

OV

-1

OV

-2

OV

-3

OV

-4

OV

-5

OV

-6a

OV

-6b

OV

-6c

OV

-7

SV

-1

SV

-2

SV

-3

SV

-4

SV

-5

SV

-6

SV

-7

SV

-8

SV

-9

SV

-10a

SV

-10b

SV

-10c

SV

-11

TV

-1

TV

-2

AV OV SV TV


DoDAF Views

ConceptRefinement




Operations &Support


Life CycleImpact

“Peer Systems” are part of some other SoS / FoS and under some other line of command and control, yet they interact with the SoS / FoS of interest

Count the “Peer Systems” so as to take account of their effect on the cost of integration for the SoS /FoS of interest

Member Systems from the SoS / FoS of interest may have to interface with Peer Systems in order to enable and underpin the achievement of a mission objective or outcome; achievement of the interface relies on negotiation and collaboration to establish the interface protocols


Operational Resources

AV

-1

AV

-2

OV

-1

OV

-2

OV

-3

OV

-4

OV

-5

OV

-6a

OV

-6b

OV

-6c

OV

-7

SV

-1

SV

-2

SV

-3

SV

-4

SV

-5

SV

-6

SV

-7

SV

-8

SV

-9

SV

-10a

SV

-10b

SV

-10c

SV

-11

TV

-1

TV

-2

AV OV SV TV


DoDAF Views

ConceptRefinement




Operations & Support


Life CycleImpact

Staffing level of the operators represents the operational resources involved in the day-to-day delivery of mission objectives or outcomes

The staffing level is typically represented in an organizational structure with an arrangement of responsibilities, authorities and relationships; it can also be represented by functions and roles

The staffing levels can be counted as number of people or as number of operational units of a uniform size, e.g., battalion as in military unit

architecture-based drivers for system-of-systems and family-of- systems cost estimating gan wang,...

Documents

operational perspective

problem slide

number of operational

work slide

view slide

information exchange

material perspective

us army slide