Software Architecture ShowcaseICSA 2026

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: representative software systems that are used to illustrate, benchmark, validate, or evaluate architectural methods and techniques.
2. Architecture-related artifact: 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.

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 (see below for more details). 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 paper, 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. 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, we expect the paper to be accompanied by the source code of the tools, along with clear documentation on how to run the tools to recreate 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 the source code clause is not applicable (e.g., because the dataset consists of qualitative data), the authors are expected to provide a short explanation of why this is not possible.

All 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. Replication Package
   • 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.

Best Practices in Sharing artifacts

Technical artifacts can be public or private (until the time of publication if accepted). artifacts should be clearly dated/versioned.

Therefore, for technical artifacts that are/can be made public before publication, we advocate the sharing via a version control system, in particular those supporting git and releases. In the spirit of transparency, independence, and perennity, CodeBerg should be the preferred choice: a community-driven, non-profit software development platform based on the open-source Forgejo software forge. CodeBerg is run by a registered non-profit association in Berlin, Germany. Alternatively, Zenodo could also be used because it is operated by CERN.

For artifacts that cannot be made public before publication, we suggest registering to Proton Drive and creating and sharing a folder in this drive. Proton is run by a Swiss company focused on private online services.

In all cases, the technical artifacts should be clearly dated/versions either using the intrinsic capabilities of the chosen platform or by naming the folders/archives with clear names, dates, and version number. (Archives should ideally be immutable, i.e., “solid”).

Evaluation Criteria

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

• Relevance and usefulness of the presented architecture, technical artifacts, datasets, or tools.
• Quality of the presentation.
• Clarity of relation with related work and relevance to research/practice.
• Availability of supporting technical artifacts.

Submission

Submit your paper (maximum 4 pages, plus 1 additional page of references) via the EasyChair submission site: https://easychair.org/conferences?conf=icsa2026

Submissions will undergo single-anonymous peer review (i.e., authors’ names should be listed on the manuscript, as opposed to the double-anonymous peer review of the main track).

All submissions must conform to the IEEE paper formatting and submission instructions

Submissions must strictly conform to the IEEE conference proceedings formatting and submission instructions. Alterations of spacing, font sizes, and other changes that deviate from the instructions may result in desk rejection without further review. LaTeX users should use the sigconf option, as well as the review (to produce line numbers for easy reference by the reviewers) option.

Papers submitted for consideration must not have been published elsewhere and may not be under review or submitted for review elsewhere for the duration of the review process until decision notification. 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 camera-ready versions. 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.