Mark W. Maier, Ph.D. Distinguished Engineer The Aerospace Corporation Mark.w.maier@aero

1. Clean Sheet Design of an SE&I Structure Based on Existing Government (NASA) and Industrial Institutions Mark W. Maier, Ph.D. Distinguished Engineer The Aerospace Corporation Mark.w.maier@aero.org

2. Outline • Considerations for designing SE&I for Exploration Systems • Understand where the SE&I problem is situated • Core functions and system categories • System category: System versus Collaborative System, technology level • Alternative futures for Exploration Systems • Classic model: Purpose driven, ultraquality, solid stakeholders, high technology • Internet counterpoint: What successful SE&I looks like in a collaborative system • Considerations applied, some design principles • No-Regrets, Big-Bets • Discussion with regard to other SE&I organizations

3. A Brief Introduction • I am a Distinguished Engineer at The Aerospace Corporation • Aerospace is the Architect-Engineer for National Security Space. Aerospace is a non-profit, FFRDC, kind of the canonical implementation of that model for SE&I. • I am part of the functional, engineering side of a matrix organization • Primary responsibilities in system architecting, system portfolio management • Especially relevant publications/References • Maier, M. W., and Rechtin. E., The Art of Systems Architecting, Second Edition, CRC Press, 2000 • Maier, M. W., Architecting Principles for Systems-of-Systems, Systems Engineering, 1:4, pp 267-284, 1998 • Rechtin, E., Why Eagles Can’t Swim: The Systems Architecting of Organizations, CRC Press, 2001 • Maier, M. W., The Art and Science of Systems Architecting, coursebook, www.aero.org

4. Key Messages • Base assumption • Exploration Systems core function is to build and operate space systems • Why you build them, what you accomplish, and who else builds and operates are different stories • The kind of systems you build matters (a lot) to how SE&I needs to be conducted • We need to identify the system (or environment) attributes that discriminate among SE&I practices • Of central importance is whether the vision is for an extremely complex but monolithic system, or for a “collaborative system” (aka system-of-systems) • Where Exploration Systems falls is not immediately obvious • It may follow the Apollo model, or it may not. • This will have a major influence on how SE&I should be conducted, and on the appropriate organization

5. An Engineer’s Assumption • Exploration System’s core function is to build and operate systems • Some may argue exploration is the core, but: • Absent building some large systems the envisioned exploration isn’t going to happen • Nobody else is going to build most of them, and if they did we would not regard it as a successful outcome (or would we?) • Systems are not all alike. SE&I is not conducted effectively using the same approaches on all systems • A bad approach will (often has) led to bad outcomes • Our first order of business should be to understand the nature of our systems, and the relationship between that nature of SE&I practices

6. Taxonomies and Discriminatory Power • A classification is just a division into groups such that members of the group share properties not shared with members of other groups • Division by location (space, air, ground) • Division by technology (electrical, software, etc.) • Division by acquirer (government, commercial) • By presence of certain types of attributes (e.g. ultraquality) • and many others • A classification or taxonomy is useful if things in different categories need to be treated differently (in design, development, or operation) • So, many taxonomies are not useful, and useful taxonomies are not unique • What are the relevant useful taxonomy dimensions here? • I’ll take “space” and ultraquality as very important, but given • I’m more interested in the “unexpected” ones

7. Three Useful Dimensions Scope Collaborative system, aka System-of-systems Multi-function/stakeholder system Single function/stakeholder system Super-High Low Medium High Purpose Driven Technology Level Technology Driven Motivation Capability Driven This model is an extension of Aaron Shenhar’s

8. Technology Level • Definitions • Low: Everything off-the-shelf • Medium: All components available, but some are not production mature • High: Some components are only at laboratory maturity, must be further developed as part of program • Super-High: Fundamental advances required • Thought experiments • If a system were correctly classified as “High Technology” how should its management differ from one correctly classified as “Medium Technology?” • What happens if you manage a High technology program as if it were Medium? • Is successful management of a Super-High technology program more or less formal and rigorous than of a High technology program?

9. Motivation and Scope • Motivation for the system • Purpose-driven means the objectives/requirements come from the funding stakeholders (the easiest, simplest case) • In technology-driven systems the builds assume requirements (based on technology), then discover the real ones in the market • In capability-driven what the builder provides is adapted in use by others. Success is determined by eventual use, not by requirements. • Scope (of system environment, not system complexity) • Single function, single stakeholder systems at one end • Collaborative systems at the other (see next slide) • The classic model for the space business is single stakeholder, purpose-driven, high technology • The greatest successes have been here • The familiar model of systems engineering was born here (think of how Apollo was system engineered)

10. What Is a System-of-Systems? • Since there is always a system/subsystem hierarchy, anything could be considered a S-of-S • From a laptop to the national satellite system • But, I believe that the real category is defined by: • Various subtypes (closed, open, virtual) also defined • Note: I usually call this a “Collaborative System” 1. Integrated elements have emergent properties (form a proper system) 2. Operational Independence of System Elements: Each system element fulfills valid purposes in its own right. If the system is disassembled the separate elements continue to function. 3. Managerial Independence of System Elements: Limited centralized control. System elements are, at least in part, managed for their own purposes

