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. Presented to the INCOSE 2007 Symposiumpage 2 Wisdom of Dilbert

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

4. Presented to the INCOSE 2007 Symposiumpage 4 Its Your and My Tax Dollars! ProgramAgency Acquisition Cost Unit Cost Acquisition Cycle Time Joint Strike Fighter (JSF)* Joint$224B$91M16 years Future Combat Systems (FCS)* Army $164B - $234B $8.8B12 years Future Aircraft Carrier CVN-21* Navy$30B$10B12 ½ years Global Hawk Unmanned Aircraft* Air Force$9B$168M6 ½ years Tornado Airframe Availability MoD£1.5B10 years *Source: GAO reports

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

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

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

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

9. Presented to the INCOSE 2007 Symposiumpage 9 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

10. Presented to the INCOSE 2007 Symposiumpage 10 Operational Perspective

11. Presented to the INCOSE 2007 Symposiumpage 11 Material Perspective

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

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

14. Presented to the INCOSE 2007 Symposiumpage 14 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 Perspective

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

16. Presented to the INCOSE 2007 Symposiumpage 16 Use Case Example (1) 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

17. Presented to the INCOSE 2007 Symposiumpage 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 isnt 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

18. Presented to the INCOSE 2007 Symposiumpage 18 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

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

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

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

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

23. Presented to the INCOSE 2007 Symposiumpage 23

24. Presented to the INCOSE 2007 Symposiumpage 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

25. Presented to the INCOSE 2007 Symposiumpage 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

26. Presented to the INCOSE 2007 Symposiumpage 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

27. Presented to the INCOSE 2007 Symposiumpage 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

28. Presented to the INCOSE 2007 Symposiumpage 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

29. Presented to the INCOSE 2007 Symposiumpage 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