Software Architecture ShowcaseICSA 2027

Call for Papers

The Software Architecture Showcase Track invites researchers and practitioners to contribute exemplar architectures, reusable benchmarks, technical artifacts, datasets, and tools that advance the practice and study of software architecture. Our goal is to create a curated collection of high‑quality, well‑documented assets pertaining to software architecture that the community can use for education, evaluation, and reproducible research.

Key aspects of this track include:

• Promote reuse: Foster sharing of software architecture-related artifacts (e.g., exemplars, models, datasets, tools, benchmarks) for a broad community adoption.
• Enable reproducibility: Provide clearly documented artifacts that allow others to replicate, compare, and extend prior work.
• Build infrastructure: Establish a repository of artifacts that can accelerate future empirical studies, tool evaluations, and teaching efforts

The track will accept four types of submissions:

1. Architecture exemplar: implementations of representative software systems that can be used to illustrate, benchmark, validate, or evaluate architectural methods and techniques.
2. Architecture-related artefacts: software architecture models, executables, reference architectures, architectural templates, architectural patterns and anti‑patterns defined in machine‑readable form, DSLs, or architectural description languages, among others.
3. Architectural Dataset: Curated collections of architecture‑related data, such as repositories of architectural metrics or smells, architecture-related logs, architecture decision records, traces of architectural evolution of projects, annotated corpora of design decisions and quality outcomes, among others.
4. Tool: Prototypes, plug-ins, or frameworks that support architecture design, analysis, or evolution, including: architecture visualization or exploration tools, static/dynamic analysis frameworks, architecture conformance tools, among others.

All of these submissions should be accompanied by a written description of the submission explaining its origins, context and characteristics (see below).

When present, the technical artifacts related to the submission should be made available at the time of submission for review, but will be considered confidential until publication. The technical artifacts should include detailed instructions about how to set up the environment (e.g., README.md), how to use them (e.g., how to import the data or how to access the data once it has been imported, how to use the tool with a running example). At a minimum, upon publication of the submission, the authors should archive the data or tool on a persistent repository that can provide a digital object identifier (DOI) such as Zenodo.org, Figshare.com, Archive.org, or institutional repositories. Where the artefact is an evolving item, such as an architectural style or pattern, and stored in a versioned repository (like GitHub or CodeBerg) the archived version should provide a URL to the repository. In addition, the DOI-based citation of the dataset or the tool should be included in the camera-ready version of the paper.

In the case of a dataset, if custom tools have been used to create it, then as well as the dataset and an accompanying description, the authors should provide the source code of the tools, and full or example input data, along with clear documentation on how the tools were run to create the dataset. The tools should be open source, accompanied by an appropriate license; the source code should be in a formal release. If authors cannot provide the source code or any data, or if the source code clause is not applicable (e.g., because the dataset consists of qualitative data), then authors should provide a short explanation of why this is not possible.

The descriptions provided with the submissions are expected to include:

1. Description:
   • Name
   • Background and Motivation
   • Novelty and Usability
   • Scope
2. Technical Details
   • For artifacts/datasets: provenance, methodology for collecting the data, storage format/schema.
   • For tools: detailed design, dependencies, and internal architecture.
   • Sample inputs and outputs, or a walk‑through of a running example.
3. Usage Instruction
   • A link to a repository or archive (see below for more details) containing the technical artifacts/tool.
   • Installation and usage instructions (e.g., requirements, configuration, execution steps).
4. Evaluation and Use cases
   • Example scenarios or benchmarks demonstrating the artifact’s value or usability for research or education.
   • Evidence of use (by authors or early adopters) or references to published works can be included.
5. Discussion
   • Potential research questions enabled by the artifact.
   • Planned future extensions and improvements.
   • Known limitations or challenges.

Evaluation Criteria

The review criteria for the Software Architecture showcase submissions are as follows:

• Relevance: Alignment with the software architecture scope and its value to the research and practitioner community.
• Practical Value and Usability: Clarity of how the system/artifact/datasets/tools can be used, and its usefulness in practice or research scenarios.
• Artifact Quality and Reusability: Clarity and completeness of the provided artifacts, including whether components are well-structured, well-documented, and reusable.

Submission

Submit your artefact description (formatted in IEEE format as double-column, maximum 4 pages, plus 1 additional page of references -- see below) via the EasyChair submission site: https://easychair.org/conferences?conf=icsa2027

Submissions will undergo single-anonymous peer review (i.e., authors’ names should be listed on the manuscript, the reviewer stays anonymous). All submissions must conform to the IEEE paper formatting and submission instructions. Submissions must conform to the IEEE conference proceedings template, specified in the IEEE Conference Proceedings Formatting Guidelines (title in 24pt font and full text in 10pt type, LaTeX users must use \documentclass[10pt,conference]{IEEEtran}.

ACM plagiarism policies and procedures shall be followed for cases of double submission. The submission must also comply with the IEEE Policy on Authorship. Please read the ACM Policy on Plagiarism, Misrepresentation, and Falsification and the IEEE - Introduction to the Guidelines for Handling Plagiarism Complaints before submitting. Submissions that do not comply with the above instructions may result in desk rejection without further review.

Upon notification of acceptance, all authors of accepted papers will be asked to complete a copyright form and will receive further instructions for preparing their artefacts and the camera-ready versions of their artefact descriptions. At least one author of each paper must register and present the results at the conference. All accepted contributions will be published in the conference’s electronic proceedings.