1. University of Southern California Center for Systems and Software Engineering Integrating Systems & Software Architecting Workshop Participants Problem space examples Followed JAL approach: two full pages of (20) issues –All Issues, refactored as appropriate –Issues with an incomplete list of proposed solutions Bottom line summary of Issues

2. University of Southern California Center for Systems and Software Engineering Architecture Workshop Participants Art Pyster, Stevens Inst. Tech (WDC) David Klappholz, Stevens Inst. Tech (NJ) Bruce Amato, OSD J. D. Baker, BAE Systems Pongtip Aroonvatanaporn, USC CSSE Ramin Moazini, Sun Microsystems & USC CSSE Itti Charoenthongtrakul, USCCSSE Clyde Chittister, SEI Ed Colbert, USC CSSE & Absolute Software Jinbo Chen, NGC A Winsor Brown, USC CSSE & ISTI Charles Driessnack, SAIC Barry Boehm, USC CSSE

3. University of Southern California Center for Systems and Software Engineering

4. University of Southern California Center for Systems and Software Engineering Problem Space by Examples From ARR WBS & Organizations Fractionated, incompatible sensor data management Domain-Specific Reference Architectures Effect of Software Underrepresentation

5. University of Southern California Center for Systems and Software Engineering 03/19/2008 ©USC-CSSE 5 Effect of Software Underrepresentation Software risks discovered too late Slow, buggy change management Recent large project reorganization SW (WBS-based) PM Sys EngrSoftwareC4ISR SensorsNetworks SW New

6. University of Southern California Center for Systems and Software Engineering 03/19/2008 ©USC-CSSE 6 Fractionated, incompatible sensor data management “Touch Football” interface definition earned value –Full earned value taken for defining interface dataflow –No earned value left for defining interface dynamics Joining/leaving network, publish-subscribe, interrupt handling, security protocols, exception handling, mode transitions –Result: all green EVMS turns red in integration Examples of Architecture Mismatches … Sensor 1 SDMS1 Sensor 2 SDMS2 Sensor 3 SDMS3 Sensor n SDMSn ……

7. University of Southern California Center for Systems and Software Engineering Domain-Specific Reference Architectures … Examples: ADAGE avionics reference architecture June 3, 20157

8. University of Southern California Center for Systems and Software Engineering © USC CSSE 2008 8 Workshop Issues, Goals, and Approach –Discuss architecting (system/SW; NDI legacy; concurrent requirements/architecture engineering) –Identify, prioritize key architecting issues –Discuss solution approaches for top-priority issues –Evaluate degree of payoff, difficulty of solution approaches on 0-10 scale –Prepare summary briefing

9. University of Southern California Center for Systems and Software Engineering 9 What is a software architecture? The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. - Len Bass, Paul Clements, Rick Kazman, SEI, 2003 The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. - Len Bass, Paul Clements, Rick Kazman, SEI, 2003 An architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution - IEEE 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems An architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution - IEEE 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems The system architecture is the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors. - INCOSE

10. University of Southern California Center for Systems and Software Engineering 03/19/2008 ©USC-CSSE 10 System/Software Architecture Mismatches - Maier, 2006 System Hierarchy –Part-of relationships; no shared parts –Function-centric; single data dictionary –Interface dataflows –Static functional-physical allocation Software Hierarchy –Uses relationships; layered multi-access –Data-centric; class-object data relations –Interface protocols; concurrency challenges –Dynamic functional- physical migration

11. University of Southern California Center for Systems and Software Engineering Top level issues (1/3) 1.(11) Inconsistent ways of viewing the entities – system architect looks at things thru functional allocation mentality – sw architect looks at things as reusable objects – a different perspective – different notations – makes it harder to move work from system architects to software architects. The sw and hw engineers use different notations/vocabularies – the way we discuss the logic of how we construct hw and sw are different. Hw and sw engineers have trouble communicating – use the same word to mean different things. Some se won’t use sw terms such as “class” (point of contention – some believe SEs shouldn’t deal with classes). We need ways to represent ideas about systems and their solutions for analysis and communication 2.(11) Too many people think of swe architecting and se architecting as separate disciplines 3.(8) How to decide in the first place what to have the hw do and what to have the sw do 03/19/2008 ©USC-CSSE 11

12. University of Southern California Center for Systems and Software Engineering Top level issues (2/3) 4.(6) Definition of terms from a domain perspective or discipline perspective - even system engineers use the same term differently and have trouble communicating among themselves – likewise for software engineers 5.(6) Chief engineers who come up the career ladder from hw and other traditional engineering disciplines don’t know or respect sw engineering 6.(6) Sw engineers are often not in the discussions from the beginning when requirements and architecture, etc. are established 7.(6) Sw architects and SE architects have different experiences – they grow up in different worlds – and so they see the world differently 03/19/2008 ©USC-CSSE 12

