Structural, logical, and organizational coupling capture different dependency and coordination phenomena in software projects, yet their relationships and practical relevance in industrial monoliths remain unclear. We investigated how these three types of coupling were related, how reliably they identified interdependent components, and the challenges and intrinsic benefits they presented to software practitioners. We conducted a mixed-method study in two large monolithic projects developed at Cadmatic. We extracted structural, logical, and organizational coupling, analyzed their correlations and agreement using nonparametric statistical methods, and complemented the results with practitioner focus groups involving the Cadmatic Development Teams. Structural coupling showed weak correlations with the other metrics, while logical and organizational coupling were strongly correlated. Agreement among the three metrics was generally low. Practitioners reported 17 issues and 8 benefits across the coupling types, with organizational coupling causing the most recurrent coordination and knowledge-sharing challenges. The three coupling types captured complementary architectural and socio-technical phenomena, and no single metric adequately characterized real dependencies in the studied Cadmatic projects. Combining multiple coupling perspectives can better support refactoring, coordination, and architectural decision-making in industrial environments.

LO2v2 is an updated and improved multi-modal dataset capturing logs, metrics, and traces from a production-ready microservice system implementing the OAuth2.0 authorization framework. The dataset extends a prior version by introducing a redesigned data collection pipeline that enhances reliability, reduces sources of data leakage, and increases the diversity and representativeness of recorded system behaviors. LO2v2 contains 640GB of data with 115 independent runs of a comprehensive test suite composed of 54 correct and error-inducing API scenarios executed over seven microservices and a MySQL database. In total, there are around 2.2 million metric files and 80,000 log files containing almost 2.6 billion log lines. Test execution order, duration, and inter-test idle periods are randomized to better reflect realistic system activity. The dataset includes 1136 container-level and 49 host-level metrics sampled at one-second intervals and extensive Docker-level service logs. However, due to limitations of injecting the Jaeger tracing agent, the maximum number of traces obtained during a test for each service is 20. All data are stored in plaintext formats, with metrics additionally provided as CSV files to facilitate time-series analysis. LO2v2 is designed to support research on anomaly detection, multi-modal observability, fault analysis, and benchmarking for microservice-based systems. The dataset offers a reproducible and extensible foundation for studies aiming to evaluate monitoring models, explore multi-modal fusion approaches, or develop new techniques for analyzing complex distributed architectures.

Organizational and logical coupling metrics require reliable identification of unique developers. In OSS, commit metadata is limited to names and emails, and the same developer may appear under multiple aliases, which can distort coupling measurements if de-duplication is missing. We aim to build a scalable and accurate pipeline for OSS developer de-duplication and to provide guidance on choosing a model based on precision vs. computational effort. We use Indel similarity as a baseline, then run an LLM-assisted matching process with manual validation to create a large dataset of duplicate identities. Using this dataset, we train and compare classical ML models of different complexity, evaluating precision along with training and inference time and energy. We expect a high-quality dataset and a benchmark of approaches that clarifies which solutions offer the best trade-off between accuracy and cost for large-scale OSS mining.

Architectural Decision Records (ADRs) play a central role in maintaining software architecture quality, yet many decision violations go unnoticed because projects lack both systematic documentation and automated detection mechanisms. Recent advances in Large Language Models (LLMs) open up new possibilities for automating architectural reasoning at scale. We investigated how effectively LLMs can identify decision violations in open-source systems by examining their agreement, accuracy, and inherent limitations. Our study analyzed 980 ADRs across 109 GitHub repositories using a multi-model pipeline in which one LLM primary screens potential decision violations, and three additional LLMs independently validate the reasoning. We assessed agreement, accuracy, precision, and recall, and complemented the quantitative findings with expert evaluation. The models achieved substantial agreement and strong accuracy for explicit, code-inferable decisions. Accuracy falls short for implicit or deployment-oriented decisions that depend on deployment configuration or organizational knowledge. Therefore, LLMs can meaningfully support validation of architectural decision compliance; however, they are not yet replacing human expertise for decisions not focused on code.

