ECSA 2024
Mon 2 - Fri 6 September 2024 Luxembourg, Luxembourg

Call for Papers

The European Conference on Software Architecture (ECSA) is the premier European software architecture conference, providing researchers, practitioners, and educators with a platform to share the most recent, innovative, and significant findings and experiences in the field of software architecture research and practice.

The 18th European Conference on Software Architecture (ECSA 2024) will be held from September 2 to 6, 2024 as an in-person conference taking place in Luxemburg.

Scope

The theme for ECSA 2024 is “trustworthy software”. With the increasing complexity of software and the black box nature of software components, it becomes more and more difficult - but at the same time also more important - to prove and demonstrate that we can trust software. At the same time, legislators introduce certification and regulations of software-based technology (e.g., the Digital Services Act and the AI Act in the European Union, the Software Bill of Materials mandated by the US government, or domain-specific compliance and data privacy requirements in sectors like banking). Also, end users demand explainable and understandable software. ECSA 2024 explores how software architecture can help with building trustworthy systems that are maintainable and evolve over time. This includes socio-technical aspects of trust (e.g., what trust means for different types of stakeholders), how we define and measure trust as a quality attribute, how software architecture can support transparency in software to increase the trust of technical and non-technical stakeholders, etc. In detail, we are interested in topics around provenance at the architecture level, data sovereignty and data ownership and control (e.g., in systems that utilize Large Language Models), explainable software and explainable AI from a software architecture perspective, software supply chains (e.g., Google’s SLSA) and architectural implications such as dependencies and security, how software architecture can support certification, governance and regulatory compliance. We are interested in learning about software architecture principles and practices, assurance methods from and for industry to architect trustworthy software, and methods to show the suitability of the software architecture for its intended application, including risk-driven architectures, and governance tactics to mitigate security threats in design decisions. Furthermore, we are interested in research and practical experiences in particular domains of trustworthy systems (e.g., large-scale national digital infrastructures and national digital ID systems).

The Program Committee of ECSA 2024 seeks submissions of original and unpublished high-quality papers on all topics related to software architecture and in particular the theme of ECSA 2024 outlined above. We particularly encourage papers that demonstrate that diversity in gender, culture, religion, country, etc. are key factors for success and innovation in software architecture.
Topics of interest include, but are not limited to:

  • Foundational principles of software architecture
  • Relationship of requirements engineering and software architecture
  • Quality attributes and software architectures
  • Architecture practices for secure, explainable, and trustworthy software
  • Architecture design and analysis
  • Architecture description languages and meta-models
  • Architecture verification and validation
  • Management of architectural knowledge, decisions, and rationale
  • Architecture patterns, styles, and tactics; reference architectures
  • Architecture viewpoints and views
  • Architecture conformance
  • Software architecture virtualization and visualization
  • Architecture-centric process models and frameworks
  • Software architecture and agile, incremental, iterative, and continuous development
  • Component-based models and deployment; middleware
  • Software architecture and system architecture
  • Software tools and environments for architecture-centric software engineering
  • Ethics, cultural, economic, business, social, human, and managerial aspects of software architecture
  • Architecture and technical debt
  • Software architecture education
  • Cross-disciplinary approaches to software architecture
  • Architectures for reconfigurable and self-adaptive systems
  • Architectural concerns of autonomic systems
  • Software architecture applied to new and emerging areas, such as the cloud/edge, big data, blockchain, cyber-physical systems, IoT, autonomous systems, systems-of-systems, energy-aware software, quantum computing, AI-enabled systems
  • Empirical studies, systematic literature reviews, and mapping studies in software architecture
  • Diversity, equity, and inclusion in activities related to software architecture

Paper Submissions

ECSA 2024 seeks four types of papers for the research track:

  • Research papers (max. 16 pages in LNCS style) which describe novel contributions to software architecture research (submissions should cover work that has a sound scientific/technological basis and has been validated)
  • Education and training papers (max. 16 pages in LNCS style) that address methodologies, experiences and best practices for teaching and training software architecture
  • Experience reports (max. 16 pages in LNCS style) that cover innovative implementations, novel applications, insightful performance results and experience in applying software architecture research advances to practical situations and systems
  • Short papers(max. 8 pages in LNCS style) that present novel and preliminary work-in-progress or challenges in a topic of software architecture research, education, and training. Submissions must have a sound basis, but not necessarily be validated in full.

All submitted papers will undergo a rigorous double-blind peer review process. Papers will be selected based on originality, quality, soundness, and relevance. All contributions must be original, not published, accepted, or submitted for publication elsewhere. Contravention of this concurrent submission policy will be deemed a serious breach of ethics, and appropriate action will be taken in all such cases. Plagiarism checking will be conducted and any paper reporting more than a 20% match with published work will be desk-rejected.

To note is that research papers, education and training papers, and experience reports that are rejected in their categories may be re-evaluated as short papers only if the committee decides on rejection of the full paper on the basis that it presents preliminary work.

The research track of ECSA 2024 supports an Open Science policy. We encourage all contributing authors to disclose (anonymized and curated) data/artifacts to increase reproducibility. Note that sharing research artifacts is not mandatory for submission or acceptance. Upon submission to the research track, authors are required:

  • To make their artifact available to the program committee (via a link to an anonymous repository) and provide instructions on how to access this data in the paper; or
  • To include in the paper an explanation as to why this is not possible or desirable; and
  • To indicate why they do not intend to make their data or study materials publicly available upon acceptance, if that is the case.

