Characterizing and Managing System Architectures Rick Steiner Raytheon Systems Company

1. Characterizing and Managing System Architectures Rick Steiner Raytheon Systems Company Naval and Maritime Systems San Diego, California fsteiner@west.raytheon.com Steiner 1

2. Confusion About the Term “Architecture” • Don’t bother distinguishing “design” from “architecture”… it’s pointless! • All concepts eventually need to be defined to the point where they can be implemented • Why is “System Architecture” such a contentious term? Conflicting views… and a spectrum of abstraction • Highly precidented systems: Architecture = which version to use • Software systems: Architecture = layers of support systems/services • Network systems: Architecture = servers/routers, protocols, topology • System integrator: Architecture = interface specifications/standards • User: Architecture = user interface, scenarios, function, acceptance method • Unprecidented systems: Architecture = development approach, guidelines, process contstraints, validation concept • Complex systems: Architecture = strategy for segregation of subsystems • Christopher Alexander: Architecture = “a timeless way of building” Steiner 2

3. What does an Architecture DO? • Applies “structure” or “framework” to technical endeavor • Aid technical decision management • provide a mechanism for cohesion • vehicle to focus the customer, user, and builder on what is important • information hiding (don’t sweat the small stuff) • translation between operational, technical, and production domains • Characterizing Architectures - orthogonal approaches: • Hierarchies • level of Abstraction (indenture: supersystem, system, subsystem) • level of detail (confidence, design rationale) • detail increases as design develops; not a good way to characterize architecture • View: Form vs. Function, etc. (domain specific, can be generalized) • Permanence: Enduring vs. Transitory (temporal aspect of architecture deployment) Steiner 3

4. Abstract Abstraction Concrete Transitory Enduring Structural Permanence Behavioral View Approach to an Integrated Architecture Model Ideally, this entire space should be filled by the system architecture concept: A Solid Cube! We need a way to identify things that are inconsistent or missing! Steiner 4

5. Abstract Abstraction Concrete Abstraction Axis • Continuum from Abstract to Concrete • Abstract - design guidelines, integration principles, “vision” of product • concept level, understandable by user or customer • Concrete - implementable design • buildable by domain specialist • Abstraction across views • layers of consistent form & function • Abstraction across permanence • discrete points for identifying reuse Steiner 5

6. Structural Behavioral View View Axis • Two relevant aspects: Structure (form) and Behavior (function). • Many other views, most are sub-setsof these two (Wright ADL, Oliver) • Behavior: states, modes, functions, information models, input/output relationships, transfer functions, software performance models • use cases and interaction diagrams are only partial descriptions of behavior • integration of these threads yields system behavior, and engineering is required to do that • Structure: components, interfaces, pinouts, voltages, software modules, hardware & software configuration items • software is buildable, hence it is “structure”. It must be tested to behavioral requirements. • Consistency of form & function architectures at a given level of abstraction and/or detail Steiner 6

7. Abstract “Boehm Spiral” Abstraction Concrete Structural Expression Behavioral Abstraction - View Plane • “Traditional” SE approach starts “abstract” and ends “concrete”, BUT: • Need to deal with multiple levels of abstraction simultaneously • Need to control “rigidity” of design, which changes over time within each abstraction level • B & S balance at each progressive level of abstraction • Completion and Consistency criteria at each technical milestone • Clear statement of design objectives to engineering team leaders during each phase of development Steiner 7

8. Transitory Enduring Permanence Permanence Axis • Continuum from Enduring to Transitory • Used to explore: lifecycle design, potential changes in stakeholder roles, technology insertion, COTS dependencies • Used to establish “Anchor points” of system architecture: • human system interface, logistics, support chain, safety, reliability • conscious identification of enduring aspects of architecture • consistent with business strategy, core competence • establish tech insertion, reuse goals • minimize COTS risk on long-life programs • proprietary data and interfaces • unplanned upgrades • identify aspects of architecture that are “throw away” • Enduring aspects at multiple levels • reuse of top level concepts (manage demands on subsystems) • reuse of subsystems (design for flexibility) • reuse of standards, protocols Steiner 8

9. Abstract Abstraction Concrete Transitory Enduring Permanence Abstraction - Permanence Examples Strategy for legacy system integration Interface management principles Pragmatic design/ integration details Protocols, data exchange standards Steiner 9

10. Transitory Enduring Structural Behavioral View - Permanence Examples legacy components key interfaces legacy protocols partitioning of core processing Steiner 10

11. Management of Enduring Architectures: Some Thoughts • Enduring architectures have strategic significance • Focus core business competence on enduring architectures • minimize internal on transitory aspects… do just enough to meet immediate needs, or subcontract to someone else • don’t allow transient aspects to subsume your entire business! • factor in how transitory aspects change • set rollout dates, focus on transition plans • be flexible when considering enduring aspects, but don’t be driven by short term concerns • Standards aren’t always enduring, but they have their place • see beyond the immediate standard to the long term need • don’t rely solely on a standard to solve an evolvability or technology insertion problem! • identify evolutionary technology needs, then look at standards • COTS systems are transitory • enduring COTS architectures belong to the vendor, not the integrator Steiner 11

12. What Next? • Rules for consistency checking across the integrated architecture model… how do we know when something is missing? • Capture of real architectures using the integrated model concept • how to deal with permanence axis in architecting tools? • Have not adequately distinguished product system from producing system • product - producing system relationships need special attention, especially along permanence axis Steiner 12

13. Backup Steiner 13

14. Who Needs an Enduring Architecture? Steiner 14

15. Examples of Classification of Architecture Elements Steiner 15

16. Architecture Endurance Across Multiple Systems • Maturation vs. Evolution (distinguished as in biology) • long life, complex, integrated systems tend to mature over time (single system “lifetime”) • weapon systems, traffic control systems, public infrastructure/utilities • shorter life, self-contained systems tend to evolve (generation to generation) • computer systems, consumer electronics, automotive • Growth Architecture -> system maturation • P3I, tech insertion • Evolutionary Architecture -> system evolution • core competencies, open interfaces, standards Steiner 16

17. Form, Function & Evolutionary Architectures Steiner 17