Systems and Software Architecting for “the Many” -- Some Research Challenges of SoS

1. USC/CSSE Convocation, 2006 (Systems, Software and People) Systems and SoftwareArchitecting for “the Many”-- Some Research Challengesof SoS Stephen C-Y. Lu, Ph.D. David Packard Chair in Manufacturing Engineering Director, Product Development Engineering Program Founding Director, the IMPACT Research Laboratory University of Southern California Los Angeles, California USA 90089 Tuesday, October 24, 2006 – Los Angeles, California

2. Prologue… • My research interest is in design theory & methodology for engineering systems. For example, • How should a design team collaborate to reach sound and rationale system decisions? • How can we encourage and improve the level of innovation in engineering systems design? • Specifically, I have been working on basic researches in • Collaborative engineering (close collaboration) • Technological innovation (open innovation) • I have the benefit of pre-viewing some of your slides to • Learn new perspectives from experts in systems and software • Share my viewpoints from design, collaboration, & innovation • Ask a few critical questions that may stimulate new thinking • Explore basic research challenges for our common interests

3. ** Categories for organizing views – Axelband *** Creating and building complex systems – Rechtin Basic Premises… • As our world becomes “flat”… • Internet revolution; Web 2.0 era; globalization; etc. • From “Power of the Few” to “Power of the Many” • System of Systems is definitely in – beyond scaling* • The social and technical spiral interaction • The evolutionary and emergent property • The dynamic and evolving complexity • It is “not your father’s” old systems and software engineering (SSE) anymore! • The SSE filed has reached a Strategic Inflection Point • Nothing less than fundamental changes will do.. • What is your “soapbox” in this new flatten world? • A new framework** and architecting*** approach for SoS * Nielsen

4. Boehm System of Systems Social System Technical Systems Austin Determinism / Physics  relation Technical System  variable Socio-technical System (System of Systems) Nielsen  stakeholder Social System  organization Constructionism / Preferences SoS is a system which is comprised of systems that are independently developed and managed, having their own purposes and can dynamically come and go – Boehm What is System of Systems (SoS)? SoS = a set of interacting technical systems (i.e., relations & variables) that are being collaboratively worked on by a network of stakeholders in organizations (i.e., a dynamic social system) to jointly perform some desired functions.

5. What do you want to achieve? How do you propose to achieve it? ? HOW WHAT Engineering Decision Making ? ? ? WHAT HOW (WHY) (WHY) Design Engineer / System Engineer Service (WHO) (WHO) Marketing Engineering The Traditional Technical Paradigm

6. Interaction WHO (Stakeholder) The Social Dimension The Technical Dimension systematically model social interactions among stakeholders within a team dynamically manage the socio-technical cycles based on the agreement Understanding WHAT (Goal) Agreement HOW (Decision) collaboratively negotiate conflicts; make participative joint decision with a group preference consistently aggregate group preferences based on a common understanding Teamwork Taskwork Preference WHY (Rationale) A Socio-Technical SoS Framework A Socio-Technical Framework for SoS

7. Process/Stage of SoS Framework • Who (stakeholder) • A common goal (based on the shared value) • Sufficient expertise • What (goal) • Common understanding of the given goal • Communal understanding of roles w.r.t. the problem • Why (rationale) • Aggregate multiple preferences to form a group preference, or • (when a group preference fails)  identify conflicts • How (decision) • Make a participative joint decision (PJD): agreement • or, manage conflicts and negotiate consensuses CE Team Social Stage 1 Administer Social Interactions Common Understanding Stage 2 Aggregate Multiple Preferences Manage the socio-technical cycle Group Preference or Conflicts Stage 3 Negotiate Joint Decisions PJD or Team Agreement Technical

8. Control Output Input Function Mechanism FEEDBACK FEEDBACK FEEDBACK IDEF0 Definition of SoS Framework Social Construction Mechanisms IDEF0 Functional Definition a common understanding of goal & task Social Choice Models WHO (stakeholder) WHAT (goal) Administer Social Interactions a group preference or identified conflicts 1 a collaborative engineering team Collaborative Negotiation Methods WHY (rationale) Aggregate Multiple Preferences an agreement committed by team members 2 • a given goal • sufficient expertise • limited resources • time bound • autonomy HOW (decision) Negotiate Joint Decisions 3 • a common understanding of the taskwork goal • a common understanding of task dependencies • a common understanding of stakeholder roles • available continuous social choice models • a group preference, or identified conflicts • each stakeholder’s BATNAs (or EATNAs) • negotiation protocols

9. System Architecting Customer Needs Functional Requirements Design Parameters Process Variables How ? What? Who? Conceptual Design Detail Design Function Assignment What? How ? Why? Function Assignment (Social) (Socio-Technical) (Technical) Preference of the Customer Physics of the Nature SoS Architecting as an Design Task • SoS architecting can be treated as an engineering design task: • Design the right thing (choose innovative functional requirements) • Design the thing right (generate creative design concepts) • Detail technical design (produce accurate technical specifications)

10. You Should Never Mix FR with DP Functional Requirements (FRs) and Design Parameters (DPs) are two very DIFFERENT things - they should not be mixed • They should be architected in different DOMAINS (see next) • FRs are WHAT you want/wish/choose to achieve • Designer’s (not customer’s) choices, i.e. “wish-list” from CNs • Conceptual and abstract (not in the physical world) • Not subjected to the limitations of physics and resources • Ideally, they should be based on implementation-free thinking • They should be written down (and read) as “verbs” • DPs are HOW you propose to achieve the chosen WHAT • Designer’s creative choices derived from FRs – the real thing • Less conceptual and abstract (in the physical world) • Subjected to the limitations of physics and resources • Practically, they should lead to actionable parameters • They should be written down (and read) as “nouns”

