Continuous Architecture

Development of high quality complex software, in particular in modern embedded and cyber-physical systems, requires careful attention to the software architecture and design in order to achieve the desired quality attributes. Generally speaking, the evolution in software development methods during the last decade, towards more agile practices with short iterations and early feedback, has focused more on implementation and validation activities than architectural design. It is sometimes argued, even, that the concept of architecture is obsolete in modern software development. However, architectural decisions still have a significant impact on software quality, including crucial aspects like performance, safety and security. Moreover, although architecture can, and should, evolve over time, it does so at a slow pace compared to implementation changes, meaning that the architecture impacts how quickly new functionality can be implemented in response to changed market needs. Thus, for any long-lived systems, but in particular for systems where for example safety assurance is critical, there is definitely a need to document and reason about architecture. Architectural documentation no longer plays the role of a static, a priori, specification for developers to follow, but should rather be viewed as an artifact that continuously evolves together with the implementation.

An overall characterization of the research carried out within the Continuous Architecture theme over the last ten years, is that it to a large extent addresses the challenges that arise when balancing the need for architectural quality and more agile ways of working, with shorter development cycles: How do we balance quick-fixes and long-term quality? How can the agile principles be extended from pure software to mechatronic products? How do we work efficiently with other evolving artifacts than code, including models and documentation? How can safety and security assurance be done more incrementally?