13. University of Southern California Center for Systems and Software Engineering Top level issues (3/3) 8.(4) Models are incompatible between SWE and SE 9.(3) SEs and SWEs focus on different levels of abstraction – what and how 10.(3) Change will happen to both system and sw architecture – how do we efficiently make sure the two architectures remain consistent 11.(2) Many SW Engineers aren’t “real” engineers 12.(1) SEs spend more time on paper than SWEs do – SWEs use more real models 13.(0) The way we talk about funding and testing is different between hw and sw 14.(0) With sw systems on generic ubiquitous hw, hardware/software integration is not an issue 03/19/2008 ©USC-CSSE 13

14. University of Southern California Center for Systems and Software Engineering Issue 1 Inconsistent ways of viewing the entities – system architect looks at things thru functional allocation mentality – sw architect looks at things as reusable objects – a different perspective – different notations – makes it harder to move work from system architects to software architects 1.We need compatible representations and terminology and models that cover both sw and se concepts and solutions that can be used for both analysis and communication 2.We need training on terminology, representations and models for both SEs and SWEs 3.We need to validate that the uniform representations, models, and terminology really work 4.There needs to be active on the job mentoring of SWEs on systems engineering – the goal is for a SWE to become a SE 5.SEs should know something about SWE – but don’t expect them to become SWEs – they need mentoring 6.Career path should encourage movement between SE and SWE 7.Controversial: SE and SWE should be combined into a single discipline 8.SE and SWEs should have an understanding of the other discipline 9.Establish an industry/government team to create uniform representations, etc. – include vendors – go beyond sysml 10.Rosetta stone between systems and software terminology 03/19/2008 ©USC-CSSE 14

15. University of Southern California Center for Systems and Software Engineering Issue 2 Too many people think of sw architecting and system architecting as separate (stovepiped) disciplines 1.Teach everyone to do both SWE and SE architecting 2.Achieving the last chart mitigates this issue as well. 03/19/2008 ©USC-CSSE 15

16. University of Southern California Center for Systems and Software Engineering Issue 3 How to decide in the first place what to have the hw do and what to have the sw do 1.Develop patterns and antipatterns to guide hw sw allocation. 2.Develop domain specific architectures 3.Integrating teams of SWEs and SEs 4.Propagating what is easy and what is hard for HW and SW to do 5.Having the common notations, etc. help achieve this 03/19/2008 ©USC-CSSE 16

17. University of Southern California Center for Systems and Software Engineering Issue 4 Definition of terms from a domain perspective or discipline perspective - even system engineers use the same term differently and have trouble communicating among themselves – likewise for software engineers 1.Training and mentoring the organization what the organization wants for systems engineering and software engineering 2.Get an industry/government team that is multi-discipline and multi- domain to identify and define terminology and taxonomies 3.Create domain architectures, domain models, reusable components, etc. that span software and systems engineering 4.Propagate through industry associations 5.Create “relatively” open architectures 03/19/2008 ©USC-CSSE 17

18. University of Southern California Center for Systems and Software Engineering Issue 5 Chief engineers who come up the career ladder from hw and other traditional engineering disciplines don’t know or respect sw engineering 1.Educate the chief engineers on software engineering 2.Make knowing software engineering a condition of becoming a chief engineer 3.If we “unify” the two subjects, then the problem goes away 4.Chief engineers should get a masters degree in software engineering 03/19/2008 ©USC-CSSE 18

19. University of Southern California Center for Systems and Software Engineering Issue 6 Sw engineers are often not in the discussions from the beginning when requirements and architecture, etc. are established 1.An organizational policy solution: no early stage system architecting activity be allowed to proceed without software architects being involved 2.Software architect should sign off on the system architecture 03/19/2008 ©USC-CSSE 19

20. University of Southern California Center for Systems and Software Engineering Issue 7 Sw architects and system architects have different experiences – they grow up in different worlds – and so they see the world differently 1.Encourage career moves that cross-train software and system architects 2.Encourage educational approaches that cross-train software and system architects 03/19/2008 ©USC-CSSE 20

21. University of Southern California Center for Systems and Software Engineering Bottom Line Summary 03/19/2008 ©USC-CSSE 21 Solutions 1.Workshop specifically focusing on issue of integrating system and software architecting Issues 1.Systems architecting and software architecting have grown up as separate disciplines and cultures, whereas to produce high quality products, they need to be unified either partially or completely. 2.Because of the separation, engineers on each side tend to be “ignorant”, “suspicious”, “disrespectful” of the other side. Most early career systems architects are from systems engineering and may not bring in software architects early enough with the result that their projects often get in trouble.