Data mesh is an emerging domain-driven decentralized data architecture that aims to minimize or avoid operational bottlenecks associated with centralized, monolithic data architectures in enterprises. The topic has piqued the practitioners’ interest, and considerable gray literature exists. At the same time, we observe a lack of academic attempts at defining and building upon the concept. Hence, in this article, we aim to start from the foundations and characterize the data mesh architecture regarding its design principles, architectural components, capabilities, and organizational roles. We systematically collected, analyzed, and synthesized 114 industrial gray literature articles. The resulting review provides insights into practitioners’ perspectives on the four key principles of data mesh: data as a product, domain ownership of data, self-serve data platform, and federated computational governance. Moreover, due to the comparability of data mesh and SOA (service-oriented architecture), we mapped the findings from the gray literature into the reference architectures from the SOA academic literature to create the reference architectures for describing three key dimensions of data mesh: organization of capabilities and roles, development, and runtime. Finally, we discuss open research issues in data mesh, partially based on the findings from the gray literature.

Travel time information is used as input or auxiliary data for tasks such as dynamic navigation, infrastructure planning, congestion control, and accident detection. Various data-driven Travel Time Prediction (TTP) methods have been proposed in recent years. One of the most challenging tasks in TTP is developing and selecting the most appropriate prediction algorithm. The existing studies that empirically compare different TTP models only use a few models with specific features. Moreover, there is a lack of research on explaining TTPs made by black-box models. Such explanations can help to tune and apply TTP methods successfully. To fill these gaps in the current TTP literature, using three data sets, we compare three types of TTP methods (ensemble tree-based learning, deep neural networks, and hybrid models) and ten different prediction algorithms overall. Furthermore, we apply XAI (Explainable Artificial Intelligence) methods (SHAP and LIME) to understand and interpret models’ predictions. The prediction accuracy and reliability for all models are evaluated and compared. We observed that the ensemble learning methods, i.e., XGBoost and LightGBM, are the best performing models over the three data sets, and XAI methods can adequately explain how various spatial and temporal features influence travel time.

The increasing heterogeneity of the VM offerings on public IaaS clouds} gives rise to a very large number of deployment options for constructing distributed, multi-component cloud applications. However, selecting an appropriate deployment variant, i.e., a valid combination of deployment options, to meet required performance levels is non-trivial. The combinatorial explosion of the deployment space makes it infeasible to measure the performance of all deployment variants to build a comprehensive empirical performance model. To address this problem, we propose Feature-Oriented Cloud (FOCloud), a performance engineering approach for deployment configurable cloud applications. FOCloud (i) uses feature modeling to structure and constrain the valid deployment space by modeling the commonalities and variations in the different deployment options and their inter-dependencies, (ii) uses sampling and machine learning to incrementally and cost-effectively build a performance prediction model whose input variables are the deployment options, and the output variable is the performance of the resulting deployment variant, and (iii) uses Explainable AI techniques to provide explanations for the prediction outcomes of valid deployment variants in terms of the deployment options We demonstrate the practicality and feasibility of FOCloud by applying it to an extension of the RuBiS benchmark application deployed on Google Cloud.

Organizations, particularly medium and large enterprises, typically rely heavily on complex, distributed systems to deliver critical services and products. However, the growing complexity of these systems poses challenges in ensuring service availability, performance, and reliability. Traditional resilience testing methods often fail to capture the intricate interactions and failure modes of modern systems. Chaos Engineering addresses these challenges by proactively testing how systems in production behave under turbulent conditions, allowing developers to uncover and resolve potential issues before they escalate into outages. Though chaos engineering has received growing attention from researchers and practitioners alike, we observed a lack of reviews that synthesize insights from both academic and grey literature. Hence, we conducted a Multivocal Literature Review (MLR) on chaos engineering to address this research gap by systematically analyzing 96 academic and grey literature sources published between January 2016 and April 2024. We first used the chosen sources to derive a unified definition of chaos engineering and to identify key functionalities, components, and adoption drivers. We also developed a taxonomy for chaos engineering platforms, capturing dimensions such as execution environments, automation modes, automation strategies, and deployment types. This taxonomy was then used to compare the relevant chaos engineering tools. The taxonomy enables organizations to align tool selection with their system and infrastructure architectures (e.g., microservices, Kubernetes, or serverless platforms) and resilience objectives, while providing researchers with a consolidated foundation for benchmarking tools and for future work such as mining open-source repositories and extending chaos engineering to AI-enabled systems. Finally, we analyzed the current state of chaos engineering research and identified several open research issues.

Software engineering nowadays largely relies on agile methods to carry out software development. In often highly distributed organizations, agile teams can develop organisational and socio-technical issues loosely defined as community smells, which reflect sub-optimal organisational configurations that bear additional project cost, a phenomenon called social debt. In this paper we look into the co-occurrence of such nasty organisational phenomena-community smells-with software architecture smells-indicators that software architectures may exhibit sub-optimal modularization structures, with consequent additional cost. We conclude that community smells can serve as a guide to steer the qualities of software architectures within agile teams.