CONTEXT. Software architecture plays a central role in the design, development, and maintenance of software systems. With the rise of cloud computing, microservices, and containers, architectural practices have diversified. Understanding these shifts is vital. This study analyzes software architecture trends across seven leading industry conferences over five years.AIM. We investigate the evolution of software architecture by analyzing talks from top practitioner conferences, focusing on the motivations and contexts driving technology adoption.METHODS. We analyzed 5703 talks from seven major industry conferences (2020-2024), using large language models and expert validation to extract technologies, their purposes, and usage contexts. We also explored how technologies interrelate and fit within DevOps and deployment pipelines.RESULTS. Among 450 technologies, Kubernetes, Cloud Native, Serverless, and Containers dominate by frequency and centrality. Practitioners present technology mainly related to deployment, communication, AI, and observability. We identify five technology communities covering automation, coordination, cloud AI, monitoring, and cloud-edge. Most technologies span multiple DevOps stages and support hybrid deployment.CONCLUSIONS. Our study reveals that a few core technologies, like Kubernetes and Serverless, dominate the contemporary software architecture practice. These are mainly applied in later DevOps stages, with limited focus on early phases like planning and coding in recent years. We also show how practitioners frame technologies by purpose and context, reflecting evolving industry priorities. Finally, we observe how only research can provide a more holistic lens on architectural design, quality, and evolution.

Context: Generative Artificial Intelligence (GenAI) is transforming much of software development, yet its application in software architecture is still in its infancy, and no prior study has systematically addressed the topic. Aim: We aim to systematically synthesize the use, rationale, contexts, usability, and future challenges of GenAI in software architecture. Method: We performed a multivocal literature review (MLR), analyzing peer-reviewed and gray literature, identifying current practices, models, adoption contexts, and reported challenges, extracting themes via open coding. Results: Our review identified significant adoption of GenAI for architectural decision support and architectural reconstruction. OpenAI GPT models are predominantly applied, and there is consistent use of techniques such as few-shot prompting and retrieved-augmented generation (RAG). GenAI has been applied mostly to initial stages of the Software Development Life Cycle (SDLC), such as Requirements-to-Architecture and Architecture-to-Code. Monolithic and microservice architectures were the dominant targets. However, rigorous testing of GenAI outputs was typically missing from the studies. Among the most frequent challenges are model precision, hallucinations, ethical aspects, privacy issues, lack of architecture-specific datasets, and the absence of sound evaluation frameworks. Conclusions: GenAI shows significant potential in software design, but several challenges remain on its path to greater adoption. Research efforts should target designing general evaluation methodologies, handling ethics and precision, increasing transparency and explainability, and promoting architecture-specific datasets and benchmarks to bridge the gap between theoretical possibilities and practical use.

Architectural decisions are central to software architecture practice, yet their rationale is often fragmented across heterogeneous artifacts such as Architecture Decision Records (ADRs), pull request discussions, code review comments, and issue threads. Large Language Models (LLMs) provide new opportunities to mine architectural decisions and trade-offs from these unstructured sources. However, most existing approaches remain interactive and difficult to scale, limiting reproducibility, cost control, and methodological rigor when analyzing decisionmaking across large software portfolios. This short tutorial presents practical lessons learned from running LLM-based architectural decision mining at scale through High-Performance Computing (HPC) batch inference. We focus on two widely adopted technologies: (i) SLURM batch scheduling (sbatch) for deterministic and resource-aware execution, and (ii) vLLM for high-throughput GPU inference on shared infrastructures. The tutorial demonstrates how batch inference enables architecture researchers and practitioners to operationalize decision mining as a repeatable pipeline, with explicit input schemas, prompt versioning, structured outputs, and systematic validation. We further discuss how to treat LLM outputs as judgments rather than ground truth, combining multiple models and targeted human sampling to ensure the trustworthiness of extracted architectural knowledge.

In the early 1980s, Open Source Software emerged as a revolutionary concept amidst the dominance of proprietary software. What began as a revolutionary idea has now become the cornerstone of computer science. Amidst OSS projects, AI is increasing its presence and relevance. However, despite the growing popularity of AI, its adoption and impacts on OSS projects remain underexplored. We aim to assess the adoption of AI libraries in Python and Java OSS projects and examine how they shape development, including the technical ecosystem and community engagement. To this end, we will perform a large-scale analysis on 157.7k potential OSS repositories, employing repository metrics and software metrics to compare projects adopting AI libraries against those that do not. We expect to identify measurable differences in development activity, community engagement, and code complexity between OSS projects that adopt AI libraries and those that do not, offering evidence-based insights into how AI integration reshapes software development practices.

