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

1. Architecture-Based Drivers for System-of-Systems and Family-of-Systems Cost Estimating Gan Wang, Phil Wardle, Aaron Ankrum BAE Systems June 25, 2007

2. Wisdom of Dilbert Presented to the INCOSE 2007 Symposium page 2

3. Agenda • Problem • Two Perspectives of Capability • Architecture-Based Cost Drivers • Conclusions and Further Work Presented to the INCOSE 2007 Symposium page 3

4. It’s Your and My Tax Dollars! *Source: GAO reports Presented to the INCOSE 2007 Symposium page 4

5. Affordability in Decision Making Is this capability affordable if we adopt the proposed solution? Presented to the INCOSE 2007 Symposium page 5

6. Go/No-go Make/Buy Contract… Deployment IOC, FOC … Lifecycle Support … Tech Insertion … Feasibility Study … Go/No-go Make/Buy … Life Cycle Decision Trade Framework Performance Functionality Interoperability KPPs, MOEs … Program Schedule Operational Roadmaps … Program Risks Technical Maturity Vulnerability … LCC Estimates Economic Analysis ROI, NPV Portfolio Mngt. … Presented to the INCOSE 2007 Symposium page 6

7. 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 Presented to the INCOSE 2007 Symposium page 7

8. Agenda • Problem • Two Perspectives of Capability • Architecture-Based Cost Drivers • Conclusions and Further Work Presented to the INCOSE 2007 Symposium page 8

9. Material View of systems and people Source: US Army e . g . supports discussions between system integrator and major subcontractors 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” Presented to the INCOSE 2007 Symposium page 9

10. Operational Perspective Presented to the INCOSE 2007 Symposium page 10

11. Material Perspective Presented to the INCOSE 2007 Symposium page 11

12. Mapping CERs Connecting The Views Architecture Based Cost Estimation Operational Perspective Material Perspective Captured in DoDAF (similarly MoDAF) DOTMLPF Representation (similarly UK MoD “lines of development” - TEPIDOIL) Presented to the INCOSE 2007 Symposium page 12

13. Agenda • Problem • Two Perspectives of Capability • Architecture-Based Cost Drivers • Conclusions and Further Work Presented to the INCOSE 2007 Symposium page 13

14. Architecture Based Cost Drivers • Number of Operational Nodes • Number of Mission-level Operational Scenarios • Number of Operational Activities • Number of Nodal Information Exchange Boundaries • Number of Key (Enabling) Technologies • Number of Member Systems • Number of Peer Systems • Operational Resource/Staffing Level Capturing the Size of SoS/FoS From Life Cycle Perspective Presented to the INCOSE 2007 Symposium page 14

15. 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 Presented to the INCOSE 2007 Symposium page 15

16. 5 1 4 6 2 3 7 Use Case Example (1) OV-2 • 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 Presented to the INCOSE 2007 Symposium page 16

17. Information Exchange Boundary • 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 Presented to the INCOSE 2007 Symposium page 17

18. Use Case Example (2) • There are two types of boundary: Internal and External • Total of 19 Internal • Total of 65 External • Overall total = 84 External Boundaries Source: US Navy Presented to the INCOSE 2007 Symposium page 18

19. Agenda • Problem • Two Perspectives of Capability • Architecture-Based Cost Drivers • Conclusions and Further Work Presented to the INCOSE 2007 Symposium page 19

20. 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 Presented to the INCOSE 2007 Symposium page 20

21. 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 Presented to the INCOSE 2007 Symposium page 21

22. Questions & Comments Gan Wang gan.wang@baesystems.com Phil Wardle phil.wardle@baesystems.com Aaron Ankrum aaron.ankrum@baesystems.com Presented to the INCOSE 2007 Symposium page 22

23. Back Up Presented to the INCOSE 2007 Symposium page 23

24. Operational Scenarios • 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 Presented to the INCOSE 2007 Symposium page 24

25. Operational Activities • 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 Presented to the INCOSE 2007 Symposium page 25

26. Key Technologies • 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 Presented to the INCOSE 2007 Symposium page 26

27. Member Systems • “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 Presented to the INCOSE 2007 Symposium page 27

28. Peer Systems • “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 Presented to the INCOSE 2007 Symposium page 28

29. Operational Resources • 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 Presented to the INCOSE 2007 Symposium page 29