11. Approach to Systems Architecting • The old-fashion way: • Ad-hoc process  jumping around • Unable to deal with complex systems • Chaos, unstable, costly, time consuming practice • The current systems engineering approach: • 1-D architecture  hierarchical decomposition • Can control the abstraction, but not the dependency • Resulting systems are often fragile and not robust • The advanced engineering design approach: • 2-D architecture  mapping and decomposition • Can deal with both abstraction and dependency • Can yield highly modularized and robust systems

12. Mapping what how X (realized-by) Customer Domain Functional Domain Physical Domain Process Domain Y abstract Layer I Layer II CNs FRs DPs PVs Functional Hierarchy Physical Hierarchy Decomposition Layer III Layer IV detail Socio- Technical SOCIAL Layer N (part-of) TECHNICAL Axiomatic Design (AD) Architecture • “Zig-zag” maneuver from CN-i to PV-n in a 2-D space • AD suggests 2 axioms to guide zig-zaging operations

13. Mapping CN1 Constraint Decomposition CN1 = Food preservation FR1 = Cool the food DP1 = a refrigerator PV1 = Refrigerator manufacturing process Decompose from DP1 FR1-1 = Keep food Within specific Ts DP1-1 = ? Constraint From PV1 Mapping From FR1-1 DP1-1 FR1-2 = Maintain uniform Temperature within the box DP1-2 = ? “Zigzagging” Architecting Process

14. Two Fundamental Design Axioms • The 1st Axiom (Independence Axiom) • Always maintain the independence of FRs • Choose independent and minimal FRs to satisfy CNs • Ensure each FR is independently satisfied by a DP • Uncoupled; Decoupled; Coupled design • The 2nd Axiom (Information Axiom) • For those designs satisfy the 1st axiom, the best one has the minimal information content • Information content is defined in terms of its probability of satisfying a specific FRs

15. Physical Coupling Functional Coupling Resulting Design (A) Bad Design Design (A) YES NO (B) Design (B) Good Design NO NO Design (C) (C) Better Design NO YES Water Faucet Example CN = having a comfortable shower FR1 = to regulate water flow FR2 = to control water temperature DP1= Hot valve PD2= Cold valve DP1= Up-down move PD2= Side-side move

16. FR DP mapping decomposition FR1 FR2 FR4 FR3 DP1 DP2 DP3 DP4 FR23 DP23 13 Phases of a Typical Lunar Mission DP22 FR21 DP21 FR22 Real Case: NASA’s CEV System* * From “Complexity in Engineering,” by N. P. Suh, CIRP Keynote, 2006 • Level 0 Functional Requirements (FRs): • FR1 = carry crews to the moon from Earth • FR2 = carry crews from the moon to Earth • FR3 = carry cargo to the moon from Earth • FR4 = carry cargo from the moon to Earth • Some examples Constraints (Cs): • C1 = Max. no. of crew members is N both ways • C2 = Max. cargo weight is W1 from Earth to moon • C3 = Max. cargo weight is W2 from moon to Earth • C4 = test flight by 2008 • Level 0 Design Parameters (DPs): • DP1 = LV and CEV human (CEV-H) system • DP2 = CEV human (CEV-H) system • DP3 = LV and CEV cargo (CEV-C) system • DP4 = CEV cargo (CEV-C) system

17. (B) (A) Decoupled Design Coupled Design (achieve independent control of all 4 FRs – less complex) (more complex) 2 Different System Architectures* * From “Complexity in Engineering,” by N. P. Suh, CIRP Keynote, 2006

18. (Maintain a decoupled design) FRs/DPs Architecting for Option B* * From “Complexity in Engineering,” by N. P. Suh, CIRP Keynote, 2006 • Level 1 Functional Requirements (FRs): • FR11 = lift (CEV-H with emergency power & fuel) from Earth to in-space site • FR12 = lift (LM-H with emergency power & fuel) from Earth to in-space site • FR13 = lift RTS from Earth to in-space site • FR14 = transport (CEV-H & fuel + LM-H) from in-space site to lunar orbit • FR15 = land the crew on the moon from lunar orbit • FR16 = assemble (LM-H with emergency power & fuel) to LM-H and RTS • FR17 = fuel RTS • FR18 = lift fuel • Level 1 Design Parameters (DPs): • DP11 = ELV-1 • DP12 = ELV-2 • DP13 = ELV-3 • DP14 = RTS • DP15 = LM-H • DP16 = assembly station • DP17 = fuel station • DP18 = ELV-4

19. Conclusion: Implications to SoS • SoS is more than just bigger and bigger systems! • How to architect the socio-technical system framework? • How to manage the evolutionary emergent behavior? • How to control the dynamic system complexity? • SSE architecting plays a critical role in SoS • Must simultaneously deal with dependency & abstraction • Must explicitly model the stakeholder interactions as part of the system architecture – constructionism • Engineering design research can offer some helps • Design theory and methodology • Collaborative engineering

20. For More Information… • International Journal of Collaborative Engineering • http://www.inderscience.com/ijce • Engineering Collaboration via Negotiation @ CIRP • http://wisdom.usc.edu/ecn and http://www.cirp.net • Collaboration Science and Technology @ USC • http://wisdom.usc.edu/cst • MS in Product Development Engineering (MSPDE) • http://wisdom.usc.edu/mspde and http://den.usc.edu/programs/mspde • Socio-Technical Framework for Collaborative Design • http://wisdom.usc.edu/stf • Stephen Lu (personal website) • http://wisdom.usc.edu/stephenlu