While sharing research artifacts is not mandatory for submission or acceptance, authors are required to include a Data Availability statement after the Conclusions section in a section named "Data Availability". This statement should explain whether or not data and/or artifacts are available or how they could be accessed (or not). Upon acceptance, papers with Open Science artifacts (e.g., data, tools, etc.) will be invited to upload their artifacts into the ECSA Zenodo community (https://zenodo.org/communities/ecsa) to make them accessible and visible to the ECSA community. Sharing artifacts via the ECSA Zenodo community is required for authors to be eligible for the best Open Artifact award.

All contributions must be formatted according to the Springer LNCS style http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0. Page limits include figures and references.

Contributions need to be submitted in PDF format via EasyChair to the ECSA 2024 Research Track: https://easychair.org/conferences/?conf=ecsa2024.

Please select the “Research Track” in EasyChair for your submission and click "Continue".

The proceedings will be published by Springer as part of the LNCS series.

We plan to organize a Special Issue on the theme of ECSA 2024 and to invite authors of selected papers to submit an extended version of their research.

Important Dates

Main Conference:

  • Abstract submission: April 11, 2024   April 18, 2024 (23h59, AoE)
  • Paper submission: April 18, 2024   April 25, 2024 (23h59, AoE)
  • Notification: May 30, 2024   June 3, 2024
  • Camera-ready paper: June 20, 2024   June 16, 2024 (23h59, AoE)

All dates are 23:59h AoE (Anywhere on Earth).

Organizers

  • Patrizia Scandurra, University of Bergamo, Italy
  • Matthias Galster, University of Canterbury, New Zealand

Review Instructions

1. Introduction

ECSA aims for an inclusive and transparent review process. The following document outlines review criteria for the “Research Papers” track at ECSA 2024 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 ECSA 2024 accepts different types of papers (see Call for Papers). The type of paper needs to be taken into consideration when evaluating the merit of a submission.
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.

  • 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 ECSA (while acknowledging that ECSA submissions are subject to the limitations of conference papers regarding lengths, etc.).

  • Numerical scoring: Reviewers should try not to be indecisive (i.e., by scoring most papers in the middle of the numerical range). Please take a stand. Whatever a reviewer’s position is, we ask 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 with respect to software architecture research, practice and education/training. ECSA 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 ECSA, 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).

  • For EXPERIENCE REPORT papers, the key concern is the relevance of lessons learned from the paper to software architecture research or practice. 

  • For EDUCATION AND TRAINING papers, the key concern is how other educators (in higher education or industry) can benefit from the work presented in the paper or learn from insights about how to teach and train (or not teach) software architecture-related topics.

  • For SHORT PAPERS, the key concern is how convincing the paper argues that the work, if fully completed, impacts software architecture research, practice or education and training.


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 acknowledge limitations and validity threats.

  • For EXPERIENCE REPORT and EDUCATION AND TRAINING papers, this typically entails appropriate discussion of the context in which the technology or techniques were applied, such that readers can understand the applicability of the lessons learned (rather than, e.g., controlled experimentation or proofs). 

  • SHORT PAPERS should have sound proposals for the research and the motivation for the proposed work.


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 of 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). 

  • EXPERIENCE REPORT and EDUCATION AND TRAINING papers need not always propose a novel technique, but should still add to the body of knowledge of software architecture in context (e.g., by offering insights into why or how a technique or method works or could be applied in a certain context).

  • SHORT PAPERS need to outline how, if the proposed work is completed, advances the body of knowledge in software architecture research, practice, or education and training (e.g., will the contribution be a new technique, new empirical evidence, experience). 


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. As stated in the Call for Papers, ECSA 2024 supports an Open Science policy. We encourage 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:

  • In RESEARCH PAPERS, qualitative interview transcripts often cannot be released due to de-identification risk or industry data may contain trade secrets. 

  • EDUCATION AND TRAINING might share teaching or training resources. 

  • EXPERIENCE PAPERS and SHORT PAPERS may not have any supplementary material. 

Note that according to the Call for Papers, research artifacts are not mandatory for submission or acceptance.


Data availability statement:

While sharing research artifacts is not mandatory for submission or acceptance, authors are required to include a Data Availability statement after the Conclusions section in a section named "Data Availability". This statement should explain whether or not data and/or artifacts are available or how they could be accessed (or not). More specifically, this statement could be used for the following:

  • To make their artifact available to the program committee (via a link to an anonymous repository) – and provide instructions on how to access this data in the paper; or

  • To include in the paper an explanation as to why this is not possible or desirable; and

  • To indicate why they do not intend to make their data or study materials publicly available upon acceptance, if that is the case. 

3. Review quality criteria

All the reviews are expected to meet the following criteria to provide authors with proper feedback:

  • 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. ECSA aims to provide a supportive community.

  • Reviewers will suggest related work as required, such as empirical standards, related papers highly relevant for the community, open repositories, etc. 

  • In general, requests to cite a reviewer’s own work are not allowed. Only on request,  providing a strong motivation for how the citation will improve the paper (and explaining why there are no alternative references), and after consultation with the PC co-chairs, citations to a reviewer’s own work might be allowed.