arXiv CSopen access

Architecting Hybrid Quantum-Classical Software Systems: Exploration of the Design Trade-off Space with Quantitative Guarantees

Architecting Hybrid Quantum-Classical Software Systems: Exploration of the Design Trade-off Space with Quantitative Guarantees ÁLVARO M. APARICIO-MORALES, JOSE GARCIA-ALONSO, and JUAN M. MURILLO, Uni-

arXiv:2606.24260v1 [cs.SE] 23 Jun 2026

versidad de Extremadura, Spain JAVIER CÁMARA, ITIS Software, Spain Abstract. Addressing problems beyond classical computing limits is sparking an increasing interest in Quantum Computing. However, despite their adequacy to address specific problems, quantum algorithms cover a limited subset of the functionality required in real-world computing systems. Additionally, they require expensive specialized hardware. To overcome this issue, hybrid (quantum-classical) software systems are emerging as a promising way to integrate both computing paradigms by applying the principles of ServiceOriented Architectures (SOA). Still, the design and deployment of hybrid service-based systems faces unique challenges like the idiosyncrasies and constraints of NISQ computers (e.g., algorithms that can only run in specific machines, disparate quality attribute metrics), and the management of structural and behavioural properties of service-based applications. From the SOA perspective, architectural decisions need to be made by performing a trade-off analysis and providing quantitative guarantees of system configurations under prescribed levels of uncertainty. In this paper, a method to explore the design space of quantum-classical applications is provided by a formalization of an architectural style of hybrid applications. The obtained results demonstrate that the proposed method successfully identifies decision boundaries. It enables the dynamic selection of the most suitable hybrid or classical configuration based on the user’s QoS criteria. CCS Concepts: • Software and its engineering → Software architectures; Automated static analysis; • Computer systems organization → Quantum computing. Additional Key Words and Phrases: Architectural Style, Tradeoff Analysis, Quantitative Guarantees, ServiceOriented Architecture, Quantum Software Engineering ACM Reference Format: Álvaro M. Aparicio-Morales, Jose Garcia-Alonso, Juan M. Murillo, and Javier Cámara. 2026. Architecting Hybrid Quantum-Classical Software Systems: Exploration of the Design Trade-off Space with Quantitative Guarantees. J. ACM 37, 4, Article 111 (August 2026), 31 pages. https://doi.org/XXXXXXX.XXXXXXX

1

Introduction

Quantum Computing (QC) brings the promise of a revolution in computing by providing capabilities to tackle problems that are either non-tractable or computationally prohibitive by today’s “classical” computing standards. Such capabilities include e.g., prime number factorization [47] and simulation of quantum phenomena in nature, such as solving Navier-Stokes equations for weather forecasting [18]. Although QC is in the Noisy Intermediate-Scale Quantum (NISQ) era [38], novel Authors’ Contact Information: Álvaro M. Aparicio-Morales, [email protected]; Jose Garcia-Alonso, [email protected]; Juan M. Murillo, [email protected], Universidad de Extremadura, Cáceres, Extremadura, Spain; Javier Cámara, [email protected], ITIS Software, Málaga, Andalucía, Spain. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM 1557-735X/2026/8-ART111 https://doi.org/XXXXXXX.XXXXXXX

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:2

Á.M. Aparicio-Morales et al.

