ABSTRACT Context The microservices architectural style has revolutionized the way modern software systems are developed and operated. While the development of new microservices systems can leverage a wide range of resources and proven strategies, the migration of an existing monolithic system is not easily generalizable. Software architects look for guidance and predictable results in this highly individual process, in particular for generating a targeted, quality‐oriented, and semi‐automated decomposition. Objective To systematically guide software architects and developers in modernizing their software systems, we propose a holistic and quality‐oriented methodology to transform monolithic applications into microservices. Our work aims to provide industry‐relevant methods that address the gap between academia and practice by facilitating the transfer of knowledge. Methods In an overarching design science research process, we developed a framework that we implemented as a web‐based application. As a preliminary work, we conducted two initial interview studies with 25 software professionals to collect evidence on the intentions, strategies, and challenges in a migration process. An essential groundwork of our framework design constitute 110 scientific publications on approaches for architectural refactoring and migration to microservices, which we reviewed over four iterations. In a multifaceted evaluation with 26 participants, we examined our methodology's capability of providing actionable guidance for practitioners. This evaluation was complemented by two longitudinal case studies in an industrial context. Results We provide a framework for transforming monolithic applications to microservices, along with a dedicated quality assurance concept that supports a quality‐driven migration process. The evaluations among 19 software professionals showed an overall positive result in terms of effectiveness, usefulness, and usability. Two industrial case studies confirmed these promising results. Among practitioners, we discerned a need for flexibility, ease of use, and holistic guidance in a migration process. In this regard, we see potential to evolve our concept using artificial intelligence techniques for even more precise recommendations in a human‐like conversational dialog.

Abstract Explainable artificial intelligence (XAI) is a field of study that focuses on the development process of AI-based systems while making their decision-making processes understandable and transparent for users. Research already identified explainability as an emerging requirement for AI-based systems that use machine learning (ML) techniques. However, there is a notable absence of studies investigating how ML practitioners perceive the concept of explainability, the challenges they encounter, and the potential trade-offs with other quality attributes. In this study, we want to discover how practitioners define explainability for AI-based systems and what challenges they encounter in making them explainable. Furthermore, we explore how explainability interacts with other quality attributes. To this end, we conducted semi-structured interviews with 14 ML practitioners from 11 companies. Our study reveals diverse viewpoints on explainability and applied practices. Results suggest that the importance of explainability lies in enhancing transparency, refining models, and mitigating bias. Methods like SHapley Additive exPlanations (SHAP) and Local Interpretable Model-Agnostic Explanation (LIME) are frequently used by ML practitioners to understand how models work, while tailored approaches are typically adopted to meet the specific requirements of stakeholders. Moreover, we have discerned emerging challenges in eight categories. Issues such as effective communication with non-technical stakeholders and the absence of standardized approaches are frequently stated as recurring hurdles. We contextualize these findings in terms of requirements engineering and conclude that industry currently lacks a standardized framework to address arising explainability needs.

Abstract The domain of cyber‐physical systems (CPS) has recently seen strong growth, for example, due to the rise of the Internet of Things (IoT) in industrial domains, commonly referred to as “Industry 4.0.” However, CPS challenges like the strong hardware focus can impact modern software development practices, especially in the context of modernizing legacy systems. While microservices and DevOps have been widely studied for enterprise applications, there is insufficient coverage for the CPS domain. Our goal is therefore to analyze the peculiarities of such systems regarding challenges and practices for using and migrating towards microservices and DevOps. We conducted a rapid review based on 146 scientific papers, and subsequently validated our findings in an interview‐based case study with nine CPS professionals in different business units at Siemens AG. The combined results picture the specifics of microservices and DevOps in the CPS domain. While several differences were revealed that may require adapted methods, many challenges and practices are shared with typical enterprise applications. Our study supports CPS researchers and practitioners with a summary of challenges, practices to address them, and research opportunities.

The promise of increased agility, autonomy, scalability, and reusability has made the microservices architecture a de facto standard for the development of large-scale and cloud-native commercial applications. Software patterns are an important design tool, and often they are selected and combined with the goal of obtaining a set of desired quality attributes. However, from a research standpoint, many patterns have not been widely validated against industry practice, making them not much more than interesting theories. To address this, we investigated how practitioners perceive the impact of 14 patterns on 7 quality attributes. Hence, we conducted 9 semi-structured interviews to collect industry expertise regarding (1) knowledge and adoption of software patterns, (2) the perceived architectural trade-offs of patterns, and (3) metrics professionals use to measure quality attributes. We found that many of the trade-offs reported in our study matched the documentation of each respective pattern, and identified several gains and pains which have not yet been reported, leading to novel insight about microservice patterns.

In the age of autonomously driving vehicles, functionality and complexity of embedded systems are increasing tremendously. Safety aspects become more important and require such systems to operate with the highest possible level of fault tolerance. Simulation and systematic testing techniques often reach their limits in this regard. Here, formal verification as a long established technique can be an appropriate complement. However, the necessary preparatory work like adequately modeling a system and specifying properties in temporal logic are anything but trivial. In this paper, we report on our experiences applying model checking to verify the arbitration logic of a Vehicle Control System. We balance pros and cons of different model checking techniques and tools, and reason about our choice of the symbolic model checker NuSMV. We describe the process of modeling the architecture, resulting in ~1500 LOC, 69 state variables and 38 LTL constraints. To handle this large-scale model, we automate and optimize the model checking procedure for use on multi-core CPUs and employ Bounded Model Checking to avoid the state explosion problem. We share our lessons learned and provide valuable insights for architects, developers, and test engineers involved in this highly present topic.

