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

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
  govtrequirements

Artists 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 Shouldnt expect practitioners to
  reorient their entire operation around the latest
  ideas
• Practitioners Shouldnt 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 theres 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, anincrementaladoptio
  nplan 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
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, its 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