11. Where’s Exploration Systems? • If it is another Apollo • Purpose driven, multi-function/stakeholder (NOT a system-of-systems or collaborative system), high technology (might be super-high, don’t know) • What else might it be? • If end goals are expected to flex in an uncontrolled way, then purpose-driven becomes capability-driven • If NASA (US Gov) cannot/will not meet the desired goals individually, then the enterprise becomes a collaborative system (probably open, if international), or gets stuck in no-mans-land (point #3 without point #2) • Would these shifts matter? • Definitely. Classic centralized SE&I processes typically fail when applied to capability-driven, collaborative systems. • A significant literature on this exists. Read “Rescuing Prometheus” by Thomas Hughes to go with your Apollo book

12. Apollo’s Counterpoint, The Internet Web Application Web Application Web Application • The Internet is arguably the most complex human system ever, how was/is it SE&I’d? • Central authority with directive power does not exist • “Standards” controlled by IETF, IETF has no legal standing • Structure and operating rules of IETF (and associated organizations) collaborative and international in very fundamental ways • Basic organizing structure is layers, not the classic system/subsystem hierarchy • Technical choices foster, not control unanticipated change • Ultraquality is not required, but robust operation is • Parallels in SE&I social structure, technical structure, system structure FTP SMTP HTTP Others TCP UDP Others IP Ethernet X.25 HDLC Others

13. Tiers and Layers • Tiers (as in the NRC report) and layers (as in communications and software) are not the same, but are related • Comm protocols achieve interoperability by “hourglassing” • Software achieves commonality by bottom-up integration/libraries • Tiered SE&I management can choose different strategies for different tiers, and upper tier strategies may execute horizontally at lower tiers • Example: Deep Space Exploration • Top tier is an Open Collaborative System • Missions are typically purpose-driven monolithic systems • DSN is an integrating system, structured as a Closed Collaborative System • A given comm layer cross-cuts the DSN and multiple programs, but may not ever be a consideration in the cross-cutting upper tiers

14. Exploration Alternative Futures • Apollo to Mars • Assumptions: Sustained National (or international consortium) commitment to manned exploration of Mars, expressed in a unified way. Nothing beyond laboratory technology needed to do it. • Approach: Rebuild the classic, centralized PM/SE organization with all the classic space knowledge bases. Open the money faucets, build the labs. • Problem: When commitment flags there is no step back • NASA the Navigator (apologies to Prince Henry) • Assumptions: Commitment to explore, not to means or ends, and the commitment waxes and wanes over time. Missions will result from voluntary and dynamic groupings of sponsors and builders. But, the right infrastructure will greatly increase mission volume and quality. • Approach: Good question, but centralized SE probably isn’t it • Problem: Don’t want to do ELDO. Not clear if successful approaches from other markets can work in the space business, or if limited robotic success can be extended. • Are there others?

15. Using Alternative Futures • Alternative futures are used by examining invariant and variant outcomes • Look for things that are good in all futures: No Regrets • Look for things good in only one/few futures: Big Bets • Some cases to consider • Is having decentralized SE for a launch vehicle ever a good idea? • When is having a for-profit system integrator for the top tier a good idea? • Is deep technical knowledge of space critical to SE&I in all futures, or only some? • When, if ever, is conflict of interest a minimal problem? • When would strongly internationalized organizations be the most useful? When would they be an impediment? • Will the mixture of inherently-governmental concerns change over time? Is it single-ended or episodic?

16. Deep, stable expertise in space technology and issues Freedom from conflict of interest For monolithic segments (e.g. launch vehicles) classically rigorous SE Substantive independence Ability to rethink basic architectures Effective connections with principal sponsors (political level, scientific community) Rigorous, centralized SE at the top tier Anything other than rigorous, centralized SE at the top tier Layered structures for systems with ultraquality requirements Fundamentally internationalized organizations Anything other then fundamentally internationalized organizations Choices for SE&I No Regrets Big Bets Note: Some big bets are inescapable

17. Integrating the Story: Questions • Questions your group should ask itself this afternoon in the groups • Should we bet on one of the alternative futures? If so, which one? What happens if we are wrong? • If we assume that the major segments (e.g. launch vehicles, CEV) have to be centrally system engineered, does it follow that the tier above that has to be as well? What is the minimum level of upper tier integration I need (as opposed to what we might want for efficiency purposes)? • Which organizational options are best at obtaining the No-Regrets attributes? Which are best at which Big-Bet attributes? How does the alternative future impact their priority? • What horizontal systems (physical or virtual) will be/should be present in the Exploration enterprise? Can/should they be SE’d the same way as the vertical segments? • Is there a technically/economically/politically stable mixture of cross-cutting and vertical systems that would make a Collaborative System possible?