Research PapersICSA 2026

Accepted Papers

Call for Papers

The IEEE International Conference on Software Architecture (ICSA) is the premier gathering of practitioners and researchers interested in software architecture, component-based software engineering, and quality aspects of complex software systems. The 23rd IEEE International Conference on Software Architecture (ICSA 2026) continues the tradition of a working conference, where practitioners and researchers meet and where software architects can explain the challenges they face and try to influence the future of the field. Interactive working sessions will be the place where researchers meet practitioners to identify opportunities to create the future.

Software engineering is undergoing a rapid transformation: AI is becoming more intimately involved with supporting software development activities, including improving developer-written code, reviewing changes, and even writing entirely new code. In such an environment, the importance of software design becomes more predominant. Furthermore, 2026 marks 30 years since Software Architecture: Perspectives on an Emerging Discipline was published, and so it is timely to reflect on how the legacy of software architecture knowledge can rise to meet this new world. Therefore, the theme of ICSA 2026 is Architecting in Continuous Software Engineering: Evolving Roles, Enduring Principles.

ICSA 2026 innovative contributions that explore the opportunities and challenges presented by these advancements. We seek papers that propose new methodologies, tools, and best practices for integrating intelligent systems into software architecture. Additionally, we welcome case studies highlighting both successful and unsuccessful applications of these technologies, providing valuable insights into their practical implications and potential pitfalls.

Besides the main theme, we call on both researchers and practitioners for contributions that advance our understanding of architectures in real-world software, facilitate empirical research by making architectural artifacts and tools publicly available, and promote replicability of results through common datasets and benchmarks. We welcome original papers that explore and explain the role of architecture in current systems and future systems. This conference looks at what can be learned from our software architecture history, experience, studies, and best practices.

Topics

Topics of interest for the conference include (but are not limited to) the following:

• Requirements & Architecture
  • Stakeholder management and collaborating with other domains
  • Linking architecture to requirements and/or implementation
  • Methods to address the intertwining of specification and design
  • Sustainability, ethics, business, financial, and managerial aspects of software architecture
• Architecture Design
  • Model-driven architecture
  • Component-based software engineering
  • Architecture frameworks and architecture description languages
  • Reusable architectural solutions & architecture knowledge management
• Cloud-native Computing & Architecture
  • Microservices & containerization
  • Serverless platforms & novel forms of virtualization
  • Event-driven architectures
  • Observability & Distributed Tracing
• Architecture Evaluation
  • Evaluating quality aspects (e.g., security, performance, reliability, evolvability)
  • Architecture conformance checking
  • Lightweight evaluation methods
  • New and emerging quality attributes, tactics for addressing them, and methods to analyze them, including for energy consumption and environmental impact measurement and assessment
• Architecture & its life-cycle
  • Automatic extraction and generation of software architecture descriptions
  • Architecture & continuous integration/delivery, and DevOps
  • Refactoring and evolving architecture design decisions and solutions
  • Agile architecting, continuous architecting, and other approaches to architecting
• Architecture & Architects
  • Roles and responsibilities for software architects
  • Training, soft skills, coaching, mentoring, education, and certification
  • Architecture for equality, diversity and inclusion
  • State-of-the-art and state-of-practice in software architecture
• Architecture for specific types of systems
  • Edge / Fog / Internet of Things (IoT) systems / IoB systems
  • AI / ML systems & systems using blockchains
  • Cyber-physical systems
  • Self-adaptive & autonomous systems
• Architecture & Generative AI
  • Design assistance & identification of architectural patterns
  • Decision making support, comparing technologies, evaluating trade-offs
  • Generating source code to facilitate implementing architecture designs
  • Reviewing designs, identifying inconsistencies, and suggesting improvements
  • Using architecture principles as a way to guide agentic- and vibe-coding

Open Science Principles

The ICSA conference encourages authors of research papers to follow the principles of transparency, reproducibility, and replicability. In particular, the conference supports the adoption of open data and open source principles and encourages authors to disclose data in order to increase reproducibility and replicability. For ICSA 2026 it is expected that accepted research papers are accompanied by an artifact that will be evaluated in the Artifacts Evaluation track. For submission of research papers, authors are expected to submit an anonymized draft of the artifact that paper reviewers can use to help evaluate the research contributions. If authors are unable to submit an artifact draft, they are asked to comment in their submitted paper on why this is not possible, practical, or desirable. Possible reasons may involve privacy restrictions and/or non-disclosure agreements.