Abstract Context Microservices as a lightweight and decentralized architectural style with fine-grained services promise several beneficial characteristics for sustainable long-term software evolution. Success stories from early adopters like Netflix, Amazon, or Spotify have demonstrated that it is possible to achieve a high degree of flexibility and evolvability with these systems. However, the described advantageous characteristics offer no concrete guidance and little is known about evolvability assurance processes for microservices in industry as well as challenges in this area. Insights into the current state of practice are a very important prerequisite for relevant research in this field. Objective We therefore wanted to explore how practitioners structure the evolvability assurance processes for microservices, what tools, metrics, and patterns they use, and what challenges they perceive for the evolvability of their systems. Method We first conducted 17 semi-structured interviews and discussed 14 different microservice-based systems and their assurance processes with software professionals from 10 companies. Afterwards, we performed a systematic grey literature review (GLR) and used the created interview coding system to analyze 295 practitioner online resources. Results The combined analysis revealed the importance of finding a sensible balance between decentralization and standardization. Guidelines like architectural principles were seen as valuable to ensure a base consistency for evolvability and specialized test automation was a prevalent theme. Source code quality was the primary target for the usage of tools and metrics for our interview participants, while testing tools and productivity metrics were the focus of our GLR resources. In both studies, practitioners did not mention architectural or service-oriented tools and metrics, even though the most crucial challenges like Service Cutting or Microservices Integration were of an architectural nature. Conclusions Practitioners relied on guidelines, standardization, or patterns like Event-Driven Messaging to partially address some reported evolvability challenges. However, specialized techniques, tools, and metrics are needed to support industry with the continuous evaluation of service granularity and dependencies. Future microservices research in the areas of maintenance, evolution, and technical debt should take our findings and the reported industry sentiments into account.

While Microservices promise several beneficial characteristics for sustainable long-term software evolution, little empirical research covers what concrete activities industry applies for the evolvability assurance of Microservices and how technical debt is handled in such systems. Since insights into the current state of practice are very important for researchers, we performed a qualitative interview study to explore applied evolvability assurance processes, the usage of tools, metrics, and patterns, as well as participants' reflections on the topic. In 17 semi-structured interviews, we discussed 14 different Microservice-based systems with software professionals from 10 companies and how the sustainable evolution of these systems was ensured. Interview transcripts were analyzed with a detailed coding system and the constant comparison method. We found that especially systems for external customers relied on central governance for the assurance. Participants saw guidelines like architectural principles as important to ensure a base consistency for evolvability. Interviewees also valued manual activities like code review, even though automation and tool support was described as very important. Source code quality was the primary target for the usage of tools and metrics. Despite most reported issues being related to Architectural Technical Debt (ATD), our participants did not apply any architectural or service-oriented tools and metrics. While participants generally saw their Microservices as evolvable, service cutting and finding an appropriate service granularity with low coupling and high cohesion were reported as challenging. Future Microservices research in the areas of evolution and technical debt should take these findings and industry sentiments into account.

To remain competitive in a fast changing environment, many companies started to migrate their legacy applications towards a Microservices architecture. Such extensive migration processes require careful planning and consideration of implications and challenges likewise. In this regard, hands-on experiences from industry practice are still rare. To fill this gap in scientific literature, we contribute a qualitative study on intentions, strategies, and challenges in the context of migrations to Microservices. We investigated the migration process of 14 systems across different domains and sizes by conducting 16 in-depth interviews with software professionals from 10 companies. Along with a summary of the most important findings, we present a separate discussion of each case. As primary migration drivers, maintainability and scalability were identified. Due to the high complexity of their legacy systems, most companies preferred a rewrite using current technologies over splitting up existing code bases. This was often caused by the absence of a suitable decomposition approach. As such, finding the right service cut was a major technical challenge, next to building the necessary expertise with new technologies. Organizational challenges were especially related to large, traditional companies that simultaneously established agile processes. Initiating a mindset change and ensuring smooth collaboration between teams were crucial for them. Future research on the evolution of software systems can in particular profit from the individual cases presented.

Maintainability assurance techniques are used to control this quality attribute and limit the accumulation of potentially unknown technical debt. Since the industry state of practice and especially the handling of Service- and Microservice-Based Systems in this regard are not well covered in scientific literature, we created a survey to gather evidence for a) used processes, tools, and metrics in the industry, b) maintainability-related treatment of systems based on service-orientation, and c) influences on developer satisfaction w.r.t. maintainability. 60 software professionals responded to our online questionnaire. The results indicate that using explicit and systematic techniques has benefits for maintainability. The more sophisticated the applied methods the more satisfied participants were with the maintainability of their software while no link to a hindrance in productivity could be established. Other important findings were the absence of architecture-level evolvability control mechanisms as well as a significant neglect of service-oriented particularities for quality assurance. The results suggest that industry has to improve its quality control in these regards to avoid problems with long-living service-based software systems.