Kubernetes has become a cornerstone of cloudnative software systems, yet empirical evidence on its architectural and quality impact remains inconclusive. Existing studies often report differences between Kubernetes-Native, adopted, and non-adopting projects, but typically overlook a critical methodological issue: Kubernetes adoption is not random. Instead, adoption decisions are shaped by pre-existing architectural, process, and organizational characteristics that also influence software quality, leading to potentially biased conclusions. We present a work-in-progress, data-driven approach to confounder identification in studies of cloud-native technology adoption, using Kubernetes as a representative case. Leveraging the SQuaD dataset, which provides hundreds of architectural, process, and organizational metrics for hundreds of mature open-source projects, we systematically analyze pre-adoption characteristics across three Kubernetes adoption scenarios. We combine regularized regression and survival analysis to identify confounders that discriminate adoption scenarios and predict adoption timing.

Practitioners and researchers continuously focus on developing automation strategies to cope with the exponentially demanding need for the timely deployment of software projects in tight release schedules. Such automation techniques include Infrastructure-as-Code (IaC) and the DevOps and DevSecOps cycles. Recent studies investigated generative AI (GenAI) for generating infrastructure as code scripts. However, no studies have focused on using GenAI to generate IaC scripts based on DevSecOps stage artifacts. Different IaC tools serve varied purposes, requiring specific infrastructure setups for different project stages. We envision GenAI models leveraging artifacts from each DevSecOps stage to create and refine IaC scripts. We trust our approach to have an impact on practitioners to leverage it as an automatic copilot for infrastructure design and deployment, and for researchers to build on our vision and future empirical validation.

Software quality research increasingly relies on large-scale datasets that measure both the product and process aspects of software systems. However, existing resources often focus on limited dimensions, such as code smells, technical debt, or refactoring activity, thereby restricting comprehensive analyses across time and quality dimensions. To address this gap, we present the Software Quality Dataset (SQuaD), a multi-dimensional, time-aware collection of software quality metrics extracted from 450 mature open-source projects across diverse ecosystems, including Apache, Mozilla, FFmpeg, and the Linux kernel. By integrating nine state-of-the-art static analysis tools, i.e., SonarQube, CodeScene, PMD, Understand, CK, JaSoMe, RefactoringMiner, RefactoringMiner++, and PyRef, our dataset unifies over 700 unique metrics at method, class, file, and project levels. Covering a total of 63,586 analyzed project releases, SQuaD also provides version control and issue-tracking histories, software vulnerability data (CVE/CWE), and process metrics proven to enhance Just-In-Time (JIT) defect prediction. The SQuaD enables empirical research on maintainability, technical debt, software evolution, and quality assessment at unprecedented scale. We also outline emerging research directions, including automated dataset updates and cross-project quality modeling to support the continuous evolution of software analytics. The dataset is publicly available on ZENODO (DOI: 10.5281/zenodo.17566690).

Microservice architecture has gained traction as a powerful way to build distributed, scalable systems. However, analyzing its quality requires considering aspects unique to this architectural style. In particular, cohesion of microservices is considered important for evaluating microservice maintainability and quality, while few such metrics are available. Hub-like microservices are defined as an architectural anti-pattern, assumed to emerge when services centralize too many dependencies or responsibilities, thereby exhibiting low cohesion. However, this assumption has not been empirically validated. This study investigates whether Hub-like microservices indeed display lower internal cohesion than other services. We analyzed 123 microservices from a dataset of 25 microservice systems by leveraging an existing labeling of Hub-like microservices and computing eight cohesion metrics. We examined correlations between cohesion and several Hub-like detection techniques, including centrality and clustering-based metrics, the Minimum Description Length principle, and the Arcan approach. Our findings reveal weak to moderate negative correlations between service interface data cohesion and network centrality. Conversely, class relation cohesion is positively correlated with clustering-based Hub-like indicators, as well as shows a relation to all categorical Hub-like indicators with a positive effect size, due to the opposite interpretation of this metric. Thus, the common assumption that Hub-like services suffer from poor internal cohesion is not supported by our findings, with only a specific combination of a Hub-like detection method and a cohesion metric behaving as conjectured.

