Software Architecture in Practice: Challenges and Opportunities

Software architecture has been an active research field for nearly four decades, in which previous studies make significant progress such as creating methods and techniques and building tools to support software architecture practice. Despite past efforts, we have little understanding of how practitioners perform software architecture related activities, and what challenges they face. Through interviews with 32 practitioners from 21 organizations across three continents, we identified challenges that practitioners face in software architecture practice during software development and maintenance. We reported on common software architecture activities at software requirements, design, construction and testing, and maintenance stages, as well as corresponding challenges. Our study uncovers that most of these challenges center around management, documentation, tooling and process, and collects recommendations to address these challenges.Comment: Preprint of Full Research Paper, the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE '23

From Social Simulation to Integrative System Design

As the recent financial crisis showed, today there is a strong need to gain "ecological perspective" of all relevant interactions in socio-economic-techno-environmental systems. For this, we suggested to set-up a network of Centers for integrative systems design, which shall be able to run all potentially relevant scenarios, identify causality chains, explore feedback and cascading effects for a number of model variants, and determine the reliability of their implications (given the validity of the underlying models). They will be able to detect possible negative side effect of policy decisions, before they occur. The Centers belonging to this network of Integrative Systems Design Centers would be focused on a particular field, but they would be part of an attempt to eventually cover all relevant areas of society and economy and integrate them within a "Living Earth Simulator". The results of all research activities of such Centers would be turned into informative input for political Decision Arenas. For example, Crisis Observatories (for financial instabilities, shortages of resources, environmental change, conflict, spreading of diseases, etc.) would be connected with such Decision Arenas for the purpose of visualization, in order to make complex interdependencies understandable to scientists, decision-makers, and the general public.Comment: 34 pages, Visioneer White Paper, see http://www.visioneer.ethz.c

Analyzing the concept of technical debt in the context of agile software development: A systematic literature review

Technical debt (TD) is a metaphor that is used to communicate the consequences of poor software development practices to non-technical stakeholders. In recent years, it has gained significant attention in agile software development (ASD). The purpose of this study is to analyze and synthesize the state of the art of TD, and its causes, consequences, and management strategies in the context of ASD. Using a systematic literature review (SLR), 38 primary studies, out of 346 studies, were identified and analyzed. We found five research areas of interest related to the literature of TD in ASD. Among those areas, managing TD in ASD received the highest attention, followed by architecture in ASD and its relationship with TD. In addition, eight categories regarding the causes and five categories regarding the consequences of incurring TD in ASD were identified. Focus on quick delivery and architectural and design issues were the most popular causes of incurring TD in ASD. Reduced productivity, system degradation and increased maintenance cost were identified as significant consequences of incurring TD in ASD. Additionally, we found 12 strategies for managing TD in the context of ASD, out of which refactoring and enhancing the visibility of TD were the most significant. The results of this study provide a structured synthesis of TD and its management in the context of ASD as well as potential research areas for further investigation

Discovering and Assessing Enterprise Architecture Debts

The term Enterprise Architecture (EA) Debts has been coined to grasp the difference between the actual state of the EA and its hypothetical, optimal state. So far, different methods have been proposed to identify such EA Debts in organizations. However, these methods either are based on the transfer of known concepts from other domains to EA or are time and resource intensive. To overcome these shortcomings, we propose an approach that uses an interview format to identify EA Debts in enterprises and a method that allows a qualitative assessment of identified EA Debts. The proposed approach is supported by the designed framework that consists of an interview format and a process for determining thresholds of certain EA Smells

How to get away with technical debt: An explorative multiple-case study on autonomous teams and technical debt management

Technical debt (TD) is constantly accumulating throughout software development processes. In many autonomous teams this technical debt will damage and injure the process, prohibiting them from adding new functionalities to their products. Tech companies must therefore understand how they can manage TD to avoid getting stuck fixing bad code. In the research on technical debt management (TDM), there seems to be a lack of empirical studies that examine how TD is managed in autonomous teams. Some frameworks are developed with the purpose of investigating TDM but lack the empirical validation and reliability. This study investigates how autonomous teams actively manage technical debt, by conducting a multiple-case study in a Norwegian fintech company. The teams are studied by utilizing the TDM framework, measuring autonomous teams’ degree of maturity within different TDM activities in order to understand their current state of practice and how to further improve these. The study found that all autonomous teams practiced TDM, but to various extents. Some teams had structured processes, while others had no clear strategies. Most of the teams were ranked with what the framework call “received level of maturity”, and conducted TDM activities occasionally based on their current needs. The study also found challenges related to the TDM frameworks maturity levels relation to TDM success, and identified that TDM activities ranked as highly mature did not necessarily translate into higher TDM success. The study identified a need for the TDM framework to be further empirically tested and iterated on for it to work as a an accurate tool for understanding and improving autonomous teams’ TDM processes. Keywords: agile software development, autonomous teams, technical debt, technical debt management, case stud

Understanding automated and human-based technical debt identification approaches-a two-phase study

Context: The technical debt (TD) concept inspires the development of useful methods and tools that support TD identification and management. However, there is a lack of evidence on how different TD identification tools could be complementary and, also, how human-based identification compares with them. Objective: To understand how to effectively elicit TD from humans, to investigate several types of tools for TD identification, and to understand the developers’ point of view about TD indicators and items reported by tools. Method: We asked developers to identify TD items from a real software project. We also collected the output of three tools to automatically identify TD and compared the results in terms of their locations in the source code. Then, we collected developers’ opinions on the identification process through a focus group. Results: Aggregation seems to be an appropriate way to combine TD reported by developers. The tools used cannot help in identifying many important TD types, so involving humans is necessary. Developers reported that the tools would help them to identify TD faster or more accurately and that project priorities and current development activities are important to be considered together, along with the values of principal and interest, when deciding to pay off a debt. Conclusion: This work contributes to the TD landscape, which depicts an understanding between different TD types and how they are best discovered