Accepted research papers with artifacts must then follow the artifact submission guidelines and deadlines mentioned in Artifacts Evaluation track. Note that at least one author of each artifact submission is expected to review 2 or 3 other submitted artifacts.

For anonymizing the draft of the artifact, we recommend https://anonymous.4open.science/. The draft of the artefact does not have to be executable. The later artefact submission does not have to be anonymized.

Submission

We solicit the submission of technical research papers that describe original and significant results of theoretical, empirical, conceptual, or experimental work in software architecture. The submissions will be evaluated based on novelty, soundness, significance/relevance, open science principles (as outlined above), and presentation quality, in that order. All submissions must conform to the IEEE paper formatting and submission instructions and must not exceed 10 pages for the main text, inclusive of all figures, tables, appendices, etc. Two additional pages containing only references are permitted. The submissions must conform to the author instructions as well as to the IEEE Guidelines for Artificial Intelligence (AI)-Generated Text. Any submission that does not comply with these guidelines may be desk-rejected without further review.

Please note that ICSA 2026 will pursue a double-anonymous review process for technical research papers only, therefore all technical research paper submissions have to fulfill the double-anonymous reviewing requirements. Submissions that disregard these review requirements will be desk-rejected without review. For artifacts that will be published following the open science principles (see above), we ask that authors undertake reasonable, possibly non-exhaustive steps to not disclose their identity, e.g., by anonymizing author names, handles, affiliations, and URLs. The leakage of information in additional artifacts will not lead to desk rejection.

Reviewers will be asked to treat artifacts and papers as confidential. Changes to the list of authors are not permitted after submission.Track chairs are not allowed to submit papers to the track they are chairing.

All papers are to be submitted electronically via the EasyChair submission system by the submission deadline and must not have been published before or be submitted for review elsewhere while under consideration at ICSA. All submissions will be checked with an anti-plagiarism tool. Submissions found to contain plagiarized content may be desk rejected without further review.

Authors will be able to update submissions until Monday, Dec 8th AoE

Publication

All accepted technical research papers will be published in the ICSA 2026 main proceedings and appear in the IEEE Xplore Digital Library.

The authors of submissions that are rejected as technical research papers – but for which reviews show a strong potential for positively influencing the state of the art or state of practice in software architecture, or strong potential to stimulate discussion – may be invited to submit a short paper (up to 8 pages including references) or a poster (poster presented at the conference) + up to 4 pages (including references) describing their research. Short papers and poster summaries (up to 4 pages) will be published in the ICSA 2026 companion proceedings.

Note that at least one author of an accepted contribution is required to register and present the work at the conference. An in-person presentation is required

1. Introduction

ICSA aims for an inclusive and transparent review process. The following document outlines review criteria for the “Research Papers” track at ICSA 2026, as well as quality criteria for reviews. We aim to balance clarity and level of detail, i.e., we aim to provide a concise guide to support reviewers.

The “Research Papers” track at ICSA 2026 includes submissions on various topics; please refer to the Call for Papers for an overview.

We encourage reviewers to be open, positive and professional:

• Review authorship: PC members were invited because of their expertise. Therefore, we expect PC members to author their reviews, asking for sub-reviewers only for additional feedback. This means that reviewers may solicit help from others. However, reviewers should rewrite the review in their own words and adjust the scores accordingly. The opinions should be represented as the PC member’s opinions, not those of a sub-reviewer.
• No AI-generated Reviews: The IEEE policy for reviewers states: “Do not use AI tools (e.g., ChatGPT, Gemini) to generate or draft reviews”.
• Review quality: PC members are requested to submit a thorough and careful review. Reviewers should pay attention to the bidding process to select those papers closer to their area of expertise.
• Be clear about what is missing: Even if, in the view of a reviewer, a paper does not meet the standards required for acceptance, we encourage reviewers to highlight what, in their opinion, would be necessary to make it acceptable for ICSA (while acknowledging that ICSA submissions are subject to the limitations of conference papers regarding lengths, etc.).
• Numerical scoring: Reviewers should try not to be indecisive. Please take a stand. Whatever a reviewer’s position is, we ask you to justify it in the comments.
• Ethical issues: PC members should inform PC co-chairs if they detect any evidence related to plagiarism, concurrent submission, etc.
• Update reviews: Reviews can be updated at any time, i.e., we encourage reviewers to follow the submitted reviews of submissions assigned to them and make adjustments even before the official discussion period.
• Discussion leaders: For papers that require more detailed discussions to reach a final decision of accepting or rejecting them, we might assign discussion leaders. Discussion leaders will be assigned before or during the discussion period. To reduce the workload for PC members, not all papers will have a discussion leader, and we will not assign discussion leaders up front.

