Skip to content

Architecture Decisions

This section documents important and large-scale decisions where multiple viable alternatives existed. This list excludes smaller-scale or less important decisions which may be documented in the sections that they apply to. The goal of this section is to provide the rationale behind major decisions which will allow re-evaluating them when circumstances change.

001: Use Layered Architecture

We use a three-layered architecture for the top-level decomposition of quantum software systems. The rationale behind this decision is documented in the building block view's motivation section.

002: Separate Design and Development Support Tooling from the main stack

In the FullStaQD Reference Architecture, we have made Design and Development Support Tooling a cross-cutting concept. This decision was driven by two main arguments:

  1. Separation of concerns: Design and Development Support Tooling is used to develop quantum software but it is not needed for the execution of the developed software1.
  2. Not layer-specific: Design and Development Support Tools exist for purposes on various layers, and some tools even cover multiple layers.

Alternatively, one could have added one Design and Development Support Tooling building block to each layer (adding redundancy and cluttering the main stack), or one could have added a separate high-level building block next to the three layers (which is conceptually similar to a cross-cutting concern).


  1. See Design and Development Support Tooling for a discussion on why the compiler is in the main stack nonetheless. ↩