1. Page 1 6/30/2015 Reconciling Systems, Software, and other Architectures Mark W. Maier, Ph.D. Distinguished Engineer The Aerospace Corporation © 2008 The Aerospace Corporation,

2. Page 2 6/30/2015 Topics To Consider l Reconciliation of what? »Of “Architectures” (treated as decisions)? »Of “Architecture Descriptions?” »Of programs and processes? l A discussion of the need to “reconcile system and software architectures” may be something of a cover for a variety of problems »A desire for common notations and tools (whether needed or not) »Poor compatibility between basic architectural decisions about the software with basic architectural decisions about the hardware within the system being developed »Poor compatibility between basic architectural decisions about the program with basic architectural decisions about the system being developed »Inefficient ordering of information developed in software-centric systems l We’ll consider the major cases in turn

3. Page 3 6/30/2015 Architecture and Program Sequence l Take software- centric or intensive as meaning 70-80% of development is spent on software development l Then, architecting of software will/must start early, before systems engineering is complete, and will be very enduring l Needs at system level induced by software architecture should have priority

4. Page 4 6/30/2015 Top Down vs Bottom Up Architecting l Stakeholders »Stakeholder Concerns »System level use-cases and objectives l Software architecture »Identification of the logical structure of the software »Concurrency and synchronization requirements, induced by software boundary Objectives-driven Function-centric Value-based invariants Design-needs-driven Object-centric Design-based invariants Many areas likely to gap Typically poor attention to HW/SW drivers Mismatched SE and SW-Architecture order

5. Page 5 6/30/2015 Program and System l Systems engineering classically looks in physically oriented hierarchies l Software is now more typically structured in layers »At least in modern, complex systems l What happens when the WBS is written to follow the systems hierarchy, not the software layers? l Classic example of mismatch of the structure of the program (via the system) with the structure of the software to be developed by the program

6. Page 6 6/30/2015 Which are the Subsystems? Backbone Interface Layer Shared Functions Platform Unique

7. Page 7 6/30/2015 The Four Way Tension Organization Who’s doing what? One or several? What are they good/bad at? What is their “strategic identity?” System What are we building? What are the key tech decisions? What are the components? How is it tested? Problem What are we doing? What delivers value? What is the environment? What is success? Program How do we build/operate? Separation of responsibilities

8. Page 8 6/30/2015 A Little Exercise Question l What aspects of the problem domain lead you to make a decision in favor of incremental development? »What aspects of the problem domain lead you to make a decision to avoid any sort of incremental development? l Given that you want an incremental development architecture for the program… »How does it (should it) change the architecture of the system? What system architectures are “consistent” with incremental development, and which ones are not? »How does it change design decisions in supporting areas (e.g. testing, verification, validation)? »How does it effect the organization that carries out development and the supported missions?

9. Page 9 6/30/2015 Notations and Methods l Lack of attention to notations and methods may be the problem l Or, too much attention to notations and methods may be the problem »Can’t fix bad decisions by changing the description framework l And…it can also be part of a solution l The “right” notation can directly incorporate the bottom-up concerns of software developers l The right notation composition rules can support explicit layering, and parallel subsystem decomposition l The right descriptions can highlight issues between the system and program

10. Page 10 6/30/2015 Some Pieces to Use Hard-coupled Push Hard-coupled Pull Soft-coupled Push Soft-coupled Pull Queued Transfer Blocking Push Blocking Pull

11. Page 11 6/30/2015 Conclusions l Bringing architecture (and architecture description) together among systems and software is important stuff l But…the systems/software divide is only part of the story l Consider from the position of fundamentals »Things (software, systems, programs) have architectures. Those architectures are formed from the basic structural decisions. »Compatibility means (largely) consistent, coherent decisions between and among those levels –Between hardware and software –Between problem and system-solution –Between system, program, and organization »Compatibility of “architecture descriptions,” (models and documents) also is an issue »Good choices in tools and methods can help with compatibility, but isn’t a panacea