solutions based on this technology are beginning to emerge [14, 49]. Therefore, it is expected that in the medium to long term, more quantum software will arise to tackle complex challenges [35]. However, despite its adequacy to address such specific classes of problem, QC covers only a narrow band of the spectrum of functionality needed to build real-world systems, which often require incorporating components to provide support for aspects such as logging, storage, and user interaction, to name a few. Furthermore, there are cases in which alternative quantum and classical implementations that cover the same functionality exist, and there are tradeoffs that make the choice of one alternative over the other more desirable, depending on the specific situation. Hence, the replacement of current classical components by their quantum counterparts results in systems with a hybrid (quantum-classical) workflow. This new type of hybrid software system must also operate under certain levels of trustworthiness and quality. Beyond their narrow scope of functionality, quantum algorithms require specialized hardware that is costly to buy and maintain. Indeed, in-house quantum hardware ownership and management is justified only in a very limited number of cases [36], and commoditization of quantum computing resources via platforms such as Amazon Braket (https://aws.amazon.com/braket/) or Azure Quantum (https://quantum.microsoft.com/) are progressively making quantum computing more affordable by providing it through models such as Quantum Computing as a Service (QCaaS) [19]. As a result, service-based hybrid quantum-classical applications are naturally emerging as a model that enables integrating classical and quantum computing by applying the principles of ServiceOriented Architectures [35]. However, to design quantum-classical applications that achieve a good balance among multiple non-functional properties, architects have to explore design spaces that are often poorly understood. Part of the intricacy in the design space stems from design decisions that often involve the selection and composition of loosely coupled, pre-existing components or services with different levels of quality (e.g., reliability, performance, cost) that may be offered by independent providers [31]. Moreover, beyond the constraints and the uncertainty that affects the behavior of the constituent components of classical service-based systems (e.g., faults, network delays, lack of control over third-party services residing in the cloud), quantum-classical servicebased systems are subject to additional constraints that are derived from the incorporation of quantum services that can be deployed only on specific hardware [44], have disparate attributes and pricing models [4], and are subject to additional sources of uncertainty (e.g., the output of a quantum circuit is generally not deterministic). For this reason, architects need tools and techniques that can help them explore these complex design spaces and guide them to good designs. Providing such tool support requires investigating the following questions: (RQ1): How can we automatically identify the set of configurations that satisfy the architectural constraints characteristic of quantum-classical service-based systems? (RQ2): How can we analyze the trade-offs among relevant non-functional system properties (e.g., cost, performance, reliability) in quantum-classical service-based systems across the architectural design space and under prescribed levels of uncertainty? Although there are existing approaches that enable the exploration of architectural design spaces under prescribed levels of uncertainty (e.g., Cámara et al. [13]), such proposals do not take into consideration some of the aspects that are unique to hybrid quantum-classical service-based systems. For this type of hybrid system, it is necessary to explicitly consider the characteristics of the hardware components, as well as the behaviour of the software, in order to identify the set of machines on which it can be executed. Likewise, it is necessary to establish a set of constraints for the service-machine relationship to ensure that the different deployment configurations are structurally correct. This combination of possible service-machine configurations implies that J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:3

the service quality attributes are dependent on the machine with which they are related. In this paper, this gap have been addressed by contributing: (i) a formalization of an architectural style for service-based quantum-classical applications, (ii) a method that exploits this formalization to automatically generate system configurations and deployments with quantitative guarantees about their quality levels under prescribed levels of uncertainty, and (iii) two case studies to evaluate our method that investigates our research questions. Our results demonstrate that the proposed method enables architectural decision-making for hybrid quantum-classical systems through the automated evaluation of the configuration space. Concretely, our approach allows for the identification of trade-offs among solutions, providing support for the selection of configurations that are appropriate to specific contexts of system use. The rest of the paper is organized as follows: Section 2 presents a scenario that motivates our proposal. Section 3 presents some background on quantum computing and the formal analysis technique that supports our approach. Section 4 describes our formalization and method for analyzing service-based quantum-classical system architectures. Sections 5 and 6 discuss evaluation and threats to validity, respectively. Section 7 discusses related work. Section 8 presents some conclusions and lines for future work. 2

Motivating Scenario

We illustrate our approach on a Hybrid Search Application (HSA), a service-based application that aims at detecting anomalous measurements in a sensor network (Figure 1). Sensors are exposed through services that send data upon request from an aggregator service, which merges the various sensor data streams and sends the aggregated data to a search service. The search service can be implemented either as a classical service that runs, e.g. a binary search algorithm, or as a hybrid (quantum-classical) service in which search is performed using quantum computing through Grover’s algorithm [22]. Finally, the result processing service is responsible for analysing the output of the search component and notifying the user of any possible anomaly. Given the architecture of this application, alternative configurations present disparate levels of execution time, cost, reliability and quantum error in results that depend, among other factors, on the machines (either quantum or classical), where services are deployed (i.e., the same service implementation may experience quality variations across different machines). Likewise, in this motivating scenario, the uncertainties emerge from three sources. First, errors can be produced in the service execution at run time, emerging from unhandled exceptions, malicious attacks, etc. Second, cloud provider infrastructure can experience problems that can affect the availability of their machines where the application is deployed [21, 51]. Finally, a third source of uncertainty is associated with errors in computational results that are produced by quantum computer noise [38] and affect the accuracy of results. In this context, finding an adequate architectural system design entails understanding the tradeoff space, identifying the set of configurations that satisfy: (i) a set of structural constraints (e.g., sensor services must not directly communicate with the search service), (ii) a set of behavioral properties (e.g., the system must eventually return a result), and (iii) a set of quality requirements that can be expressed, e.g., as a combination of quantitative constraints and optimization objectives, such as the ones illustrated in Table 1. Due to space reasons, the set of structural constraints and behavioural properties of the motivating scenario is collected in the Zenodo repository 1 . Generalizing this scenario, the problem we tackle is, given a set of constraints imposed by the architectural style of an application, as well as, a set of elements (service components, connectors,

1 Motivating Scenario Zenodo Link

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:4

Á.M. Aparicio-Morales et al.

computational resources such as quantum and classical processing units where services can be deployed), and a set of requirements (quality, behavioral), identifying the set of system configurations that satisfy structural constraints, along with behavioral and quality requirements.

«Component» Sensor

«Component» Sensor

«Component» Sensor

Legend Classical Component Quantum Component «Component» Aggregator

Hybrid Component Alternative Components Service's Communication Notification

«Component» Search «Component» Binary Search «Component» Result Processing

«Component» Grover

User «Component» Grover

«Component» Grover

Fig. 1. Architecture of the HSA System

Table 1. HSA - Quality of Service Requirements

Name R1 R2 R3 R4

Description The average execution time must not exceed 𝑡 s/request. Execution cost must not exceed 𝑒 usd/request. Failure rate must not exceed 𝑟 %. Quantum Error must not exceed 𝑞 number of wrong executions/request.

3 Background In this section, we first describe some context that concerns Quantum Computing, following with an introduction to the basics of the technique based on model finding and quantitative verification that we employ in our approach. 3.1

Quantum Computing

Quantum Computing is a paradigm based on leveraging quantum mechanics phenomena (e.g., superposition, entanglement) to perform computations using qubits, the fundamental units of quantum information. Superposition allows qubits to exist in a state where values are undetermined J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:5

until the system collapses. Entanglement occurs when qubits become strongly correlated, such that the state of one cannot be described independently of the other [38]. The Quantum Processing Unit (QPU) is the core component where computation takes place. It consists of a set of qubits distributed on a quantum chip, where operations are typically performed between pairs of qubits. Furthermore, current hardware technology makes qubits highly sensitive to environmental noise. Consequently, QPUs often yield error-prone results. Given these limitations, and the fact that current qubit counts are insufficient for addressing large-scale problems, the field is currently in the Noisy NISQ era [38]. Simultaneously, the lack of standardization in quantum hardware, combined with distinct problem-solving approaches, has led to the development of diverse QC technologies [44]. The most widespread is the gate-based quantum computers [4]; consequently, this type was selected for this study. It is considered the universal quantum computer [26]. Its operational model is analogous to classical CPUs, a set of logic gates (i.e., quantum gates) is applied to the bits (i.e., qubits) to perform computation. The arrangement of these gates on a set of qubits constitutes a quantum circuit. Key properties of a quantum circuit include its width, defined as the number of qubits involved in the computation, and its depth, defined as the longest path of sequential gates applied to a single qubit. Additionally, the number of shots represents the number of times the circuit is executed to obtain a result. These three metrics are critical factors in determining whether a specific quantum circuit can be successfully mapped onto a given target QPU. Moreover, current quantum hardware specification metrics are not the same for each quantum computer, and they depend on its provider. For instance, IBM offers a pricing model based on compute time per minute, whereas AWS Braket charges users based on the number of shots. Additionally, other metrics to evaluate performance on a quantum machine are appearing, such as Quantum Volume or CLOPS (Circuit Layer Operations per Second), making performance estimation different across platforms. In this study, the selected metric to evaluate the performance of a quantum machine is CLOPS because it was defined by IBM as a metric correlated with how fast a quantum processor can execute circuits. The downside of these NISQ devices is that they require special conditions to perform computations optimally. As a result, they can only be housed in large infrastructures, such as data centres or research facilities owned by governments and major multinational corporations [3]. Due to the stringent environmental and operational requirements for hosting quantum computers, most of them are accessible via cloud computing providers through their Software Development Kits (SDKs). This shift has enabled a new paradigm where these SDKs are used to develop classical services that act as entry points, by encapsulating the implementation of quantum algorithms in the cloud. This approach was proposed in [19] and was referred to as a hybrid (quantum-classical) service. By leveraging these hybrid services, it becomes feasible to integrate them into existing software systems, providing an alternative to traditional computational services that perform in the same way. However, bringing this promise to fruition requires making practical considerations related to the way in which hybrid (quantum-classical) services can be integrated into real-world information systems and harmoniously co-exist with classical computing forming hybrid quantum-classical software systems. In this context, ensuring trustworthiness in hybrid (quantum-classical) software is crucial to guarantee the reliability, security, and robustness of such integrated systems. 3.2 Model-Finding with Quantitative Verification In order to guarantee the structural validity of the generated design space while simultaneously assessing its quantitative characteristics, a framework that integrates structural constraints with stochastic behavioral properties is required. For this purpose, our proposal is underpinned by HaiQ [12]. This tool-supported approach synergizes probabilistic model checking [29] mechanisms J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:6

Á.M. Aparicio-Morales et al.

with model-finding capabilities in the style of Alloy [28], enabling the combined analysis of structural and behavioral properties in a quantitative fashion. As input, HaiQ receives two specifications: (i) a system model specified in a high level language (HaiQ) capable of capturing both structural and behavioral descriptions of system components, including probabilistic and other quantitative attributes (e.g., time, cost) and (ii) a set of formalized requirements specified in a temporal logic language (manifold probabilistic computation tree logic or M-PCTL) that extends the PCTL logic commonly used in probabilistic model checkers to express (mostly quantitative) properties about collections of systems variants that can be generated from a HaiQ specification. A HaiQ model includes both a set of signatures and a set of variables. A signature is a type definition from which multiple instances or objects of that type can be generated to build a model of a system variant. The specification of each signature contains two parts: structural and behavioral. The structural part captures relations between the instances defined by the signatures, while the behavioral part expresses the (possibly stochastic) behavior of the instances. A HaiQ specification is formally characterized as a tuple 𝑀 = ⟨𝐵, Σ, C⟩, where: • 𝐵 is a set of variables that range over finite integers or booleans. Variables can belong to a signature or be global. • Σ is a set of signatures that defines a hierarchy of types (including their behavior), where each signature 𝜎 ∈ Σ is defined as a tuple ⟨𝜎 ↑, 𝑚, 𝐴, 𝑅⟩: – 𝜎 ↑ is a (possibly empty) parent signature from which 𝜎 can inherit, meaning that it shares the same actions and variables as 𝜎 ↑ . – 𝑚 is the multiplicity of the signature that prescribes how many instances of 𝜎 can be generated. Allowed values are abstract, lone, one, some, set, which correspond to zero, at most one, exactly one, at least one, and any number of instances, respectively. – 𝐴 is a (possibly empty) set of actions 𝑎 = ⟨𝑔, D𝑈 ⟩, where the action’s guard 𝑔 is a boolean expression over the set of variables 𝐵, and D𝑈 is a discrete probability distribution over a set of updates 𝑈 . An update 𝑢 ∈ 𝑈 assigns new values to one or more variables in 𝐵. – 𝑅 is a set of relations with other signatures. A relation 𝑟 = ⟨𝑚𝑟 , 𝜎𝑟 ⟩ defines a relationship multiplicity 𝑚𝑟 that takes values in the same range as 𝑚, and a signature 𝜎𝑟 with which the relation is established. • C is a set of structural constraints over the relations defined by signatures in Σ, expressed in first-order predicate logic. Probabilistic Computation Tree Logic (PCTL) [24] is used to quantify properties related to probabilities and rewards in single system specifications described as a probabilistic state machine (e.g., discrete-time Markov chain -DTMC-, Markov decision process -MDP-, probabilistic timed automata or PTA). In contrast, M-PCTL targets quantification across collections of design alternatives that correspond, in this case, to the state machines generated from the set of architectural configurations that satisfy the constraints of a HaiQ specification. M-PCTL extends PCTL with checking of probability and reward-based properties to collections of models. Hence, quantification occurs over a pair (M, 𝜌), where M is a set of models, and 𝜌 is a set of reward functions. M-PCTL includes three types of formula. Similarly to PCTL, it includes path (𝜙) formulas (which are the same as in PCTL) and state (Φ) formulas, but also an additional type of set formula (Ψ) that returns the collection of models that satisfy a particular quantitative constraint. The syntax of M-PCTL is: Φ ::= true| 𝑎 | ¬Φ | Φ ∧ Φ | someP∼𝑝𝑏 [𝜙] | allP∼𝑝𝑏 [𝜙] | maxP∼𝑝𝑏 [𝜙] | minP∼𝑝𝑏 [𝜙] | someR𝑟∼𝑟𝑏 [𝜙] | allR𝑟∼𝑟𝑏 [𝜙] | maxR𝑟∼𝑟𝑏 [𝜙] | minR𝑟∼𝑝𝑏 [𝜙] Ð Ñ Ψ ::= 𝑈 | Ψ Ψ | Ψ Ψ | Ψ𝐶 | SsomeP∼𝑝𝑏 [𝜙] | SallP∼𝑝𝑏 [𝜙] | SmaxP[𝜙] | SminP[𝜙] | J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:7

SsomeR𝑟∼𝑟𝑏 [𝜙] | SallR𝑟∼𝑟𝑏 [𝜙] | SmaxR𝑟 [𝜙] | SminR𝑟 [𝜙] Concerning state formula quantifiers, allP and someP determine if the evaluation of 𝑃𝑟 (𝜙) on all or some model in M satisfies ∼ 𝑝𝑏, whereas maxP determines if the maximum probability evaluated across elements of M satisfies ∼ 𝑝𝑏. We define their semantics as: JsomeP∼𝑝𝑏 [𝜙]K ≡ ∃𝑀 ∈ M : 𝑃𝑟 𝑀 (𝜙) ∼ 𝑝𝑏 JallP∼𝑝𝑏 [𝜙]K ≡ ∀𝑀 ∈ M : 𝑃𝑟 𝑀 (𝜙) ∼ 𝑝𝑏 JmaxP∼𝑝𝑏 [𝜙]K ≡ max 𝑃𝑟 𝑀 (𝜙) ∼ 𝑝𝑏, 𝑀∈M

where 𝑃𝑟 𝑀 (𝜙) denotes the evaluation of the probability 𝑃𝑟 (𝜙) on model 𝑀. The analogous rewardbased quantifiers someR𝑟 , allR𝑟 , maxR𝑟 , and minR𝑟 , are defined over the expected reward measure of PCTL, instead of the probabilistic one 𝑃𝑟 (c.f. [29]). The use of maxP/minP and maxR/minR quantifiers without a bound implies the quantification of the actual maximum/minimum probability or reward for the path formula 𝜙, e.g.: JmaxP[𝜙]K ≡ max 𝑃𝑟 𝑀 (𝜙). In set formulas, 𝑈 denotes the 𝑀∈M

universe of models in M and Ψ𝐶 is the standard complement operator of set algebra. The semantics of the main quantifiers in set formulas is: JSallP∼𝑝𝑏 [𝜙]K ≡ {𝑀 : M | 𝑃𝑟 𝑀 (𝜙) ∼ 𝑝𝑏} JSmaxP[𝜙]K ≡ arg max 𝑃𝑟 𝑀 (𝜙) 𝑀∈M

Quantifier SsomeP returns a singleton with an element drawn nondeterministically from SallP∼𝑝𝑏 [𝜙] if the set is not empty, and ∅ otherwise. The previously defined formal model is concretely captured within the HaiQ specification language. As illustrated in Fig. 2, which depicts a portion of the motivating scenario, each formal component has a direct syntactic counterpart. This snippet allows for a detailed examination of how the theoretical definitions are instantiated. First, the bound 𝐵 is represented by the declared constant MAX_TIMEOUT. The set of signatures Σ is instantiated by the PU and QPU signatures. Specifically, the inheritance 𝜎 ↑ corresponds to the extends PU of the QPU signature. The multiplicity 𝑚 in the formal model is denoted by the keyword abstract. Furthermore, the set of actions 𝐴 can be observed in the line [services:qpair] true → (finished’=true);. Regarding the relationships 𝑅, these are represented within the PU signature, which contains the set of related services. Constraints 𝐶 are showcased in Listing 1, while the M-PCTL properties are defined in Listing 2.

Fig. 2. HaiQ Signature Examples const MAX_TIMEOUTS ; abstract sig PU { services : some Service } </ formula cpulogicalperformancefactor ; formula cpuram ; formula cpubandwidth ; formula cpucostfactor ; formula qpuprize ; formula clops ; formula readoutminerror ; formula readoutmaxerror ; formula cpuerrorrate ; />

abstract sig QPU extends PU {} </ formula cpulogicalperformancefactor ; formula cpuram ; formula cpubandwidth ; formula cpucostfactor ; formula qpuprize ; formula clops ; formula readoutminerror ; formula readoutmaxerror ; formula cpuerrorrate ; var finished : bool init false ; [ services : qpair ] true -> ( finished '= true ) ; />

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:8

Á.M. Aparicio-Morales et al.

all pu : PU | # pu . services > 0

Listing 1. HaiQ Example

4

Constraint

label success [ some Deployment : finishedOK = true ] property rangeP [ F success ] as reliability ; property rangeR { executiontimeRew } [ F done ] as execution_time ;

Listing 2. HaiQ Properties Example

Design Trade-off Space Framework for Hybrid (Quantum-Classical) Software Systems Approach's Overview «artifact» Application Specification H

«artifact» App Model

«artifact» Services Specification

«artifact» Cloud Machines Attributes H

«task» Suitable Machines Filter

«artifact» Suitable Machines

S1

S2

«task» Specification Manager

«artifact» Architectural Style Formalization H

«task» 0 Model File Generator

«artifact» Model

«task» Model Analyzer

«artifact» Tradeoff Spaces

S3 «artifact» Weights Utility Function H

«task» Utility Calculator

«artifact» Deployment Configuration File

S4

Legend H

Human Intervenction Required Automated Analysis External Data Input Internal Data Input Output generation

Fig. 3. Design Trade-off Space with Quantitative Guarantees Analyzer System for Hybrid Service Applications J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:9

The proposed framework enables the analysis of design trade-offs in qualities (e.g., cost, performance, reliability, and quantum error) of quantum-classical hybrid applications (Figure 3). The process receives as input a specification that contains the sets of requirements and resources available (e.g., machines, services), the behaviour model and constraints of the application, and the architectural style of hybrid service applications. Given this information, the process of generating different configurations and analysing them begins. This procedure is divided into four stages: (S1): Filtering. In which the elements that are not suitable to build feasible system configurations (e.g., QPUs that do not meet quantum service requirements) are discarded. (S2): Configuration Generation. During which alternative system configurations are generated. The process receives as input a specification of the available resources (services, suitable machines) and the intended application behavior (described as an abstract workflow in HaiQ), as well as a formalized description of our hybrid quantum-classical architectural style (as a set of first-order predicate logic constraints, cf. Section 4.1). It produces a set of probabilistic models, each of which captures the behavior of a legal architectural configuration. (S3): Configuration Analysis. The collection of models for each configuration is analyzed using quantitative verification techniques that check system properties formalized in the logic M-PCTL described in Section 3. (S4): Configuration Ranking and Selection. The set of configurations can be ranked and selected according to their qualities. Although multiple criteria can be employed, the current version of the proposal uses utility theory to rank configurations according to different contexts of use that consider concerns such as cost, execution time, reliability, and quantum error. In the remainder of this section, a description of the formalization of architectural style for service-based quantum-classical applications is presented, followed by a description of each of the stages in the process. 4.1

Architectural Style

The possible structures of a family of systems that are related by shared structural and semantic properties are characterized employing an architectural style [46]. Definition 1 (Architectural Style). The architectural style of a quantum-classical servicebased application is characterized as a 2-tuple A = ⟨Σ, C⟩, where: • Σ = ⟨𝑀, 𝑆, 𝐾, Π, Λ⟩ is an architectural signature, such that: – 𝑀 = 𝑀𝑞 ∪ 𝑀𝑐 is a set of processing unit types (machine types, for short), where 𝑀𝑞 and 𝑀𝑐 are disjoint sets of quantum processing units (QPU) and classical processing units (CPU) types, respectively. – 𝑆 = 𝑆𝑞 ∪ 𝑆𝑐 is a set of service types, where 𝑆𝑞 and 𝑆𝑐 are disjoint sets of quantum and classical service types, respectively. – 𝐾 is a set of connector types. – 𝑀 is a set of machine types. – Π : (𝑀 ∪ 𝑆 ∪ 𝐾) → 2 P is a function that assigns sets of symbols typed by datatypes in a fixed set D to architectural types 𝜅 ⊆ 𝑀 ∪ 𝑆 ∪ 𝐾. Π(𝜅) represents the properties associated with type 𝜅 (we denote a property 𝑝 ∈ Π(𝜅) simply as 𝜅.𝑝). ∗ For machines, 𝑚 ∈ 𝑀, the set of properties Π(𝑚) is a tuple (𝑠, 𝑚𝑐𝑟 , 𝑚𝑐𝑏 , 𝑚𝑐𝑐 , 𝑚𝑞𝑞𝑚𝑖𝑛 , 𝑚𝑞𝑞𝑚𝑎𝑥 , 𝑚𝑞𝑠 𝑚𝑖𝑛 , 𝑚𝑞𝑠 𝑚𝑎𝑥 ) ∈ 𝑆 × R3≥0 in which 𝑚.𝑠 ∈ 2𝑆 corresponds to the set of service types that can be deployed in 𝑚, whereas the remaining three propoerties are the memory, bandwidth, and processing capacity of 𝑚. J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:10

Á.M. Aparicio-Morales et al.

∗ For service types 𝑠 ∈ 𝑆 the set of properties Π(𝑠) are a tuple (𝑚, ℎ, 𝑠𝑐 , 𝑠𝑟 , 𝑠𝑏 , 𝑠 𝑓 , 𝑠𝑎 , 𝑠𝑒 , 𝑠𝑠 , 𝑠𝑑 , 𝑙) ∈ 2𝑀 × (𝑆𝑐 ∪ ∅) × R3≥0 , where 𝑠.𝑚 corresponds to the set of machine types in which 𝑠 can be deployed, 𝑠.ℎ is a classical service that wraps 𝑠 if it is a quantum service, and 𝑠.𝑠𝑐 , 𝑠.𝑠𝑟 , 𝑠.𝑠𝑏 , 𝑠.𝑠 𝑓 , 𝑠.𝑠𝑎 , 𝑠.𝑠𝑒 , 𝑠.𝑠𝑠 , 𝑠.𝑠𝑑 are the processing capacity minimum requirements, memory, bandwidth, percentage of reliability, online availability, baseline execution time, number of shots and the depth of the quantum circuit. Additionally, 𝑙 ⊆ 𝑆 is the set of services that 𝑠 can communicate with (either invoke or be invoked by). – Λ : (𝑆 ∪ 𝐾) → 2 P ∪ 2 R is a function that assigns a set of symbols typed by a fixed set R to connectors 𝜅 ∈ 𝐾. Λ(𝜅) represents the ports of a service (conversely, roles if 𝜅 is a connector), which define logical points of interaction with 𝜅’s environment. To denote a port/role 𝑞 ∈ Λ(𝜅), we write 𝜅 :: 𝑞. • C is a set of structural constraints that prescribes the set of legal configurations in A. Constraints in C are expressed in a constraint language based on first-order predicate logic in the style of Alloy [28], analogous to OCL [50] and Acme [20] (e.g., ∀𝑞 : 𝑆𝑞 • 𝑞.ℎ ∈ 𝑆𝑐 – “every quantum service must have a classical service wrapper”). Table 2 provides an excerpt of several constraints representative of our architectural style. 2 Definition 2 (Configuration). A configuration in an architectural style A = ⟨Σ, C⟩, given a fixed universe of architectural elements A Σ , is a graph G = (N, E) satisfying the constraints imposed by C, where N is a set of nodes, such that N ⊆ A Σ , and E is a set of of pairs typed by P × R that represent attachments between ports in services, and roles in connectors. We denote the type of an architecture element 𝑎 ∈ A Σ as 𝑡𝑦𝑝𝑒 (𝑎).

Table 2. Architectural Style - Constraints Description Every quantum service has to be associated with a classical service wrapper. A quantum service cannot share the classical service with which it is associated. Two services that form a hybrid service are communicated through a link. If a service is deployed on a machine, then that machine can only be related to that service.

4.2

FOPL Formalization

Alloy Formalization

∀𝑞𝑠 : 𝑆𝑞 • 𝑞𝑠 .ℎ ∈ 𝑆𝑐

all qs: QuantumService | qs.hybrid_service in ClassicalService

∀𝑞𝑠 , 𝑞𝑠′ : 𝑆𝑞 • 𝑞𝑠 ≠ 𝑞𝑠′ ⇒ 𝑞𝑠 .ℎ ≠ 𝑞𝑠′ .ℎ ∀𝑠, 𝑠 ′ : 𝑆 • (𝑠 ≠ 𝑠 ′ ∧ 𝑠.ℎ = 𝑠 ′ ) ⇒ (𝑠 ∈ 𝑠 ′ .𝑙 ∧ 𝑠 ′ ∈ 𝑠.𝑙 ) ∀𝑚 : 𝑀, 𝑠 :𝑆 • 𝑠 ∈ 𝑚.𝑠 ⇒ 𝑠.𝑚 = 𝑚

all qs, qs': QuantumService | qs != qs' implies qs.hybrid_service != qs'.hybrid_service all s, s': Service | s !=s' and s' in s.hybrid_service implies (s in s'.link and s' in s.link) all m:PU, s:Service | s in p.services implies s.machines = m

Filtering (S1)

The process receives as input a specification of the application that consists of two parts. The first part is a formal structural and behavioural description of the application’s services, including their hardware and non-functional requirements (cf. Table 3). The second part is a specification of the set of available processing units and their attributes, so that they can be adequately matched to suitable services. 2 Due to space constraints, we do not reproduce the whole set of constraints included in our formalization. The entire

specification, can be downloaded from Architectural Style link

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:11

Table 3. Non-Functional Service Requirement Attributes

Attribute id api mode

Description Mandatory Identifier string of the service ✓ URI for the service’s specification. ✓ Indicates the computing model used by the service (quan✓ tum or classical). memory Variable describing the required memory capacity, in MB. ✓ cpu Number of required CPU cycles for the service execution. ✓ execution_time Maximum execution time (seconds) of the classical ser✓ vice task. qubits Number of quantum bits used in quantum algorithm im×∗ plementation. num_shots Number of times the quantum algorithm is executed. ×∗ number_request Number of requests per minute received by the service. ✓ max_request_size Request maximum size in bytes. ✓ availability Number of hours per day the service is available. ✓ reliability Percentage representing the probability of successful ser✓ vice execution instances Number of service instances. ✓ mandatory Indicates if the service must appear in the deployment. ✓ ∗ Attributes presented only in quantum services.

According to the service requirements specifications and the hardware characteristics of the cloud providers’ machines, a set of suitable machines for each service is obtained. In order to make an assignment between a service and a set of candidate machines, a filter must be applied. Given the two types of services and processing units (quantum and classical), there is a filter for each of the types: (1) Given a classical machine 𝑚𝑐 ∈ 𝑀𝑐 with 𝑚𝑐𝑟 , 𝑚𝑐𝑏 , 𝑚𝑐𝑐 as the machine’s memory, bandwidth and processing capacity and being 𝑠𝑟 , 𝑠𝑏 , 𝑠𝑐 as the service’s minimum memory, bandwidth and processing capacity required, the following restrictions must be accomplished: 𝑀𝑐𝑠 = {𝑚 ∈ | 𝑡𝑦𝑝𝑒 (𝑚) ∈ 𝑀𝑐 ∧ 𝑠.𝑠𝑟 ≤ 𝑚.𝑚𝑐𝑟 ∧ 𝑠.𝑠𝑏 ≤ 𝑚.𝑚𝑐𝑏 ∧ 𝑠.𝑠𝑐 ≤ 𝑚.𝑚𝑐𝑐 } (2) Given a quantum machine 𝑚𝑞 ∈ 𝑀𝑞 with 𝑚𝑞𝑞𝑚𝑖𝑛 , 𝑚𝑞𝑞𝑚𝑎𝑥 , 𝑚𝑞𝑠 𝑚𝑖𝑛 , 𝑚𝑞𝑠 𝑚𝑎𝑥 as the machine’s minimum and maximum number of qubits and minimum and maximum number of shots and being 𝑠𝑞 , 𝑠𝑠 as the service’s minimum qubits and shots required, the following restrictions must be accomplished: 𝑀𝑞𝑠 = {𝑚 ∈ | 𝑡𝑦𝑝𝑒 (𝑚) ∈ 𝑀𝑞 ∧ 𝑚.𝑚𝑞𝑞𝑚𝑖𝑛 ≤ 𝑠.𝑠𝑞 ≤ 𝑚.𝑚𝑞𝑞𝑚𝑎𝑥 ∧ 𝑚.𝑚𝑞𝑠 𝑚𝑖𝑛 ≤ 𝑠.𝑠𝑠 ≤ 𝑚.𝑚𝑞𝑠 𝑚𝑎𝑥 } As a result, a set of pairs of (services, (classical machines, quantum machines)) is obtained from the services’ application and a set of quantum and classical machines 𝑀. The set of machines that satisfy the constraints for service 𝑠 is 𝑀 𝑠 ≡ 𝑀𝑐𝑠 ∪ 𝑀𝑞𝑠 , taking into account the two definitions proposed above. 4.3

Configuration Generation (S2)

This stage focuses on the synthesis of the set of potential architectural configurations for the application. To this end, both a formalization of the architectural style described earlier in this J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:12

Á.M. Aparicio-Morales et al.

section, as well as a description of the set of services and the set of suitable machines for each application’s service obtained in the previous stage, are integrated into a single formal specification. Such specification is encoded in a subset of the language Alloy, which is employed to define the structural part of a HaiQ model. This process includes the definition of: • Signatures: The creation of structures representing the services and their potential associated machines. In Listings 3 and 4 an example of the two principal signatures is provided: abstract sig Service { machines : some PU , deployment : one Deployment , hybrid_service : set Service , link : some Service }

abstract sig PU { services : some Service }

Listing 4. Processing Unit Signature

Listing 3. Service Signature abstract sig QuantumGroveralg extends QuantumService {} abstract sig Binarysearch extends ClassicalService {}

Listing 5. HSA Signature Examples

The PU signature includes the services attribute of type Service. This attribute denotes the service that is deployed on the PU. The Service signature is defined by the following attributes: – machines: Refers to the machine on which the service is deployed. It corresponds to an element 𝑚 of the set 𝑀 𝑠 resulting from stage S1. – deployment: Refers to the deployment configuration to which the service belongs. – hybrid_service: Corresponds to property ℎ of the architectural style. – link: Corresponds to property 𝑙 described in the architectural style. Two examples of signatures from the motivating scenario are showed in Listing 5. • Constraints: The definition of association restrictions between services and machines. These limitations are formalized through an Alloy predicate, which defines the model’s constraints. Some examples of constraints are collected in the Table 2. Also, specific constraints related to the hybrid application are used to build de HaiQ model. Listing 6 collects two examples of the motivating scenario. all ag : Aggregator | #( ag . link & ( QuantumGroveralg + Resultprocessing + Aggregator ) ) = 0 and #( ag . link & ( Binarysearch + Groveralg ) ) > 0 all qg : QuantumGroveralg | #( qg . link & ( Sensor + Aggregator + Resultprocessing ) ) = 0

Listing 6. HSA Constraint Examples

• Execution Scope: For the generation of the set of potential configurations for the application, the minimum number of execution instances for the predicate must be specified, ensuring the existence of at least one machine instance for each service. For example, if after phase S1, a set of three classical machines has been obtained for the Motivating Scenario, and its total number of classical services is six, then for each machine obtained, at least six instances of that machine must be generated, one for each service. This ensures that there are enough instances for all services. This is specified in the HaiQ model with the statement included in the Listing 7. run show for 6

Listing 7. Execution Escope

For the generation of the configuration space we employ the HaiQ analyzer tool, which is able to synthesize valid architectural configurations satisfying the defined constraints. The resulting set of configurations enables the analysis of properties of interest across the solution space, which is described in the next section. J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

4.4

111:13

Configuration Analysis (S3)

This stage concerns the quantitative analysis of trade-offs across the solution space generated in the previous phase. To conduct this analysis, the model is enriched with detailed information regarding behavioral and quantitative aspects (e.g., quality attributes encoded as costs or rewards) of various architectural elements, such as those that represent services and machines. The analysis of the configuration space is carried out by evaluating the four key Quality of Service (QoS) dimensions established in the Table 1 (cost, execution time, reliability, and quantum error). The calculation of each dimension is implemented via a reward system, where a value is assigned to each state transition action (e.g., the pairing between a service and a machine). This process yields the quantitative value associated with each dimension for every configuration. The methodology for obtaining the metrics for each studied dimension is detailed below, illustrated with examples from the motivating scenario: • Cost: Represents the total economic cost associated with using the configuration. It is calculated as the weighted sum of the usage costs of both classical and quantum machines. The reward for each service is calculated based on its nature (classical 8 or quantum 9) and is typically measured in terms of price/request. Listing 8 and Listing 9 detail the reward for each type. // Classical service reward costRew [ machines : cpair ] true : machines . cpucostfactor /( numberrequest *60) ;

Listing 8. Classical Service - Cost Reward // Quantum Service reward costRew [ machines : qpair ] true : (( machines . qpuprize ) /60) *( depth / machines . clops ) * shots ;

Listing 9. Quantum Service - Cost Reward

In the case of a hybrid service, the total cost is the result of the addition of the cost of its classic and quantum services. • Execution Time: This metric, quantified in nanoseconds/request, reflects the time required to complete the task associated with the service. The execution time is directly dependent on the characteristics of the associated machine. A machine with higher capabilities executes the corresponding service task more rapidly. // Classical Service reward executiontimeRew [ machines : cpair ] true : msexecutiontime *( mslogicalperformancefactor * msram * msbandwidth ) /( machines . cpulogicalperformancefactor * machines . cpuram * machines . cpubandwidth ) ; reward executiontimeRew [ machines : cpupenalty ] true : msexecutiontime *( mslogicalperformancefactor * msram * msbandwidth ) /( machines . cpulogicalperformancefactor * machines . cpuram * machines . cpubandwidth ) ; reward executiontimeRew [ machines : mspenalty ] true : msexecutiontime *( mslogicalperformancefactor * msram * msbandwidth ) /( machines . cpulogicalperformancefactor * machines . cpuram * machines . cpubandwidth ) ;

Listing 10. Classical Service - Execution Time Rewards // Quantum Service reward executiontimeRew [ machines : qpair ] true : ( depth / machines . clops ) * shots ;

Listing 11. Quantum Service - Execution Time Reward

The execution time is quite different between the two existing types of services. In the classic ones (detailed in Listing 10), the total execution time includes the time of executing the request and the penalty times. In this scenario, the two penalty times [machines:cpupenalty] and [machines:mspenalty] correspond to hardware and software failures. These penalties have been established as the total request execution time. On the other hand, the quantum service J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:14

Á.M. Aparicio-Morales et al.

only takes into account the execution time of the quantum algorithm, as it is illustrated in Listing 11. • Reliability: Service reliability is a composite factor that includes both a hardware and a software component. Reliability is only associated with classical services and during the servicemachine pairing phase (service association/deployment on a machine, see in Listing 12) is determined by the hardware component. In contrast, reliability during the operational phase (upon receiving the process request) is related to the stability of the software component as it is shown in Listing 13. // Hardware Transition [ machines : cpair ] ( currentstatus = initial ) -> machines . cpuerrorrate : ( currentstatus '= cpuerror ) & ( penalty '= true ) + 1 - machines . cpuerrorrate : ( currentstatus '= deployed ) ;

Listing 12. Hardware Reliability Transition // Software Transition [ deployment : SearchActivationCall ] ( currentstatus = ready ) -> mserrorrate : ( currentstatus '= mserror ) & ( penalty '= true ) + 1 - mserrorrate :( currentstatus '= running ) ;

Listing 13. Software Reliability Transition

• Quantum Error: This metric quantifies the number of executions that provide wrong results obtained by the service. Given the nature of the current NISQ (Noisy Intermediate-Scale Quantum) era of quantum computers, these devices introduce significant noise into execution results, making this a critical factor to consider. Its corresponding reward is detailed in Listing 15. For classical services, the quantum error is considered null as it is reflected in Listing 14. // Classical service reward quantumerror [ machines : cpair ] true : 0;

Listing 14. Classical Service - Quantum Error Reward // Quantum service reward quantumerror [ machines : qpair ] true : ((( machines . readoutminerror ) +( machines . readoutmaxerror ) ) /2) * shots ;

Listing 15. Quantum Service - Quantum Error Reward

Considering these metrics, the probabilistic model checking tool PRISM, integrated into the HaiQ environment, evaluates each of the defined properties across the entirety of the trade-off space. This process yields a set of valid configurations, each associated with a set of quantitative values for the studied quality dimensions.

4.5

Configuration Ranking and Selection (S4)

This last stage of the process involves the evaluation of the various configurations with the objective of obtaining the optimal solution of the assessed model. This part of the process incorporates user preferences regarding the relative importance of the various dimensions of concern (e.g., timeliness, quantum error). The result of this phase will be the solution(s) that better optimize such preferences. Although there are various ways to identify the solutions that best match user preferences, in this case, we use Utility Theory, which enables us to seek the outcome that maximizes user satisfaction. To accomplish this, we employ a simple weighted additive utility function: 𝑈 (𝑥) =

𝑛 ∑︁ 𝑖=1

where: J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

𝑎𝑖 𝑥 𝑖

Architecting Hybrid Quantum-Classical Software Systems

111:15

• 𝑈 (x): The total utility value for a set of dimensions x = (𝑥 1, 𝑥 2, . . . , 𝑥𝑛 ). • 𝑛: The total number of dimensions or features considered in the model. • 𝑥𝑖 : The value of the 𝑖-th dimension or characteristic being studied. In this case, this value could represent execution time, cost, reliability, and quantum error. • 𝑎𝑖 : The weight or coefficient assigned to the 𝑖-th dimension. These weights are typically normalized such that their sum is equal to 1. The utility-weighted function used in the Evaluation Section 5 is: 𝑈 (𝑥) = 𝑤𝑐𝑜𝑠𝑡 𝑥𝑐𝑜𝑠𝑡 + 𝑤𝑒𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛𝑡𝑖𝑚𝑒 𝑦𝑝𝑒𝑟 𝑓 𝑜𝑟𝑚𝑎𝑛𝑐𝑒 +𝑤𝑟𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡 𝑦 𝑧𝑟𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡 𝑦 + 𝑤𝑞𝑢𝑎𝑛𝑡𝑢𝑚𝑒𝑟𝑟𝑜𝑟 𝑤𝑞𝑢𝑎𝑛𝑡𝑢𝑚𝑒𝑟𝑟𝑜𝑟 where 𝑤𝑐𝑜𝑠𝑡 , 𝑤𝑒𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛𝑡𝑖𝑚𝑒 , 𝑤𝑟𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡 𝑦 , 𝑤𝑞𝑢𝑎𝑛𝑡𝑢𝑚𝑒𝑟𝑟𝑜𝑟 are coefficients defined by the user for their corresponding dimension, such that (𝑤𝑐𝑜𝑠𝑡 + 𝑤 𝑝𝑒𝑟 𝑓 𝑜𝑟𝑚𝑎𝑛𝑐𝑒 + 𝑤𝑟𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡 𝑦 + 𝑤𝑞𝑢𝑎𝑛𝑡𝑢𝑚𝑒𝑟𝑟𝑜𝑟 = 1). Finally, obtaining the set of best configurations (x∗ ) is the result of applying: x∗ = argmaxx (𝑓 (𝑥)) In order to apply the utility function, the values of the analyzed dimensions were normalized to a common [0, 1] range. The goal of this transformation is for 0 to represent the minimum utility and 1 to represent the maximum utility. Since the results of the analysis contain metrics that need to be maximized (like reliability) and minimized (like cost, execution time, and quantum error), the Min-Max normalization method was adjusted based on each variable’s nature, inverting the scale where required.

5

Evaluation

The purpose of this evaluation section is to explore the research questions described in the introduction, using as a vehicle to do so a prototype implementation of our approach. This section is structured as follows: firstly, the Experimental Setup section 5.1 details the conditions under which the experiments were conducted. Secondly, the Results 5.3 section presents an analysis of the experiments. Finally, the Discussion section 5.4 provides the answers to the proposed research questions (RQ1 and RQ2). 5.1

Experimental Setup

To evaluate our approach, two use cases were selected. The first is the Hybrid Search Application, previously detailed in Section 2. The second use case is a Weather Forecast Hybrid System detailed in Section 5.2. To run our experiments, the following computer and software requirements have been used: • macOS Ventura (version 13.7.1) • Intel Core i5 with dual-core, running at 2.3GHz. • 16GB of RAM. • HaiQ Relational Probabilistic Model Analyzer v0.2a The final HaiQ generated models are published in this Zenodo repository 3 . To evaluate the generated HaiQ models, four M-PCTL properties targeting reliability, execution time, cost, and 3 HaiQ Models

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:16

Á.M. Aparicio-Morales et al.

quantum error have been defined. These properties leverage cumulative rewards that are computed until the system reaches a termination state (labeled as success or done). 5.1.1 Implemented Analyzing Tool. The analysis tool was developed using Python 3.11.9. The workflow initiates with the ingestion of system specifications through a web-based interface. A core feature of the implementation is the automated generation of HaiQ models derived from the developed architectural style of hybrid (quantum-classical) service applications and the application specification. The data distribution across the system’s components is handled via a pub-sub protocol implemented with Apache Kafka. Once the simulation finishes, the architectural configurations based on the applied multi-dimensional utility function are ranked and shown on the website. This quantitative analysis is complemented by a specialized data processing pipeline using Pandas 4 and Jupyter Notebooks 5 , which facilitates the rendering of decision region maps and statistical visualizations. 5.2

Weather Forecast Hybrid System

The architecture depicted in Figure 4 reflects a simplified structure of the weather forecasting system presented in [3]. The primary objective of these systems is to provide routine weather forecasts. However, there are exceptional use contexts that require of obtaining rapid predictions, especially in climate emergency situations (such as isolated high-level depressions or DANAs, flash floods, tornadoes, among others) where the window of opportunity to issue a warning is critical for civil safety. Structurally, these systems typically comprise a data collection layer, represented in our case study by two weather stations (WSS). This information is sent to an intermediate node, the Data Processing Service (DPS), which is responsible for structuring and organizing the data. Following this processing, the information is stored in a database (Weather Forecast Database, WFD) that feeds the forecasting models. These models are triggered by the Weather Launcher Service (WLS). Once the execution is complete, the resulting information is stored back into the database. Finally, the results processing service (WMP) retrieves the prediction to be interpreted by a meteorologist. In this study, the weather models can be either purely classical (CWFM) or hybrid, incorporating quantum components (HWFM). Their selection will depend on the urgency and context of the forecast. Notably, this WFHS use case considers alternatives not only for the forecast model (classical vs. quantum) but also for the WSS, DPS, and PRS classical components. 5.3

Results

After conducting the configuration space exploration for both use cases with the HaiQ tool, a total of 7680 instances (1536 classical vs 6144 hybrid instances) were obtained for the motivating scenario (HSA) and 3456 instances (1152 classical vs 2304 hybrid instances) for the WFHS. Table 4 shows the total analysis time for each case. It is worth noting that, despite the notable difference in the volume of instances generated (Δ = 4224), the analysis times present great similarity. This circumstance is attributed to the variability in structural complexity and the state space generated by the models due to their behavior. Likewise, the evaluation times for each dimension studied (cost, execution time, reliability, and quantumerror) are broken down in said table. Next, the analysis of the results is presented, starting with the HSA, followed by the HWFS. 4 Pandas 5 Jupiter Notebook

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:17

Legend Classical Component «Component» Weather Station

Quantum Component

«Component» Weather Station

Hybrid Component Alternative Components

«Component» Data Processing Service

Service's Communication Notification «Component» Weather Forecast Database

«Component» Weather Launcher

«Component» Weather Forecast Model «Component» Classical Weather Forecast Model «Component» Weather Model Processing

«Component» Hybrid Weather Forecast Model (HWFM)

Meteorologist «Component» HWFM

«Component» HWFM

Fig. 4. Architecture of the WFHS System

Table 4. Evaluation time of each dimension

Use Case HSA WFHS

Instances Generated 7680 3456

Evaluation Time (h) 4.18 4.08

Cost (s) 3463.2 3595.4

Execution Time (s) 3481.5 3600.6

Reliability (s) 4544.3 3820.7

Quantum Error(s) 3418.6 3625.5

5.3.1 Hybrid Search Application. As detailed previously in Section 2 (Motivating Scenario), the Hybrid Search Application serves as a compact practical example of a hybrid system used to validate the proposed method. This application is composed of four types of services: three sensor services, an aggregator service, a search service (either classical or quantum), and a result processing service. In the Figure 5, all the possible configurations are represented. The primary objective of this analysis is to demonstrate the validity of the proposed system in facilitating architectural deployment decisions for systems integrating equifinal services. Specifically, the aim is to explore the entire design space to identify the most suitable service-machine pair configuration. This selection is driven not only by constraints, such as execution time limits and tolerance to quantum error, but also by the pursuit of dynamic adaptation according to potentially changing user preferences. To evaluate this adaptability, the set of configurations was subjected to five distinct scenarios. Each scenario represents a variation in the weights assigned to each studied dimension within the utility function: J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:18

Á.M. Aparicio-Morales et al.

Fig. 5. Design Space of Hybrid Search App Table 5. Weight configurations for different optimisation scenarios.

Scenario 𝑤𝑐𝑜𝑠𝑡 1 - Cost priority 0.7 2 - Execution time priority 0.1 3 - Reliability priority 0.1 4 - Quantum error priority 0.1 5 - Equal importance 0.25

𝑤𝑒𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛𝑡𝑖𝑚𝑒 0.1 0.7 0.1 0.1 0.25

𝑤𝑟𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡 𝑦 0.1 0.1 0.7 0.1 0.25

𝑤𝑞𝑢𝑎𝑛𝑡𝑢𝑚𝑒𝑟𝑟𝑜𝑟 0.1 0.1 0.1 0.7 0.25

The results for these scenarios is visualized in Figures 6a-6e. These figures display the resulting decision region maps for each scenario, representing the optimal solution type selected under varying constraints of execution time and quantum error. The selection of these two variables is justified as they constitute the primary competing constraints in quantum software engineering. On the one hand, execution time reflects the configuration’s performance, while on the other, quantum error captures the fidelity limitations inherent to current NISQ computers. Ultimately, both determine the architectural decision boundary. Regarding the figures, the following interpretations can be done: • In Scenarios 1 and 4, where cost and result precision are prioritized respectively, a clear dominance of classical configurations over hybrid ones is visualized. Hybrid configurations only begin to be selected when execution time constraints are strict (execution time < 200). In this sense, the proposed system discards the hybrid option due to its high costs and the presence of execution errors stemming from the NISQ era of quantum computers. • In Scenarios 2 and 3, the system proposes the hybrid option as the dominant type of configuration across a large portion of the design space. This is because of a smaller cost priority J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

.

111:19

(a) Scenario 1: Cost Priority

(b) Scenario 2: Time Priority

(c) Scenario 3: Reliability Priority

(d) Scenario 4: Quantum Error Priority

.

(e) Scenario 5: Balanced

Fig. 6. Decision region representation of the optimal configurations for the Hybrid Search Application across five different scenarios.

(𝑤𝑐𝑜𝑠𝑡 = 0.1), compared to other scenarios; hybrid solutions are less penalized. This validates the premise that in environments where execution times or reliability must be prioritized over budget, the architecture should be oriented towards configurations that provide results in a timely manner. • Thirdly, in the balanced scenario, the system prioritizes classical solutions, maintaining control over cost and precision. In contrast, for stricter time constraints, the set of hybrid configurations becomes optimal as classical solutions cannot operate within those limits. • Finally, it is noteworthy that in all scenarios, there exists a set of constraints strict enough to indicate that, given the characteristics of the established services for the use case and the selected set of machines, no valid solutions are yielded for those criteria. In this regard, the proposed system informs the software architect of the existence of a design space where the J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:20

Á.M. Aparicio-Morales et al.

physical boundaries of the current system are delimited. Thus, the system acts as a diagnostic tool, indicating the possible need to refactor the architecture. 5.3.2 Weather Forecast Hybrid System. To provide a generalization of the obtained results and mitigate potential domain-specific dependencies, the analysis proceeds to the second proposed case study; the Hybrid Weather Forecast System. The main objective of this scenario is to evaluate the architectural trade-off between classical solutions, which offer high-precision predictions at the expense of high computational time, and hybrid configurations, which enable faster result generation by sacrificing exactitude. This analysis is conducted within the constraints imposed by the current state of NISQ devices on the design space.

Fig. 7. Solution Space of Weather Forecast Hybrid System

5.3.2.1 Global Solution Space Exploration. Figure 7 shows the generated 3456 configurations. Visual analysis reveals a topology characterized by three completely disjoint data clusters, the separation of which is attributed to the nature of the utilized computational hardware. Specifically, a first cluster is identified corresponding to the classical solutions (1152 configurations), alongside two additional clusters associated with hybrid solutions, differentiated by the QPU provider (IBM and IQM, with 1152 configurations for each one). Upon examining Figure 7, which depicts the architectural trade-offs, classical solutions dominate the result quality dimension (ensuring zero quantum error. It is appreciated in Figure 8c). Conversely, they incur significantly higher execution times. On the other hand, hybrid alternatives excel in the execution time dimension, offering a drastic reduction. However, they are outperformed in terms of economic cost and result quality. For a more detailed quantitative analysis, in Figures from 8a to 8c a comparative box-plot visualization of the four studied dimensions is provided. In terms of cost, classical configurations J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:21

shows a minimal cost profile, represented by a nearly flat boxplot at the lower bound of scale. On the other hand, hybrid configurations shows a significant value of cost higher thant the classical ones. Additionally, the hybrid box suggests that the pricing is sensitive to the quantum machine selected because of the large interquartile range. Comparing the execution time, hybrid configurations exhibit a performance advantage, reducing the median execution time to approximately 1500 ns. Conversely, classical solutions operate at a significantly slower baseline, clustering tightly just above the 5000 ns mark. Notably, unlike the other metrics, reliability does not serve as a clear discriminating factor between clusters; rather, it appears homogeneously distributed throughout the entire design space. This statement is illustrated in Figure 8d. This global characterization of the design space does not, in itself, resolve the architectural choice; rather, the suitability of a solution fluctuates according to the temporal constraints imposed by the context. Subsequently, the global utility of the generated configurations is evaluated under two opposing weather scenarios, modeling how the urgency of obtaining a weather forecast serves as a determining factor.

.

(a) Cost

(b) Execution Time

(c) Quantum Error

(d) Reliability

Fig. 8. Comparison of dimensions by configuration type

5.3.2.2 Context-Aware Decision Making. Normal weather forecast. The first established context models the generation of conventional weather forecasts. In this scenario, execution time is not a priority, therefore, solutions with high quality and low monetary cost are sought. To achieve this, weights are assigned within the utility function to increase high solution quality and low monetary cost (𝑤𝑐𝑜𝑠𝑡 = 0.5; 𝑤𝑒𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛𝑡𝑖𝑚𝑒 = 0;𝑤𝑟𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡 𝑦 = 0; 𝑤𝑞𝑢𝑎𝑛𝑡𝑢𝑚𝑒𝑟𝑟𝑜𝑟 = 0.5). J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:22

Á.M. Aparicio-Morales et al.

Under these conditions, the design space of optimal solutions points out classical configurations. Consequently, their ability to deliver high-quality predictions at a low cost maximizes global utility. Conversely, hybrid solutions, despite their low execution times, are relegated due to penalties incurred in the quality and cost dimensions, yielding marginal utility values in this context. Table 6 lists the top 5 solutions, ranked from highest to lowest utility. However, Figure 9 reveals the comprehensive scope of the design space for the weather forecast scenario. In this regard, the heatmap demonstrates that optimality is not absolute but contingent upon the constraints imposed on the system. The plot clearly delineates the decision boundaries where the system transitions toward hybrid configurations (in orange) or alternates between distinct classical architectures to maximize the utility function.

Fig. 9. Normal Forecast Scenario - Optimal Solutions

Table 6. Normal weather forecast scenario - Top 5 solutions

Solution

Cost ($/𝑟𝑒𝑞)

sol-406 sol-976 sol-1117 sol-548 sol-370

0.435501 0.435501 0.435806 0.435806 0.437051

Execution Time (ns/𝑟𝑒𝑞) 5120.023297 5084.576769 5045.983657 5084.023228 5115.606844

Reliability (%) 86.837789 83.122861 79.061943 82.951582 86.629120

Quantum Error (𝑁𝑜. 𝑠ℎ𝑜𝑡𝑠 𝑤𝑖𝑡ℎ 𝑒𝑟𝑟𝑜𝑟 /𝑟𝑒𝑞) 0.0 0.0 0.0 0.0 0.0

Emergency Weather Forecast. In this second context, an alert situation is modeled. Given this scenario, priorities are drastically inverted, assigning greater weight to execution time and imposing a stricter temporal constraint (between 1000 and 2000 ns/request). Consequently, classical weather forecast configurations fail to meet the established restriction, rendering their utility zero in this scenario. In this context, hybrid configurations emerge as the only viable alternative satisfying the defined bounds. Furthermore, within the set of hybrid configurations, it is necessary to determine the J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:23

most suitable architecture. To this end, Table 7 lists the top 5 solutions for this scenario, seeking to balance cost, reliability, and precision against execution time. Additionally, Figure 10 illustrates the evolution of the optimal solution within the design space constrained by execution time and precision. Notably, the tonal variations denote transitions between distinct hybrid architecture configurations, demonstrating the system’s capability to identify the best possible configuration in response to varying Quality of Service (QoS) requirements.

Fig. 10. Emergency Forecast Scenario - Optimal Solutions

Table 7. Emergency weather forecast scenario - Top 5 solutions

Solution

Cost ($/𝑟𝑒𝑞)

sol-2689 sol-2682 sol-2729 sol-2666 sol-2688

14.072453 14.031743 14.077542 14.036831 14.071235

5.4

Execution Time (ns/𝑟𝑒𝑞) 1416.442747 1417.176797 1416.432423 1417.166631 1416.547517

Reliability (%) 86.690606 86.765443 86.615533 86.690606 86.569894

Quantum Error (𝑁𝑜. 𝑠ℎ𝑜𝑡𝑠 𝑤𝑖𝑡ℎ 𝑒𝑟𝑟𝑜𝑟 /𝑟𝑒𝑞) 385.249940 385.249943 385.249936 385.249940 385.249934

Discussion

Following an exhaustive analysis of the results obtained for both case studies, the subsequent section details how the proposed framework addresses the formulated research questions. 5.4.1 RQ1. How can we automatically identify the set of configurations that satisfy the architectural constraints characteristic of quantum-classical service-based systems? The proposed system enables the identification of the set of configurations that satisfy the architectural constraints characteristic of quantum-classical service-based systems. To achieve this, the system provides an analytical method that delimits the decision boundaries between different deployment types, depending on the established set of preferences. This is accomplished through the generation of a heatmap, which visualizes the set of constraints for which a valid solution (either classical or quantum) exists, as well J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:24

Á.M. Aparicio-Morales et al.

as identifying the design space where the generated configurations fail to meet the requirements. Furthermore, the analysis method ensures compliance with SLA criteria even before considering the utility of the candidate solutions. 5.4.2 RQ2. How can we analyze the trade-offs among relevant non-functional system properties (e.g., cost, performance, reliability) in quantum- classical service-based systems across the architectural design space and under prescribed levels of uncertainty? Through the established analysis process, it is possible to examine the design trade-off space for a given hybrid application. In this analysis, a utility calculation is performed for each generated solution across multiple defined scenarios. Consequently, it is possible to identify a configuration that maximizes utility by balancing conflicting non-functional properties, including critical factors such as uncertainty and economic cost. Furthermore, it is noteworthy that this method integrates a specific characteristic of hybrid systems, such as the number of erroneous shots (quantumerror). This establishes the groundwork for integrating additional dimensions specific to quantum systems, such as queueing delays or circuit decoherence levels, among others. In summary, this procedure enables the exploration of the architectural design space by revealing the decision boundaries for the selection of the optimal configuration, depending on the software architect’s Quality of Service requirements. 6

Threats to validity

In this section, the main threats to validity are discussed in order to ensure that the previously presented results are as reliable as possible through their identification and analysis. The structure follows the Internal, External, Construct and Conclusion subsections. 6.1

Internal Validity

One of the internal threats faced has been obtaining information about the reliability of digital computing machines from the selected provider, Amazon Web Services (AWS) 6 . This provider promises 99.5% availability for its machines in its Service Level Agreement (SLA) 7 . However, some studies, such as the work by Zhenyu Wen et al. [51] and Peter Garraghan et al. [21], have shown that this availability percentage is not exactly accurate, as availability can decrease by 2.46%, dropping to 97.54%. Therefore, based on the information provided in these works and the absence of this type of information from service providers, it was decided to use a range of availability values from 97.54% (the minimum availability percentage) to 99.5% (the value promised in the SLA Contract). The assignment of availability values was done using a random distribution to assign a different probability to each of the digital computing machines used in this study. It is acknowledged that these values are arbitrary. However, the main objective of this article is to provide validity for the use of these techniques in generating deployment configurations for hybrid applications. On the other hand, the need to manage computational complexity arises. Given the variability of computing machines and the number of services, the number of configurations to be generated has been intentionally limited to reduce the combinatorial explosion. This decision, although it reduces the exhaustiveness of the work, was necessary to address the study. This is evidenced when observing the times and number of configurations generated in both use cases (Table 4), even though the classical and quantum machines were deliberately limited. Additionally, a notable limitation in the simulation of the quantum environment is presented. In this study, the real operational conditions of QPUs have not been implemented. Specifically, this paper does not consider queue times, which are, in some cases, too long due to high demand and 6 https://aws.amazon.com/ 7 https://aws.amazon.com/compute/sla/

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:25

limited availability of quantum resources. In the same way, the restricted availability windows of the quantum machines have not been considered yet. These factors significantly influence the deployment performance and will be integrated into the future evolution of the proposed system. 6.2

External Validity

Regarding external validity, several threats arise from the current state of quantum hardware and its providers. Although AWS offers access to quantum computing machines, the metrics provided are not suitable for studying the performance of hybrid configurations. A significant metric for this is the CLOPS attribute, explained in Section3. For this reason, International Business Machines (IBM) 8 was used as the provider for the QPUs. However, since the cost of IBM machines is the same for each computer, in order to achieve greater richness in the trade-offs spaces, the quantum computer provider IQM 9 was also considered. IQM machines include the CLOPS metric, as well as a payment quota dimensionality similar (0.30$/s 10 ) to that of IBM (96$/minute 11 ). This lack of standardisation in hardware metrics between different QPU providers poses a challenge, as quantum software development tools must be adapted to each provider’s specific metrics rather than relying on a universal abstraction layer. Furthermore, in this work, only gate-based quantum computers have been considered. There are several reasons for this decision. At first, they are the most widely used quantum computers, as well as universal computers [26], meaning they can execute any algorithm. Secondly, this is an incipient research study, so it was decided to limit the scope to gate-based quantum computers. Including all types of architectures would complicate the problem’s definition and proper delimitation in this initial phase. 6.3

Construct Validity

In this section, a threat to the study’s validity linked to the proposed architectural style is identified. Given the incipient nature of the hybrid (classical-quantum) application architecture concept, there is a risk that the constraints defined for the service or deployment do not fully reflect optimal operational conditions. This design limitation is also present in the execution time assigned to tasks. As this is an initial study, the quantum algorithm being simulated has not been addressed in detail. Consequently, the execution time defined in the specification is not based on any specific algorithm or even on the execution times of similar algorithms. This simplification was necessary to scope and address the problem in this initial phase, but its modification will be required for validation with real use cases. 6.4

Conclusion Validity

Potential threats to conclusion validity arise from the fact that quantum computing is an incipient field. The observed trade-offs, while sufficient for validating the technique, may change as quantum technologies reach a higher degree of maturity. Likewise, these initial findings could be altered when real-world hybrid (quantum-classical) use cases are introduced. 7

Related Works

Related approaches can be categorized into: (i) Formalization and quantitative analysis/optimization of architectures, (ii) architecture of quantum computing systems, and (iii) placement/deployment of complex software systems. 8 https://www.ibm.com/ 9 https://meetiqm.com/ 10 https://meetiqm.com/products/iqm-resonance/ 11 https://www.ibm.com/quantum/products

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:26

Á.M. Aparicio-Morales et al.

Formalization and quantitative analysis/optimization of architectures. There is extensive related work on model-based performance prediction [7] and optimization of quantitative aspects of architectures [23] that typically use mechanisms like stochastic search and/or Pareto analysis [1, 8, 10, 11, 16, 32, 34]. PerOpteryx [32] takes as input an architectural model described using the Palladio component model and tries to automatically improve it by searching for pareto-optimal solutions employing a genetic algorithm. ArcheOpterix [1] uses an evolutionary algorithm for optimizing the architecture of embedded systems specified in AADL [17]. DeepCompass [10] is a framework that analyzes different architectural alternatives along the dimensions of performance and cost to find pareto-optimal solutions. While these approaches can optimize quantitative aspects of designs they do not support synthesis of configurations. Other approaches [6, 15] combine structural synthesis with simulation and dynamic analysis to provide estimates of quantitative properties of design variants. TradeMaker [6] synthesizes design spaces for relational database mappings, in which individual designs are subject to static and dynamic analysis to extract performance metrics. Dwivedi et al. [15] propose using architectural models coupled with automated design space generation for making fidelity and timeliness tradeoffs. These approaches share with ours the idea of synthesizing a solution space from a set of constraints and analyzing individual solutions independently. However, they are not equipped to provide quantitative guarantees under uncertainty, which rely on checking sophisticated properties (typically encoded as temporal logic formulas) via numerical methods and exhaustive state space exploration techniques. The class of technique we employ to support our approach [12], which combines the capabilities of quantitative verification with configuration synthesis, has been applied to the analysis of architectural design trade-off spaces in contexts such as security countermeasure selection [48], as well as pub-sub and service-based systems [13]. However, such proposals do not consider the idiosyncrasy of hybrid quantum-classical systems, including aspects of the problem related to machine-algorithm placement, which are explicitly addressed in our proposed solution and captured in our formalization of hybrid quantum-classical architectural style. Quantum Service-Oriented Architecture. In terms of the Quantum Service-Oriented Architecture (QSOA), research papers are beginning to emerge that propose Service-Oriented Computing as a way of integrating quantum computing into current software solutions. On the one hand, we highlight notable works that address issues of adapting tools and processes for the development of hybrid services. Among these, notable works include Alvarado et al.[2], which presents a guide for converting quantum circuits into web services, and Nguyen et al.[37], which introduces the concept of quantum-function-as-a-service, where a serverless model is used to execute quantum circuits. Another line of research in quantum services focuses on their deployment. Noteworthy here is the work of Karoline Wild et al.[52], which introduces TOSCAQ a model featuring two deployment styles based on the Topology and Orchestration Specification for Cloud Applications (TOSCA) standard to automate the deployment and orchestration of quantum applications. Additionally, Alvarez et al.[43] propose a strategy for the creation and continuous deployment of quantum services using an OpenAPI extension. On the other hand, there are also works that address the modelling challenges of quantum or hybrid software. In this context, the work of Carlos et al.[40] introduces Q-UML, an extension to classical UML, designed for the structural and behavioural representation of quantum search algorithms. Similarly, Pérez-Castillo and Piattini[39] explore how UML can be adapted to facilitate the co-design of classical-quantum systems, enabling the seamless integration of quantum functionalities within traditional software architectures.

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:27

Beyond UML-based approaches, constraints and architectural modelling languages play a crucial role in defining quantum software architectures. Medvidovic et al.[33] investigate how software architectures can be represented within UML, providing insights into the application of architectural constraints in quantum systems. Placement/Deployment of complex software systems. The deployment of complex software systems is a type of problem that has already been addressed in classical computing, with numerous studies examining it from various perspectives. Among these studies, we can highlight the work of Herrera et al. [25], which provides recommendations based on the composition of service applications and user requirements; the study by Yang Hu et al. [27], which seeks to optimize the deployment of microservice-based applications in cloud environments by minimizing inter-component traffic; and the work of Selimi et al. [45], which aims to leverage network state information to support service placement decisions. Other studies focus on the economic cost aspect of this deployment. This is the case in Olivier Belli’s work [9], where they implement a cost-optimization tool through a resource consumption model (RCM), enabling users to automatically compare the prices of different cloud infrastructure providers for their applications. Another example is the study by Ang Li et al. [30], which proposes an evaluation tool that, through controlled testing across different providers, estimates and compares the performance and costs of each, helping users select the most suitable provider. Furthermore, some studies adopt a metaheuristic approach. In this vein, the work by Hemant Kumar Apat et al. [5] is noteworthy, as it proposes a hybrid metaheuristic algorithm for IoT service placement based on multiple objectives, optimizing parameters such as makespan, cost, and energy consumption. There is also the study by Poria Pirozman et al. [41], which proposes using a genetic algorithm and energy-aware scheduling heuristic (GAECS) to address the multi-objective task scheduling problem in cloud computing, aiming to reduce both makespan and energy consumption. In the Quantum Computing study area, works addressing the challenge of selecting the most suitable quantum machine for a specific quantum circuit are starting to appear. It is the case of NISQ Analizer [44] where a suggestion of the optimal implementation of an algorithm and the appropriate quantum computer for certain input data is made or the work of Nils Quetschlich et al. [42] that propose MQT Predictor, a methodology for the automatic choice of a quantum computer for an application as well as the best compiler for the selected machine. As can be observed, numerous studies, like this one, seek to address the placement problem by applying different techniques with diverse final objectives. However, these approaches do not consider the application of quantum computing or its characteristics to achieve an optimal deployment of hybrid (quantum-classical) applications. 8

Conclusion and Future Work

As NISQ computer companies rapidly advance in developing fault-tolerant quantum computers, efforts must begin to emerge in the field of quantum software engineering in order to bridge the gap between experimental devices and practical applications. Addressing this challenge, this work aims to pave the way for integrating quantum components into Service-Oriented Architecture. For this purpose, a trade-off decision tool for hybrid (quantum-classical) applications is presented. The evaluation of the proposed framework has been done by analysing the Hybrid Search Application and the Weather Hybrid Forecast System examples. Within this evaluation, clear answers to the formulated research questions have been provided. Regarding the automatic identification of valid configurations (RQ1), results demonstrate that the proposed procedures enable the identification of diverse regions within the design trade-off space. By utilizing the decision region map, it is possible to provide software architects with a clear visualization of the best configuration, depending on J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:28

Á.M. Aparicio-Morales et al.

the established constraints for execution time and quantum error. On the other hand, concerning the trade-off analysis under uncertainty (RQ2), results reveal that the optimal configuration is inherently context-dependent. This characteristic renders the proposed framework a dynamic decision-making tool that prioritizes classical solutions when economic constraints are dominant, while favoring quantum configurations in high-performance scenarios where execution time is critical. Consequently, this work presents a context-aware framework that enables the identification of optimal deployments for a given hybrid application through the use of a utility function. The novelty of this approach lies in the integration of quantum components as a valid deployment alternative to existing classical services, the explicit consideration of hardware specifications for both quantum and classical machines, the generation of structurally correct deployment configurations, and the inherent dependency of service quality attributes on the specific hardware-service mapping thereby providing a mechanism to manage this complexity of future hybrid systems. In future work, several validity threats will be addressed to develop a more complete and sophisticated prototype. For instance, it is planning to simulate the queuing behavior of quantum computers and incorporate software quality metrics to account for the stochastic behavior of the service applications. In the long term, it is necessary to develop this methodology to support the deployment of hybrid applications across the entire spectrum of computing (Cloud-Fog-Edge). Additionally, the creation of a fully functional proof of concept for integration into a practical deployment tool that will enable optimal deployment of a hybrid (quantum-classical) application has started to be developed. Currently, only cloud machine providers are considered, but the plan is to extend this to analyze applications deployed across the computing continuum, which will introduce new challenges and further quality of service metrics to evaluate. References [1] A. Aleti, S. Bjornander, L. Grunske, and I. Meedeniya. 2009. ArcheOpterix: An extendable tool for architecture optimization of AADL models. In Model-Based Methodologies for Pervasive and Embedded Software, 2009. MOMPES ’09. ICSE Workshop on. IEEE, Vancouver, Canada, 61–71. doi:10.1109/MOMPES.2009.5069138 [2] Jaime Alvarado-Valiente, Javier Romero-Álvarez, Jose Garcia-Alonso, and Juan M Murillo. 2022. A guide for quantum web services deployment. In International Conference on Web Engineering. Springer, Bari, Italy, 493–496. doi:10.1007/9783-031-09917-5_42 [3] Álvaro M. Aparicio-Morales, Majid Haghparast, Niko Mäkitalo, José García-Alonso, Javier Berrocal, Vlad Stirbu, Tommi Mikkonen, and Juan Manuel Murillo. 2024. Liquifying Quantum-Classical Software-Intensive System of Systems. In IEEE International Conference on Software Analysis, Evolution and Reengineering, SANER 2024 - March 12, 2024. IEEE, Rovaniemi, Finland, 159–166. doi:10.1109/SANER-C62648.2024.00028 [4] Álvaro M. Aparicio-Morales, Juan Luis Herrera, Enrique Moguel, Javier Berrocal, Jose Garcia-Alonso, and Juan M. Murillo. 2023. Minimizing Deployment Cost of Hybrid Applications. In 2023 IEEE International Conference on Quantum Computing and Engineering (QCE), Vol. 02. IEEE, Bellevue, WA, USA, 191–194. doi:10.1109/QCE57702.2023.10209 [5] Hemant Kumar Apat, Bibhudutta Sahoo, Veena Goswami, and Rabindra K. Barik. 2024. A hybrid meta-heuristic algorithm for multi-objective IoT service placement in fog computing environments. Decision Analytics Journal 10 (2024), 100379. doi:10.1016/j.dajour.2023.100379 [6] Hamid Bagheri, Chong Tang, and Kevin J. Sullivan. 2014. TradeMaker: automated dynamic analysis of synthesized tradespaces. In 36th Int. Conf. on Software Engineering. ACM, Hyderabad, India, 106–116. doi:10.1145/2568225.2568291 [7] Simonetta Balsamo, Antinisca Di Marco, Paola Inverardi, and Marta Simeoni. 2004. Model-Based Performance Prediction in Software Development: A Survey. IEEE Trans. Software Eng. 30, 5 (2004), 295–310. doi:10.1109/TSE.2004.9 [8] Steffen Becker, Heiko Koziolek, and Ralf H. Reussner. 2009. The Palladio component model for model-driven performance prediction. Journal of Systems and Software 82, 1 (2009), 3–22. doi:10.1016/j.jss.2008.03.066 [9] Olivier Belli, Charles Loomis, and Nabil Abdennadher. 2016. Towards a Cost-Optimized Cloud Application Placement Tool. In 2016 IEEE International Conference on Cloud Computing Technology and Science (CloudCom). IEEE, Luxembourg, Luxembourg, 43–50. doi:10.1109/CloudCom.2016.0022 [10] Egor Bondarev, Michel R. V. Chaudron, and Erwin A. de Kock. 2007. Exploring Performance Trade-offs of a JPEG Decoder Using the Deepcompass Framework. In 6th WS on Software and Performance (WOSP). ACM, New York, NY,

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:29

USA, 153–163. doi:10.1145/1216993.1217020 [11] Franz Brosch, Heiko Koziolek, Barbora Buhnova, and Ralf H. Reussner. 2012. Architecture-Based Reliability Prediction with the Palladio Component Model. IEEE Trans. Software Eng. 38, 6 (2012), 1319–1339. doi:10.1109/TSE.2011.94 [12] Javier Cámara. 2020. HaiQ: Synthesis of Software Design Spaces with Structural and Probabilistic Guarantees. In FormaliSE@ICSE 2020: 8th International Conference on Formal Methods in Software Engineering, July 13, 2020, Kyungmin Bae, Domenico Bianculli, Stefania Gnesi, and Nico Plat (Eds.). ACM, Seoul, Republic of Korea, 22–33. doi:10.1145/3372020.3391562 [13] Javier Cámara, David Garlan, and Bradley R. Schmerl. 2019. Synthesizing tradeoff spaces with quantitative guarantees for families of software systems. J. Syst. Softw. 152 (2019), 33–49. doi:10.1016/j.jss.2019.02.055 [14] Yongcheng Ding, Xi Chen, Lucas Lamata, Enrique Solano, and Mikel Sanz. 2021. Implementation of a Hybrid ClassicalQuantum Annealing Algorithm for Logistic Network Design. SN Comput. Sci. 2, 1 (2021), 68. doi:10.1007/S42979-02100466-2 [15] Vishal Dwivedi, David Garlan, Jürgen Pfeffer, and Bradley Schmerl. 2014. Model-Based Assistance for Making Time/Fidelity Trade-Offs in Component Compositions. In 11th International Conference on Information Technology: New Generations, ITNG 2014. IEEE CS, Las Vegas, NV, USA, 235–240. doi:10.13140/2.1.2495.6164 [16] Naeem Esfahani, Sam Malek, and Kaveh Razavi. 2013. GuideArch: guiding the exploration of architectural solution space under uncertainty. In 35th International Conference on Software Engineering, ICSE. IEEE CS, San Francisco, CA, USA, 43–52. doi:10.1109/ICSE.2013.6606550 [17] Peter H Feiler, Bruce Lewis, Steve Vestal, and Ed Colbert. 2004. An overview of the SAE architecture analysis & design language (AADL) standard: A basis for model-based architecture-driven embedded systems engineering. In IFIP World Computer Congress, TC 2. Springer, Springer, Toulouse, France, 3–15. doi:10.1007/0-387-24590-1_1 [18] Frank Gaitan. 2020. Finding flows of a Navier–Stokes fluid through quantum computing. npj Quantum Information 2020 6:1 6 (7 2020), 1–6. Issue 1. doi:10.1038/s41534-020-00291-0 [19] José García-Alonso, Javier Rojo, David Valencia, Enrique Moguel, Javier Berrocal, and Juan Manuel Murillo. 2022. Quantum Software as a Service Through a Quantum API Gateway. IEEE Internet Comput. 26, 1 (2022), 34–41. doi:10. 1109/MIC.2021.3132688 [20] David Garlan, Robert T. Monroe, and David Wile. 1997. Acme: an architecture description interchange language. In Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative Research, November 10-13, 1997. IBM Press, Toronto, Ontario, Canada, 7. doi:10.1145/782010.782017 [21] Peter Garraghan, Paul Townend, and Jie Xu. 2014. An Empirical Failure-Analysis of a Large-Scale Cloud Computing Environment. In 2014 IEEE 15th International Symposium on High-Assurance Systems Engineering. IEEE, Miami Beach, FL, USA, 113–120. doi:10.1109/HASE.2014.24 [22] Lov K Grover. 1996. A fast quantum mechanical algorithm for database search. In Proceedings of the twenty-eighth annual ACM symposium on Theory of computing. Association for Computing Machinery, Philadelphia, Pennsylvania, USA, 212–219. doi:10.1145/237814.237866 [23] Lars Grunske and Aldeida Aleti. 2013. Quality optimisation of software architectures and design specifications. Journal of Systems and Software 86, 10 (2013), 2465–2466. doi:10.1016/j.jss.2013.06.001 [24] Hans Hansson and Bengt Jonsson. 1994. A logic for reasoning about time and reliability. Formal Aspects of Computing 6, 5 (1994), 512–535. doi:10.1007/BF01211866 [25] Juan Luis Herrera, Jaime Galan-Jimenez, Jose Garcia-Alonso, Javier Berrocal, and Juan Manuel Murillo. 2023. Joint Optimization of Response Time and Deployment Cost in Next-Gen IoT Applications. IEEE Internet of Things Journal 10 (3 2023), 3968–3981. Issue 5. doi:10.1109/JIOT.2022.3165646 [26] Jack D. Hidary. 2021. Quantum Computing: An Applied Approach, Second Edition. Springer, Cham, Switzerland. doi:10.1007/978-3-030-83274-2 [27] Yang Hu, Cees de Laat, and Zhiming Zhao. 2019. Optimizing Service Placement for Microservice Architecture in Clouds. Applied Sciences 2019, Vol. 9, Page 4663 9 (11 2019), 4663. Issue 21. doi:10.3390/APP9214663 Importante. [28] Daniel Jackson. 2019. Alloy: a language and tool for exploring software designs. Commun. ACM 62, 9 (2019), 66–76. doi:10.1145/3338843 [29] Marta Z. Kwiatkowska, Gethin Norman, and David Parker. 2007. Stochastic Model Checking. In Formal Methods for Performance Evaluation, 7th International School on Formal Methods for the Design of Computer, Communication, and Software Systems, SFM 2007, Bertinoro, Italy, May 28-June 2, 2007, Advanced Lectures (Lecture Notes in Computer Science, Vol. 4486), Marco Bernardo and Jane Hillston (Eds.). Springer, Bertinoro, Italy, 220–270. doi:10.1007/978-3-540-72522-0_6 [30] Ang Li, Xiaowei Yang, Srikanth Kandula, and Ming Zhang. 2010. CloudCmp: comparing public cloud providers. In Proceedings of the 10th ACM SIGCOMM Conference on Internet Measurement (Melbourne, Australia) (IMC ’10). Association for Computing Machinery, New York, NY, USA, 1–14. doi:10.1145/1879141.1879143 [31] Sara Mahdavi-Hezavehi, Matthias Galster, and Paris Avgeriou. 2013. Variability in quality attributes of servicebased software systems: A systematic literature review. Information and Software Technology 55, 2 (2013), 320–343.

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

111:30

Á.M. Aparicio-Morales et al.

doi:10.1016/j.infsof.2012.08.010 [32] Anne Martens, Heiko Koziolek, Steffen Becker, and Ralf Reussner. 2010. Automatically Improve Software Architecture Models for Performance, Reliability, and Cost Using Evolutionary Algorithms. In Int. Conf. on Performance Engineering (WOSP/SIPEW). ACM, San Jose, California, USA, 105–116. doi:10.1145/1712605.1712624 [33] Nenad Medvidovic, David S. Rosenblum, David F. Redmiles, and Jason E. Robbins. 2002. Modeling software architectures in the Unified Modeling Language. ACM Trans. Softw. Eng. Methodol. 11, 1 (2002), 2–57. doi:10.1145/504087.504088 [34] Indika Meedeniya, Irene Moser, Aldeida Aleti, and Lars Grunske. 2011. Architecture-based reliability evaluation under uncertainty. In 7th International Conference on the Quality of Software Architectures, QoSA 2011 and 2nd International Symposium on Architecting Critical Systems, ISARCS. ACM, Colorado, USA, 85–94. doi:10.1145/2000259.2000275 [35] Juan Manuel Murillo, Jose Garcia-Alonso, Enrique Moguel, Johanna Barzen, Frank Leymann, Shaukat Ali, Tao Yue, Paolo Arcaini, Ricardo Pérez-Castillo, Ignacio García-Rodríguez de Guzmán, Mario Piattini, Antonio Ruiz-Cortés, Antonio Brogi, Jianjun Zhao, Andriy Miranskyy, and Manuel Wimmer. 2025. Quantum Software Engineering: Roadmap and Challenges Ahead. ACM Trans. Softw. Eng. Methodol. 34, 5, Article 154 (May 2025), 48 pages. doi:10.1145/3712002 [36] Hoa T. Nguyen, Prabhakar Krishnan, Dilip Krishnaswamy, Muhammad Usman, and Rajkumar Buyya. 2024. Quantum Cloud Computing: A Review, Open Problems, and Future Directions. CoRR abs/2404.11420 (2024). doi:10.48550/ARXIV. 2404.11420 [37] Hoa T Nguyen, Muhammad Usman, and Rajkumar Buyya. 2024. Qfaas: A serverless function-as-a-service framework for quantum computing. Future Generation Computer Systems 154 (2024), 281–300. doi:10.1016/j.future.2024.01.018 [38] Michael A. Nielsen and Isaac L. Chuang. 2016. Quantum Computation and Quantum Information (10th Anniversary edition). Cambridge University Press, Cambridge. doi:10.1017/CBO9780511976667 [39] Ricardo Pérez-Castillo and Mario Piattini. 2022. Design of classical-quantum systems with UML. Computing 104, 11 (2022), 2375–2403. doi:10.1007/S00607-022-01091-4 [40] Carlos A. Pérez-Delgado. 2022. A Quantum Software Modeling Language. In Quantum Software Engineering, Manuel A. Serrano, Ricardo Pérez-Castillo, and Mario Piattini (Eds.). Springer International Publishing, Cham, 103–119. doi:10. 1007/978-3-031-05324-5_6 [41] Poria Pirozmand, Ali Asghar Rahmani Hosseinabadi, Maedeh Farrokhzad, Mehdi Sadeghilalimi, Seyedsaeid Mirkamali, and Adam Slowik. 2021. Multi-objective hybrid genetic algorithm for task scheduling problem in cloud computing. Neural Computing and Applications 33 (10 2021). doi:10.1007/s00521-021-06002-w [42] Nils Quetschlich, Lukas Burgholzer, and Robert Wille. 2025. MQT Predictor: Automatic Device Selection with DeviceSpecific Circuit Compilation for Quantum Computing. ACM Transactions on Quantum Computing 6, 1, Article 10 (Jan. 2025), 26 pages. doi:10.1145/3673241 [43] Javier Romero-Álvarez, Jaime Alvarado-Valiente, Enrique Moguel, Jose Garcia-Alonso, and Juan M Murillo. 2024. Enabling continuous deployment techniques for quantum services. Software: Practice and Experience 54, 8 (2024), 1491–1515. doi:10.1002/spe.3326 [44] Marie Salm, Johanna Barzen, Uwe Breitenbücher, Frank Leymann, Benjamin Weder, and Karoline Wild. 2020. The NISQ Analyzer: Automating the Selection of Quantum Computers for Quantum Algorithms. In Service-Oriented Computing 14th Symposium and Summer School on Service-Oriented Computing, SummerSOC 2020, Crete, Greece, September 13-19, 2020 (Communications in Computer and Information Science, Vol. 1310), Schahram Dustdar (Ed.). Springer, Crete, Greece, 66–85. doi:10.1007/978-3-030-64846-6_5 [45] Mennan Selimi, Llorenç Cerdà-Alabern, Marc Sánchez-Artigas, Felix Freitag, and Luís Veiga. 2017. Practical Service Placement Approach for Microservices Architecture. In Proceedings of the 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid ’17). IEEE Press, Madrid, Spain, 401–410. doi:10.1109/CCGRID.2017.28 [46] Mary Shaw and David Garlan. 1996. Software architecture - perspectives on an emerging discipline. Prentice Hall, New Jersey, USA. [47] Peter W Shor. 1999. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM review 41, 2 (1999), 303–332. doi:10.48550/arXiv.quant-ph/9508027 [48] Charilaos Skandylas, Narges Khakpour, and Javier Cámara. 2022. Security Countermeasure Selection for ComponentBased Software-Intensive Systems. In 2022 IEEE 22nd International Conference on Software Quality, Reliability and Security (QRS). IEEE, IEEE, Guangzhou, China, 63–72. doi:10.1109/QRS57517.2022.00017 [49] Tobias Stollenwerk, Bryan O’Gorman, Davide Venturelli, Salvatore Mandrà, Olga Rodionova, Hokkwan Ng, Banavar Sridhar, Eleanor Gilbert Rieffel, and Rupak Biswas. 2020. Quantum Annealing Applied to De-Conflicting Optimal Trajectories for Air Traffic Management. IEEE Trans. Intell. Transp. Syst. 21, 1 (2020), 285–297. doi:10.1109/TITS.2019. 2891235 [50] Jos Warmer and Anneke Kleppe. 2003. The Object Constraint Language: Getting Your Models Ready for MDA. AddisonWesley, Boston, MA, USA. [51] Zhenyu Wen, Jacek Cała, Paul Watson, and Alexander Romanovsky. 2017. Cost Effective, Reliable and Secure Workflow Deployment over Federated Clouds. IEEE Transactions on Services Computing 10, 6 (2017), 929–941. doi:10.1109/TSC.

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.

Architecting Hybrid Quantum-Classical Software Systems

111:31

2016.2543719 [52] Karoline Wild, Uwe Breitenbücher, Lukas Harzenetter, Frank Leymann, Daniel Vietz, and Michael Zimmermann. 2020. TOSCA4QC: Two Modeling Styles for TOSCA to Automate the Deployment and Orchestration of Quantum Applications. In 2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC). IEEE, Eindhoven, The Netherlands, 125–134. doi:10.1109/EDOC49727.2020.00024

Received 27 March 2026; revised DD Month YYYY; accepted DD Month YYYY

J. ACM, Vol. 37, No. 4, Article 111. Publication date: August 2026.