Measuring software energy consumption is becoming essential, but doing it correctly is not straightforward. Energy is measured at the hardware level, while software operates at higher levels of abstraction, making attribution inherently uncertain. Here, we explore RAPL-based tools that bridge this gap, comparing their capabilities and limitations and providing practical guidance to help practitioners choose the right tools for experiments, monitoring, and production use.—Davide Taibi

Machine learning operations (MLOps) has rapidly evolved from a marginal concept to a pivotal consideration for any enterprise implementing ML at scale. Cloud providers have rushed to fill this gap, each offering its own take on what MLOps should be. This article compares the MLOps offerings of Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), and Databricks. Their analysis reveals the diverse perspectives guiding each vendor’s approach, assisting practitioners in identifying suitable tradeoffs for their specific contexts. — Davide Taibi

In recent years, the detection of anti-patterns in microservice architecture has gained traction, particularly to identify instances of Microservice Architectural Degradation. In such tasks, the microservice architecture is often modeled as a network of microservice dependencies. Recent works have explored how to assess the evolution of such architectural networks by considering the architecture of consecutive releases of the project. Particular anti-patterns related to the structure of the service network include Wrong cuts and Knot services. Community detection is a way to identify groups of services in a network that strongly depend on each other. If such groups cannot be mapped to business processes in the system, or if the same service belongs to multiple communities, this could indicate architectural degradation due to an inappropriate division of responsibilities or unoptimized communication. Temporal community detection methods have been proposed to analyze community structure that evolves in time. We performed temporal community detection within the microservice architecture of six releases of the train-ticket benchmark and analyzed the composition of the discovered communities and their activities over time. We observed a stable architecture with a clear separation of services into two communities, which we could identify with two business processes performed by the system. We found services belonging to several communities, as well as services within the same community with both incoming and outgoing connections. The membership strength metric provided by the leveraged algorithm enables fine-grained assessment of the microservice communities.

While microservices are revolutionizing cloud computing by offering unparalleled scalability and independent deployment, their decentralized nature poses significant security and management challenges that can threaten system stability. We propose a framework based on MAPE-K, which leverages agentic AI, for autonomous anomaly detection and remediation to address the daunting task of highly distributed system management. Our framework offers practical, industry-ready solutions for maintaining robust and secure microservices. Practitioners and researchers can customize the framework to enhance system stability, reduce downtime, and monitor broader system quality attributes such as system performance level, resilience, security, and anomaly management, among others.

With microservices continuously being popular in the software architecture domain, more practitioners and researchers have begun to pay attention to the degradation issue that diminishes its sustainability. One of the key factors that causes the degradation of software architecture is its organizational structure, according to Conway's Law. However, the best practice of "One microservice per Team", advocated widely by the industry, is not commonly adopted, especially when many developers contribute heavily across multiple microservices and create organizational coupling. Therein, many key developers, who are responsible for the majority of the project work and irreplaceable to the team, can also create the most coupling and be the primary cause of microservice degradation. Hence, to properly maintain microservice architecture in terms of its organizational structure, we shall identify these key developers and understand their connections to the organizational coupling within the project. We propose an approach to identify the key developers in microservice projects and investigate their connection to organizational coupling. The approach shall facilitate the maintenance and optimization of microservice projects against degradation by detecting and mitigating organizational coupling.

Most leading technology companies are already on the cloud and continue investing in cloud-native systems built on microservices. Despite the trajectory, we lack guidance and best practices when coping with the evolvability of microservice-based systems. In a microservice architecture, applications are structured as a collection of loosely coupled, independently deployable services, each responsible for a specific functionality. However, despite the isolated microservice codebases managed by distinct teams, dependencies exist across microservices. When changes to the microservice code are made, we risk impacting other services with the potential for breakage when these get deployed. This compromises resilience and undermines stability throughout the distributed evolution. Unfortunately, we lack effective mechanisms to mitigate breaking changes when they are introduced. Our tool performs a comprehensive distributed codebase analysis based on robust AST-parsing tailored to component-based development typical for microservices. Such state-of-the-art static analysis is a promising instrument to effectively detect breaking changes or anti-patterns. Given the plethora of platforms, our demonstration focuses on Java and invites contributors to broaden platform support, offering unified intermediate representation to facilitate analysis with reusable search rules. Website: cloudhubs.github.io/cimet/ | Video tutorial: youtu.be/mKWueuln_80