Microservices architecture has gained significant traction, in part owing to its potential to deliver scalable, robust, agile, and failure-resilient software products. Consequently, many companies that use large and complex software systems are actively looking for automated solutions to decompose their monolith applications into microservices. This paper rigorously examines 35 research papers selected from well-known databases using a Systematic Literature Review (SLR) protocol and snowballing method, extracting data to answer the research questions, and presents the following four contributions. First, the Monolith to Microservices Decomposition Framework (M2MDF) which identifies the major phases and key elements of decomposition. Second, a detailed analysis of existing decomposition approaches, tools and methods. Third, we identify the metrics and datasets used to evaluate and validate monolith to microservice decomposition processes. Fourth, we propose areas for future research. Overall, the findings suggest that monolith decomposition into microservices remains at an early stage and there is an absence of methods for combining static, dynamic, and evolutionary data. Insufficient tool support is also in evidence. Furthermore, standardised metrics, datasets, and baselines have yet to be established. These findings can assist practitioners seeking to understand the various dimensions of monolith decomposition and the community's current capabilities in that endeavour. The findings are also of value to researchers looking to identify areas to further extend research in the monolith decomposition space.

Architecture Consistency (AC) aims to align implemented systems with their intended architectures. Several AC approaches and tools have been proposed and empirically evaluated, suggesting favourable results. In this paper, we empirically examine the state of practice with respect to Architecture Consistency, through interviews with nineteen experienced software engineers. Our goal is to identify 1) any practises that the companies these architects work for, currently undertake to achieve AC; 2) any barriers to undertaking explicit AC approaches in these companies; 3) software development situations where practitioners perceive AC approaches would be useful, and 4) AC tool needs, as perceived by practitioners. We also assess current commercial AC tool offerings in terms of these perceived needs. The study reveals that many practitioners apply informal AC approaches as there are barriers for adopting more formal and explicit approaches. These barriers are: 1) Difficulty in quantifying architectural inconsistency effects, and thus justifying the allocation of resources to fix them to senior management, 2) The near invisibility of architectural inconsistency to customers, 3) Practitioners’ reluctance towards fixing architectural inconsistencies, and 4) Practitioners perception that huge effort is required to map the system to the architecture when using more formal AC approaches and tools. Practitioners still believe that AC would be useful in supporting several of the software development activities such as auditing, evolution and ensuring quality attributes. After reviewing several commercial tools, we posit that AC tool vendors need to work on their ability to support analysis of systems made up of different technologies, that AC tools need to enhance their capabilities with respect to artefacts such as services and meta-data, and to focus more on non-maintainability architectural concerns.

Context and Motivation – Developer eXperience (Dev-X) is a recent research area that focuses on developers perceptions, feelings, and values with respect to software development and software quality. Research suggests that factors and practices related to Dev-X can have a substantial impact on developer productivity (Dev-P). However, despite a large and diverse body of literature on factors that can impact Dev-P in general, there is no coherent and comprehensive characterization of how Dev-X-specific insights can influence developer productivity. Aims – In the presented research, we aim to provide a coherent, comprehensive characterization of factors and practices related to Dev-X, with a particular focus on those factors and practices that potentially affect Dev-P. Method – To this end, we performed a systematic literature review and identified 218 relevant papers in this area. We characterize the papers based on the related frameworks and concepts common to Dev-X and Dev-P as presented in the existing literature. Dev-X factors such as “work fragmentation” and practices such as “collaboration with owner-developer” are identified using a grounded-in-the-literature, content-analysis method, guided by the theory. For each Dev-X factor, we identify attributes that might be used to assess/ measure the current status (of an organization or project) regarding that factor and how that factor and its effects on productivity have been evidenced in the literature (mentioned vs. considered in questionnaires vs. substantiated with a more positivist evaluation). Results – We identify 33 Dev-X-related factors and 41 Dev-X-related practices, which are organized into 10 themes to summarize their influence. The results suggest that the availability of required resources, relevant expertise re the allocated tasks, and fewer interruptions are among the top positively impacting factors. Conversely, factors such as code complexity, heterogeneous contexts of tasks, and non-adherence to standardization harm Dev-X and Dev-P. Top industrial practices employed to mitigate the negative influence of factors include characterization-based task assignments, mental model support, and the timely evolution of technologies. Conclusions – Overall, this research suggests that organizations can influence Dev-P through improved Dev-X, incorporating suitable practices to mediate relevant factors in their context. Important in this regard are practices such as fragmenting large tasks, highlighting the utility of proposed tasks/changes to the developers, and promoting (developer) ownership of artefacts. Finally, our results point to areas where further research seems appropriate, i.e., where Dev-X factors/practices have been proposed as being impactful on Dev-P but not yet fully substantiated or explored as such (factors like “Nature of Activity” and practices like choosing practices/protocols appropriately).

Gamification is the use of game design elements in nongame contexts and has been shown to be effective in motivating behavior change. By seeing game elements as “motivational affordances,” and formalizing the relationship between these elements and motivational affordances, it is the position of this article that gamification can be effectively applied to improve software systems across many different application domains. The research reported here aims to formalize the relationship between game elements and motivation, toward making gamification’s use more systematic. The focus is on the development of a framework linking commonly occurring game elements with the components of a psychological motivational model known as the self-determination theory, coupled with a proposed framework of commonly occurring game elements. The goal is to inform system designers who would like to leverage gamification of the game elements they would need to employ as motivational affordances.