2. Review Criteria

Relevance: The extent to which the paper responds to the scope as outlined in the Call for Papers and to which the paper’s contributions are important for software architecture research, practice and education/training. ICSA is interested in growing its community, so we encourage new areas of architecture-related research, even if they are not explicitly mentioned in the Call for Papers. If a reviewer believes that a paper is not relevant for ICSA, we ask for an explanation of why not. For RESEARCH PAPERS, the key concern is how the paper discusses implications for software architecture research and/or practice and explains the meaning of the findings (in particular, if the focus of the paper is on empirical work).

Soundness: The extent to which the paper’s claims and contributions are supported by rigorous application of appropriate research methods. RESEARCH PAPERS should provide a rigorous description of the research method as well as acknowledge limitations and validity threats.

Originality: The extent to which the contribution is sufficiently original and is clearly explained with respect to the state-of-the-art. Note that originality is not about providing surprising or unexpected results or the complexity of a proposed solution but how the work advances the body of knowledge. If a paper lacks important references, we ask reviewers to provide suggestions but avoid self-citations. When a reviewer’s own work is extremely relevant, they should always contact the PC co-chairs and provide potential alternatives for other related work. For RESEARCH PAPERS, there needs to be a clear discussion of how the proposed work fits into the current body of knowledge. For papers that provide new approaches, simple and elegant solutions which still have the potential to improve the state of practice or provide relevant insights are acceptable and should not be criticized for being “too trivial” (in that case, soundness and relevance should be assessed carefully). Also, papers that confirm previous findings are encouraged (as long as findings are discussed in the context of previous works).

Quality: The extent to which the paper’s writing is clear, with well-organized descriptions and explanations, adequate use of the English language, absence of major ambiguities, clearly readable figures and tables, and adherence to the formatting instructions provided.

In addition to the above criteria, we also ask reviewers to comment on reproducibility and open science principles. The Call for Papers states that ICSA 2026 supports an Open Science policy. We expect authors to disclose (anonymized and curated) data/artifacts to increase reproducibility.

Reproducibility and Open Science: The extent to which the paper provides sufficient detail on methods and experiments and shares information and artifacts that are practical and reasonable to share to support replication and reproducibility. Note that suitable sharing depends on the type of paper. For example, qualitative interview transcripts often cannot be released due to de-identification risk, or industry data may contain trade secrets. Note that according to the Call for Papers, research papers that do not include an artifact should explain the reasoning for not being able to do that. Please comment on whether the explanation is reasonable for this paper.

3. Review Quality Criteria

• Reviewers will check that the review criteria (see above) are properly satisfied by the submissions evaluated. All reviews will comment on the review criteria.
• Reviewers will provide constructive suggestions or ideas to improve the quality of the paper (even if a paper is not accepted).
• Reviewers will describe criticisms and comments in an argumentative and reasoned way, using a polite tone. ICSA aims to provide a supportive community.
• Reviewers will suggest related work as required, such as empirical standards, related papers highly relevant to the community, open repositories, etc.
• In general, requests to cite a reviewer’s own work should be scrutinized more deliberately. If a reviewer believes that their work should be cited, then they should comment in the confidential remarks for the program committee so that the appropriateness of the request can be discussed among the reviewers and PC co-chairs.

Also note that this year ICSA is experimenting with an AI-based system to help chairs flag reviews that do not follow the review guidelines, especially when it comes to bias and constructive feedback. All reviews will be kept confidential, and results will just help PC chairs to moderate discussions.