The Golden Spike: Finding Common Ground between Software Architecture Research and Practice

1. The Golden Spike: Finding Common Ground between Software Architecture Research and Practice Eric M. Dashofy June 8, 2004 http://www.isr.uci.edu/

2. Outline • What are the advantages of working to bring together research and practice? • What have the difficulties been in bridging the gap? • What can we do to improve collaborations? • What research directions can we pursue that will satisfy the goals of both researchers and practitioners?

3. A History Refresher • The golden spike joinedthe two halves of thetranscontinentalrailroad in Promontory, Utah in 1869

4. The Advantages of Collaboration • Researchers are assisted in evaluating and validating their research • Find out what works • Find areas for improvement • Practitioners get to evaluate new methods and techniques • Improve processes • Improve products

5. The Difficulties • (Some) different goals • Researchers need to create and publish research results • Practitioners need to create and ship products • Researchers need to do something new • Practitioners need to do something that works • (Some) different constraints • Researchers desireopenness forpublication, widedissemination • Practitioners oftenneed exclusivity,e.g. for gov’trequirements Artist’s Rendering of the Chunnel Effort

6. How can researchers and practitioners find common ground? • Start small • Look for small opportunities to make a connection • Researchers: Shouldn’t expect practitioners to reorient their entire operation around the latest ideas • Practitioners: Shouldn’t expect research ideas to be fully formed and productized • Prepare for growth • Both parties should prepare to capitalize on successful efforts and be thinking of longer-term collaborations • Be proactive in looking for win-win funding opportunities

7. How can researchers and practitioners find common ground? • Balance the use of well-worn/adopted technologies with novel research approaches • Perpetually look for research areas that satisfy common and disparate goals • Areas where there are important, open research questions • Areas where (incremental) improvements will make an immediate difference • Areas where there’s a lot of future potential

8. From a Software Architecture Perspective • Design above the level of modules and classes occurs • But is not principled • or adequately supported • Moving toward principled, supported design at this level has potential benefits: • Better management of software evolution • Better management of run-time changes • Potential for self-governed run-time changes • Better ability to monitor, understand, analyze software • Better ability to understand and explore tradeoffs

9. Key #1: Start Small with Incrementality • All-or-nothing solutions are hard to justify adopting • For any complextechnology, anincrementaladoptionplan iscritical tosuccessfuladoption. Semantics-based Tools (Critics, Ménage, Archipelago, MAE, etc.) Structural Schemas Type System CM Schemas Implementation Schemas Syntax-basedTools (Apigen, Data BindingLibrary, ArchEdit) Increased Adoption XML

10. Incrementality in ISR Architecture Technologies • xADL 2.0 • Adopt structural modeling • Adopt our type system • Adopt implementation mappings • Adopt product variations (options and variants) • Adopt product evolution (versioning) • Our tools • Adopt tools for supporting the syntax of the notation • Adopt tools for supporting the semantics of the notation

11. Key #1: Start Small with Incrementality • All-or-nothing problem domains are hard to work on • Applying new technologies or techniques to complete, huge systems over multiple dimensions is infeasible • The full details of huge systems are often classified or proprietary

12. Types & Instances - Design-time CM/Product Families (Versions, Options, Variants) xArch – Run-time (Architectural Instances Core) Implementation Mappings (Future Expansions) Key #2: Grow Big with Extensibility • Many research projectshave viewed extensibility as an afterthought • We have found that whenextensibility is a primary (or the first) concern, our ownlong-term research goalsmysteriously becomeeasier to achieve • Spending time developingthe extension mechanismsfirst pays dividends

13. Extensibility in ISR Architecture Technologies • xADL 2.0 • Chose and designed the extension mechanisms first • Leveraged off-the-shelf technology (XML schemas) • Language constructs designed to be extended • ArchStudio 3 • Designed the framework first • Chose a loosely-coupled architectural style for easy extensibility • Archipelago • Designed the plugin mechanism first • Applied well-known design patterns pervasively

14. Key #2: Grow Big with Extensibility • Practitioners can look to open up areas of their development processes, particularly in the design phase • Prioritize extensibility in tool choices • Look for and choose off-the-shelf tools that have some open mechanisms and let researchers know these tools are important

15. Key #3: Play nice with other kids • As researchers, it’s our job to find deficiencies in existing technologies and techniques • And remedy them • Compromise betweenbuilding a bettermousetrap and adaptingan existing one IEEE 1471

16. Key #3: Play nice with other kids • Practitioners will continue using off-the-shelf technologies, but should be open to replacing or augmenting them with research technologies • With the understanding that research techniques and tools (especially) will not have evolved to the point of some of these well-seated standards

17. Key #4: Find a Common Area • The “holy grail” of research-practice collaborations in architecture has been a research area that • Contains lots of interesting, “big” research questions • Is valuable to practitioners in the short-term • Is important to practitioners in the long-term • Provides incremental opportunities for success • I believe such a research area is emerging and will fundamentally change the direction of architecture research

18. Systems Architecture • Application of architecture techniques to software systems in context • Models aspects of the hardware that affect system qualities • Models quantifiable, analyzable aspects of software components and connectors • Provides strong traceability to implementation • Facilitates powerful tradeoff analysis • Facilitates multi-level understanding of complex systems

19. Systems Architecture Requirements PhysicalElements SoftwareElements Systems Architecture ImplementationMappings Implemented Elements

20. Systems Architecture (offboard) Requirements SingleBoardComputer NIC PhysicalElements SoftwareElements ImplementationMappings DBMS LegacySystem Implemented Elements

21. Systems Architecture (offboard) OS = QNXProcessor = PPCMhz = 500RAM = 256M Requirements SingleBoardComputer NIC PhysicalElements Media = EthernetBandwidth = 10Mbps SoftwareElements Link = PCIBusSpeed = 100Mhz ImplementationMappings DBMS LegacySystem Implemented Elements OS = VMSProcessor = 68KMhz = 40RAM = 4M TPS = 200MaxTables = 255MaxRecords = 64K

22. Systems Architecture Requirements PhysicalElements SoftwareElements ImplementationMappings Implemented Elements

23. Systems Architecture Requirements PhysicalElements Footprint = 256KPeriod = 1.0 secPowerUse = .02W SoftwareElements ImplementationMappings Type = BusFootprint = 4KPeriod = 0.2 secPowerUse = .01W Implemented Elements

24. Systems Architecture Requirements PhysicalElements Footprint = 256KPeriod = 1.0 secPowerUse = .02W -OR-FootPrint = 512KPeriod = 0.5 secPowerUse = .03W SoftwareElements ImplementationMappings Implemented Elements

25. Systems Architecture Requirements • UML? • Mapped to components? • Generated? • Extended with propertiesgarnered from the architecture? PhysicalElements SoftwareElements ImplementationMappings Implemented Elements

26. ISR Technologies and Systems Architecture • ISR technologies map well onto needs of systems engineering • Extensible notations • Allow the addition of new views • Allow the modeling of new types of properties • Adaptable environments and editors • Allow for addition of new semantics and diagrams • Strong focus on product-line modeling and sculpting • Required for expressing and managing tradeoffs • Leverage off-the-shelf technologies • Needed to integrate in larger processes

27. Summing Up • Start out small • Incrementality • Grow big • Extensibility • Play nice • Open technologies, tools, and processes • Integrate where possible • Look for opportunities • Systems architecture will provide a plethora of mutually beneficial research endeavors