1 Introduction↩︎

Computing infrastructures are deeply intertwined with organizational practices, shaping how work is performed and how flexibility emerges in research and industrial settings. In advanced computing domains, such as quantum computing (QC) and high-performance computing (HPC), this relationship becomes more pronounced due to the complexity, scarcity, and heterogeneity of resources. QC, in particular, represents a disruptive shift, not only in computational capabilities but also in how users interact with infrastructure, as access is typically remote, mediated, and evolving alongside the technology itself. As a result, integrating quantum and classical resources introduces new challenges in maintaining usable and adaptable computing environments.

In practice, computing environments are not seamless systems but require continuous adaptation by users to compensate for misalignments between infrastructure and work requirements. In the context of quantum computing, this challenge is amplified by technological immaturity and fragmentation across the software stack. Users face a growing number of choices in tools, frameworks, and execution environments, which creates combinatorial complexity and prevents the formation of stable development routines. This leads to increased mental and operational burden, where users must manage heterogeneous resources, bridge incompatible systems, and absorb the hidden costs of integration. The result is a tension between the need for experimentation in an emerging field and the constraints imposed by limited resources and evolving infrastructure.

To address this gap, we propose a framework for analyzing quantum software environments through a socio-technical lens. The framework introduces the concept of gravity wells to capture how technologies and practices exert structural pull on surrounding choices, and a set of socio-technical desiderata to evaluate whether this pull enables or constrains experimentation and evolution. Developed using Design Science Research (DSR), the framework is demonstrated through three representative execution scenarios spanning cloud-native and HPC-oriented approaches. Rather than prescribing a single solution, the contribution provides a structured method for identifying sources of friction, reasoning about architectural trade-offs, and guiding the design of more evolvable and practitioner-friendly hybrid quantum–classical environments.

The paper is structured as follows. Section 2 provides the background. Section 3 describes the methodology and the objectives. Section 4 describes the design of the framework. Section 5 presents the use of the framework in representative scenarios, followed by Section 6 in which the framework is evaluated. The paper concludes in Section 7.

2 Background and motivation↩︎

Existing research has demonstrated progress toward integrating heterogeneous computing resources [1]–[4]. The proposals are often limited to experimental setups or specific institutions, and their applicability in real-world scientific workflows remains constrained. In hybrid QC-HPC execution developer experience continues to be fragmented and vendor-dependent [1], [2], [5]. We have noted a clear research gap: the need for practical, developer-oriented orchestration solutions that enable interoperability across heterogeneous infrastructures while reducing workflow complexity. In essence, structural tension is evident between QC, HPC, cloud, and scientific demands.

2.1 Quantum Software Stack↩︎

The quantum software stack refers to the organized layering of components built on top of hardware (Fig. 1). It clarifies that when practitioners speak of fragmentation or interoperability, they are often diagnosing misalignment between specific layers rather than the stack as a whole. [7] and [6] propose structures for the stack, showing that the most consistent gaps appear precisely at the interfaces between layers.

In the infrastructure level, there exists a growing range of alternatives in terms of proximity of QC to HPC systems. Effectively orchestrating those remote computational resources can significantly enhance quantum software development [8], [9]. Middleware solutions can simplify interactions, decouple quantum logic from underlying systems, and dynamically allocate workloads across QC and HPC resources [6], [10]. Efforts such as Quantum Device Interface Layer (QDIL)¹ and Quantum Device Management Interface (QDMI) [11] seek to maintain homogeneous access across devices while recognizing the need to operate within the specifics of each modality and potentially their integration.

Above the infrastructure layer, quantum software development kits (QSDKs) operationalize access to quantum hardware and hybrid resources [6], [12]–[15]. Despite the plethora of available SDKs, many languages and frameworks remain research-oriented or vendor-specific, full interoperability across platforms being limited [6], [15], [16] and noise sensitivity constraining these tools in the NISQ era [17], [18]. Within the layered perspective adopted in this background section, QSDKs function as the critical mediation layer. Their maturity directly influences portability, interoperability, and developer experience across hybrid QC-HPC environments.

At the top of the stack, applications materialize quantum and hybrid capabilities into domain-specific workflows. Access to quantum applications is predominantly mediated through cloud-based service models that abstract away hardware ownership and management, such as the as-a-service framework [5], [19]–[21]. In scientific computing contexts, applications frequently span heterogeneous infrastructures, combining cloud-native orchestration with remote QC resources and HPC backends [4], [22], with focus on workflow continuity, scheduling efficiency, and adaptive resource allocation [2], [23]. From a layered perspective, the application-level limitations often reflect unresolved architectural tensions in the underlying QC-HPC integration stack.

2.2 What Has Been Attempted↩︎

Existing research demonstrates substantial progress toward integrating heterogeneous computing resources [1]–[4]. Hardware-agnostic approaches [1] and shared environments with interoperable tooling [2] have been gaining attention. [1], [24], [25] and [14] introduce comprehensive frameworks for QC-HPC integration. Critically, [24] positions Kubernetes² and Slurm³ as complementary rather than competing, meaning they can coexist in hybrid HPC deployments, whereas much prior discussion treats Kubernetes and Slurm as mutually exclusive.

Effective integration requires management at two levels: workflows and resources [1]. Composable tooling and bridging solutions advance interoperability but fall short of delivering end-to-end, vendor-neutral orchestration suitable for sustained scientific use [3], [4], [22], with scheduling remaining a problem [2], [23]. Some offered solutions include Quantum Algorithms as a Service (QAaaS) [5], Qonductor [26], The Bridge Operator [27], NVQLink [28], serverless Quantum Function as a Service (QFaaS) [20], High-Performance Kubernetes (HPK) [3], and Dynamic Kubernetes [29]. Several solutions also address GPU sharing within Kubernetes environments, targeting deep learning and multi-tenant HPC workloads [30]–[32]. CloudVeneto uses InterLink⁴ to simplify deployment, resource management, and workload offloading [21]. InterLink allows Kubernetes to execute arbitrary heterogeneous remote resources [4], [22].

2.3 Portability and Orchestration Problems↩︎

One of the emerging trends in HPC is the integration of QC [33], which provides broader access to computational resources that were previously highly specialized and restricted [19], [34]. In this landscape, cloud-native and serverless paradigms [34] as well as containerization technologies such as Docker⁵ and Kubernetes [35] are gaining attention. Actors in HPC seem to notice the benefits of containerization: for example, LUMI supercomputer has its own orchestration platform⁶. Despite these advances, orchestration in multi-cloud and hybrid QC-HPC environments remains underexplored [35], with existing workflows often forcing developers to manually bridge separate infrastructures [6], [10].

The orchestration challenge in classical computing has evolved to meet concrete needs in industry and academia across variety of environments, but the emerging trade-offs from specific demands arising from the translation of workflow specifications into actual workloads reflect market realities, often captured by a power-law like distribution in the adoption of specific technologies. Market data exhibits this: Market Growth Reports [36] describe Kubernetes as the dominant container platform. QC orchestration is in earlier stage. QPU orchestration decisions tend to be tied to specific institutional efforts rather than emerging from broad market selection. This contrast between the two domains is not merely descriptive — it underscores why direct translation of classical orchestration patterns to the quantum domain is insufficient, while also confirming that established classical tools like Kubernetes represent a sensible starting point.

Across the stack, quantum software engineering functions as the connective tissue. The field suffers from a structural complexity problem due to choices in the levels of the stack, creating a complex multi-to-multi mapping problem: no single solution can dominate across all resource pairings and workflow types, nor should it. The more productive framing is not which solution wins, but whether the ecosystem can support the full range of pairings that scientific and engineering practice demands. What is needed are tools and frameworks that embrace this heterogeneity, without forcing developers into narrow, vendor-defined corridors.

2.4 Socio-Technical Problems↩︎

Technology does not exist in a vacuum. Every tool, platform, or system we deploy enters an existing social context. This is the foundational insight of the socio-technical tradition: technological artifacts and social practices are constitutively entangled. As QC matures, it confronts the same challenge that has accompanied every major computational paradigm shift: how do we build environments where the right tools fit together into a whole genuinely greater than the sum of its parts? The following insights apply to QC environments, where the stack spans multiple heterogeneous layers and no single offering covers every level adequately. Choosing a QC environment is therefore not an act of selecting the best tool, but an act of alignment: matching available offerings to the given context.

Gasser’s [37] study of routine computer use demonstrates that even in highly successful computing environments, the fit between systems and the work they support is perpetually unstable. Star and Ruhleder [38] deepen this account by showing that such friction arises from incommensurable contextual levels: infrastructure is never a passive substrate but always a relation, becoming visible precisely in where it breaks down. Orlikowski continues this insight further, explaining that there is no social that is not also material, and no material that is not also social [39]. Friction is therefore not a residual problem to be eliminated by better engineering, but a persistent condition arising from the gap between systems as designed and work as performed. This tradition stands in deliberate contrast to adoption models such as TAM [40], [41], UTAUT [42], and UTAUT2 [43], which treat adoption as predictable from individual-level beliefs.

3 Motivation, Methodology and Objective↩︎

This paper follows the DSR methodology [44], [45]. The problem-centered approach allows us to notice that the quantum software environment is composed of interchangeable but poorly interoperable elements, creating combinatorial configuration complexity. Assembling the right elements and configuring the stack becomes a complex problem with many choices that require skills and expertise. As a result, users cannot form stable routines, while choices carry hidden irreversible costs. Additionally, we identify that the problems being solved with QC must be positioned in a socio-technical context, with a short-term objective to lower the configuration combinatorial complexity and a long-term goal to enable resilience and evolvability.

Therefore, during the Problem identification and motivation phase, we were able to distill the following research questions:

• RQ1: How can orchestration infrastructure be designed to reduce socio-technical friction and combinatorial configuration complexity in hybrid QC–HPC software environments?

• RQ2: What design criteria and quality attributes enable such orchestration frameworks to support flexibility, interoperability, and evolvability?

• RQ3: How to identify the dominant sources of friction in quantum software ecosystems and how do they impact developer workflows?

In the Objectives of the solution phase, the goal was to define a framework that supports practitioners in navigating the socio-technical challenges of quantum software environments, with particular focus on reducing combinatorial configuration complexity and associated frictions. The framework was developed during the Design and development phase, grounded in socio-technical theory and operationalized through the concepts of technological evaluation criteria for evaluating individual nodes, gravity wells and their properties for finding the problematic nodes, and socio-technical desiderata for evaluating the impact of the gravity wells. In the Demonstration phase, the framework was applied to three representative case scenarios to identify gravity wells and analyze their effects on workflow and environment design. The Evaluation phase consisted of a critical reflection on the framework’s explanatory and analytical capabilities in these scenarios. Finally, the Communication phase reports the results in this paper.

4 Design and Development↩︎

4.1 Criteria for technology evaluation↩︎

When solving quantum problems, practitioners must curate their own quantum computing environments. The result is not a simple selection problem but a deeply constrained compositional challenge: each choice at one layer carries implications for other layers. If the totality of available environments were represented as a graph, with nodes corresponding to tools and offerings, and edges representing the technical and organizational relationships between them, the evaluation criteria developed in this framework would serve as a lens for identifying where that graph breaks down or centralizes. The evaluation criteria were synthesized from three comprehensive works: [6], [15], [46]. Previous work in [47] about quantum software developer experience was used as a starting point. The criteria mapped to the levels is available in Table 1.

Given the amount of tools and solutions in this evolving field, interoperability between the offerings is essential. It is achieved through API portability, hybrid workflow support, workflow exportability, pluggable backends, clear differentiation of orchestration from vendor-specific dependencies, and agnosticism in different components [6], [46]. Vendor lock-in is repeatedly identified as a systemic problem that restricts portability, constrains interoperability, and limits architectural evolution [10], [15], [48], [49]. A compounding challenge arises from the fundamental asymmetry between QC and HPC systems: HPC infrastructure is designed for multi-user, low-latency operation, unlike QC [2]. Integration efforts have revealed particular difficulties around remote hardware control [1]. Many HPC environments impose additional access barriers, including vendor lock-in [50]. In cloud-native settings, GPU-sharing remains uncommon [30], [31], while scientific computing demand increasingly exceeds the capacity of current isolated infrastructures [22]. The development of quantum-aware frameworks for hybrid systems, alongside runtime management is widely regarded as a central objective for the field [51]. Cloud-HPC workflows that do not require users to connect directly to HPC systems remain uncommon in everyday practice [3], and existing HPC schedulers lack the flexibility characteristic of cloud-native tooling [52].

Vendor lock-in undermines the reproducibility that interoperability is intended to enable. In quantum computing, reproducibility can be supported through version control and open-source code [46], as well as the development of reusable quantum software components [6], [15]. Programmability, in turn, offers users meaningful control through integrated environments [15].

Alongside reproducibility, transparency constitutes a critical concern for the continued evolution of the field [6]. Transparency can be realized through workflow abstractions and debugging support, cost and resource visibility, and the deliberate exposure of conceptual stack layers to the user. Governance and management processes further enable transparent, auditable workflows [6]. Transparency renders workflows more legible, making it possible to switch backends, inspect the translation layers of the stack, and maintain continuity in the stack levels. Release stability and sustained maintenance activity are further prerequisites [15], [46]. Transparency encompasses visibility into HPC scheduler configuration, monitoring across heterogeneous resources, unified logging, and QPU backend configurations. It is also worth noting that some available solutions are oriented toward the fault-tolerant era of quantum computing, while others are not [15]. Reliability is also an important consideration when evaluating infrastructure choices: vendors differ in the error-correction mechanisms and reliability assurances they offer [6], as well as in their approaches to performance efficiency and resource utilization [6], [46].

Development processes assume particular significance. The emergence of new hybrid software life cycles [6], [15], the iterative development of hybrid software [15], and the management of quantum software development projects [6] are all active areas of concern. When managing multi-stage scientific workflows, users must orchestrate computation and data across diverse and heterogeneous resources [53], and employ disparate bridging tools that enable job transfer while keeping underlying resources differentiated [3], [29]. Difficulties with workflow execution and orchestration are commonly reported challenges for users [23].

A structural limitation of the current landscape is the absence of sufficiently mature tooling, with many existing tools remaining at the prototype stage [13], [49], [54]. Usability is closely coupled with tooling quality. Adequate documentation and illustrative examples [46], continuous updates [46], user-friendly interfaces [15] and clarity of error feedback all significantly affect practitioners’ capacity to work effectively with their chosen tools. QC demands substantial levels of domain-specific skills and expertise [5], [13], [49], [55], [56], and the shortage of technical expertise remains an obstacle in the field [55].

The deployment model has significant downstream implications for the rest of the environment. The implementation technology constrains which adjacent technologies can be meaningfully integrated. The use model determines the cost structure under which resources are accessed. Backend offerings define the set of providers a practitioner can realistically work with. Finally, for certain use cases, computing models, including distributed computing approaches or multi-tenant support, introduce further constraints and opportunities that must be considered in environment design.

4.2 Gravity Wells and Their Properties↩︎

The concept of a gravity well, as used in this framework, denotes a highly connected partition of the QC environment graph. It captures how certain technologies, practices, or structural conditions, once adopted, exert increasing pull on surrounding choices, shaping which paths through the stack remain practically available. This pull manifests along a spectrum: at one end it enables coherent ecosystem development and productive specialization; at the other it constrains the experimentation space that innovative work requires. This dynamic is reflected in the MAYA principle from design theory, which holds that effective artifacts balance typicality and novelty rather than collapsing into either extreme [57]. Understanding where a given environment sits along this spectrum – and why – is the purpose of the gravity well properties analysis that follows. From the technological evaluation criteria, we derive three properties of the gravity wells. These properties help to identify if a partition of a graph is indeed a gravity well. The connections can be seen in Fig. 2.

Workflow Specialization arises when teams optimize workflows for their immediate operational needs. This process causes knowledge and tooling choices to concentrate around the people who built or routinely use a given system. The spectrum of this property runs from deep workflow expertise and highly optimized local pipelines at one end, to fragmented development practices, elevated coordination overhead, and reduced transferability at the other. The degree to which this pull opens or closes the surrounding design space depends on the availability of shared orchestration standards and the portability of the chosen bridging solutions.

Infrastructure naturally solidifies as it matures, and tooling attracts users who, through familiarity and accumulated investment, come to depend on it irrespective of its current fit for purpose. The same dynamic applies to processes and methodologies. The spectrum of the Technology Entrenchment runs from stable, high-performance infrastructure at one end, to resistance to architectural evolution and accumulating technical debt at the other. Its effects range from productive stability to structural rigidity depending on the pace of change in the surrounding environment.

At the ecosystem level, certain platforms and toolchains exert gravitational pull that shapes which paths remain available. The spectrum of Ecosystem Convergence Pressure runs from rich, deeply integrated proprietary ecosystems with extensive tooling support at one end, to fragmented, lock-in-prone landscapes where portability and interoperability are structurally constrained at the other. The resulting dependencies range from enabling access to a coherent and well-resourced ecosystem to foreclosing the architectural flexibility that evolving problem contexts may demand.

The three gravity well properties are neither independent nor static. They interact across stack levels, and a practitioner will encounter them simultaneously in different gravity wells. Each property describes a kind of pull, and each pull has a spectrum of possible outcomes depending on the problem context. The purpose of identifying these properties is not to prescribe which ones to avoid, but to make their dynamics legible, so that the paths through the environment graph can be considered with an understanding of what forces are shaping them.

4.3 Socio-Technical Desiderata↩︎

To evaluate whether a given gravity well is productive or obstructive in a particular context, a normative reference point is needed: the socio-technical desiderata developed in this section. They are not prescriptive engineering requirements, but goal-oriented criteria derived from the intersection of the socio-technical tradition reviewed earlier and the technology readiness levels (TRLs) (Fig. 3) discussed below. Taken together, they articulate what a well-functioning, evolvable, and practitioner-enabling QC environment should strive toward. When a gravity well does not facilitate progress toward these desiderata, it can be characterized as non-beneficial in that context. This evaluation is context-dependent: the same well may be productive for a team operating at quantum organizational readiness level 3 and obstructive for one operating at level 7. The framework does not resolve that judgment on behalf of the practitioner; instead, it provides a conceptual vocabulary that enables them to make informed, deliberate decisions with a clear understanding of the trade-offs involved.

Quantum technologies qualify as emerging technologies due to their low technological maturity and nascent practical applications [58], with the stack remaining open to fundamental changes at all levels (Fig. 3). Mapping the quantum stack onto the [63] framework, most hardware and software tooling sits in the technical feasibility range, with maturity concentrated only around simulators and classical control infrastructure. This asymmetry means that orchestration solutions must accommodate fundamentally different readiness levels on each side of the QC-HPC integration. [60] implies that it is a structural constraint on adoption rather than a transitional inconvenience, making developer-oriented orchestration a prerequisite for commercial uptake. Most quantum algorithms of practical interest remain at the theorized-but-invalidated stage of [61] framework, creating a reinforcing cycle where gaps in application readiness constrain infrastructure investment. [62] sharpen this picture by separating quantum advantage – outperforming a classical counterpart in accuracy, power, or time [61] – from quantum economic advantage, arguing that commercially relevant speedups may arise before classical impossibility is demonstrated, implying that hybrid QC-HPC workflows can be economically justifiable well before fault-tolerant hardware arrives.

As quantum software stacks grow in complexity, monitoring and logging capabilities tend to be added reactively and inconsistently, accumulating blind spots that complicate debugging, reproducibility, and accountability. Operational and governance transparency addresses this tendency by articulating what practitioners must be able to observe and control within their environments. At the operational level, this includes visibility into scheduler configuration, resource allocation decisions, QPU backend parameters, and the translation layers. Unified logging across heterogeneous classical and quantum resources, and monitoring dashboards that expose the state of multi-stage workflows, are practical expressions of this desideratum. At the governance level, transparency requires clear deployment guarantees, reproducible environment configurations, and the ability for practitioners to meaningfully influence the tools and standards.

A major source of irreversibility in QC environment choices is the accumulation of human capital. When practitioners invest significant effort in learning something, that investment creates switching costs that go beyond the technical. The expertise itself becomes entangled with the tool, making transitions toward more suitable alternatives disproportionately costly. Knowledge and skill portability as a desideratum therefore encompasses both the transferability of conceptual understanding across platforms and the availability of documentation, shared vocabularies, and educational resources that reduce the degree to which expertise is tied to specific implementations. Open standards, common programming abstractions, and cross-platform frameworks all contribute to portability by ensuring that skills acquired in one context remain applicable in others.

Not all constraints are equal: some narrow the solution space temporarily, while others close off architectural paths in ways that are difficult or prohibitively costly to reverse. Avoiding irreversible choices and constraints concerns the identification and, where possible, the avoidance of the latter category. Irreversibility in QC environments arises from several sources. Compartmentalization is the bundling of functionality within proprietary or tightly coupled systems, and reduces the surface area for substitution. Specification occurs when parts of the system are expressed in vendor-specific terms that cannot be straightforwardly translated to alternative platforms. A further dimension concerns the transition from activity space to information space. In action space artifacts, the irreversibility of the underlying tool choices is effectively amplified because the manual labor of the choices is much larger than in information space.

The evolutionary trajectory of a technological field depends in part on its capacity to generate, evaluate, and selectively retain novel approaches. This requires that the environment preserves productive failure and allows experimentation for evolution. In QC, where the maturity landscape is uneven, the preservation of experimentation space is a central concern. Providing practitioners with interoperable, accessible, and composable solutions allows a form of natural selection to operate across the field: approaches that prove durable under real conditions are retained and developed. This requires that individual tool choices do not carry prohibitive exit costs, that abstraction layers remain penetrable when lower-level control is needed, and that the broader ecosystem does not converge prematurely on solutions whose long-term fitness has not yet been demonstrated.

4.4 The composed framework↩︎

The framework elements are illustrated in Fig. 4. At the center is the goal the user aims to solve using technologies drawn from a broader ecosystem, not limited to QC. Within this ecosystem, gravity wells appear as highly connected regions, that exhibit gravity well properties. The technologies within these regions are assessed using the evaluation criteria, while their socio-technical impact is interpreted through the desiderata. By assigning the technologies to specific software stack layers, the impact of each gravity well can be more precisely assessed across the system.

In the baseline case, progress toward the problem’s goal is unguided, exposing the user to maximum complexity. The desiderata provide guidance: in the short term, they help reduce this complexity; in the long term, they support resilience and co-evolution with the surrounding technology ecosystem.

5 Demonstration: Framework Usage in Practice↩︎

In this section, we first apply the framework to three cases representing distinct approaches to QC-HPC workflow execution. Then, we analyze how each supports or constrains experimentation and evolution.

5.1 Case Studies↩︎

The workload execution scenarios span current QC–HPC integration approaches. Each case is described via its execution model, tracing how a quantum workload moves from the developer environment through scheduling and resource allocation to execution. These cases were chosen in order to evaluate the diversity of execution models for QC-HPC integration and to see the coverage of gravity well properties.

5.1.1 Qubernetes↩︎

In the Qubernetes execution model [64], the user initiates execution via the q8sctl toolkit⁷, which packages the quantum workload, developed with the user’s QSDK of choice, together with its dependencies into a container image. This ensures a reproducible and portable execution environment across targets. The resulting container is submitted to the Kubernetes cluster as a job, where the scheduler assigns it to an appropriate execution target represented as a node. These nodes encapsulate available compute capabilities, including classical resources (CPU, GPU) for simulation and gateways to remote QPU backends for quantum execution. Beyond native cluster resources, Qubernetes integrates HPC environments through mechanisms such as interLink [22], exposing them as virtual nodes. This enables HPC resources to participate in the same scheduling and execution model as cloud-native resources, preserving a unified abstraction throughout the execution path.

5.1.2 Hybrid circuit-cutting workflow↩︎

In this execution model [24], the user initiates the execution path by submitting the workload as an Argo Workflow⁸, which represents the multi-stage QC-HPC computation as a declarative pipeline. The workload is containerized, ensuring reproducibility and portability across execution environments. Once deployed to the Kubernetes cluster, the workflow engine orchestrates execution: the Qiskit circuit is partitioned into smaller independent tasks, and Argo manages their dependencies and execution order across the pipeline. The cluster capabilities are extended with Kueue⁹, which provides a unified queuing and scheduling layer for heterogeneous resources. Through this mechanism, nodes exposing CPU, GPU, and QPU capabilities, whether on-premises or accessed remotely, are treated within a single orchestration domain. This allows workloads to be dynamically scheduled to appropriate execution targets based on availability and policy constraints, while maintaining a consistent execution model. In this way, the integration bridges traditional HPC resource management with cloud-native orchestration, completing the execution path through a unified control plane that abstracts underlying infrastructure diversity.

5.1.3 HPC↩︎

In the HPC execution model, the execution path is initiated by preparing the workload in the developer environment and staging it to the HPC system using standard data transfer mechanisms, such as secure copy or shared file systems. The user then submits the workload through the native HPC scheduler (e.g., Slurm), specifying resource requirements, execution parameters, and the program entry point. The scheduler manages the lifecycle of the job by placing it in a queue and dispatching it to allocated compute nodes once resources become available. These nodes provide classical computation capabilities, including CPUs and GPUs, which are used for simulation, data preparation, and post-processing. Within the execution phase, parallel workloads may leverage MPI to coordinate distributed computation across multiple nodes, enabling scalable simulation and data processing. The interactions with quantum hardware could be handled through the QDMI interface [11]. Recent work on QC-HPC integration has shown that not only does this pattern translate well when QPUs are present, but that it also enables diversity of execution patterns to serve various needs depending on performance constraints [65], [66].

5.2 Identifying the gravity wells↩︎

The execution path graphs from the above case studies are extracted and merged into a single comparative view, depicted in Fig. 5. Two components emerge as structural gravity wells, by virtue of the density of connections passing through them: the api-server and kubelet pairing in the Kubernetes-based cases, and Slurm across all three. Both components sit at the convergence of multiple workflow paths, meaning that architectural decisions made with respect to these components propagate across a wide surface of the environment. Their centrality in the graph is not coincidental: it reflects the current state of QC-HPC integration, in which practitioners must route quantum workloads through infrastructure originally designed for classical computation.

The gravity wells’ properties are visible in all cases, although with different degree of prominence. The workflow specialization is most clearly visible on Slurm, as the primary interface to utilize HPC resources. Its use across all cases reflects the lack of comparable alternatives. Each case integrates it differently, producing workflows tailored to specific needs rather than converging to a shared abstraction. This specialization is structurally characteristic of an emerging field, leading to coordination overhead and concentrated expertise, as noted in the gravity well properties analysis.

The technology entrenchment gravity well property is evident in the prominent role of both Kubernetes and Slurm across the cases. Both technologies are mature, widely adopted, and operationally well-understood within their respective domains. Their selection reflects the practical logic of building on established infrastructure. At the same time, this reliance shapes the integration approaches available to practitioners: the Kubernetes-based cases in particular represent an effort to extend cloud-native orchestration semantics into the HPC domain, effectively using Kubernetes as a stable substrate around which novel QC-HPC integration is constructed. This is a productive form of entrenchment insofar as it leverages existing operational knowledge, but it also means that the architectural assumptions embedded in Kubernetes and Slurm propagate into the quantum integration layer, potentially constraining how that layer can evolve.

The ecosystem convergence pressure gravity well property is present but operates differently across the cases. Kubernetes functions less as a locking ecosystem actor and more as an intermediate orchestration layer that, by design, abstracts the diversity of underlying resources. Its role in the case studies 1 and 2 is closer to that of a neutral integration substrate than a proprietary ecosystem. Slurm, by contrast, operates as a more direct convergence point: its dominance in HPC scheduling means that integration with HPC resources is effectively synonymous with integration with Slurm in the current landscape, regardless of whether practitioners would prefer an alternative. The broader ecosystem convergence pressure – toward Qiskit as the dominant QSDK, toward the circuit paradigm as the primary abstraction model, and toward specific vendor backends – is present in the background of all three cases but is not the primary structural feature that the graph makes visible.

5.3 The gravity wells from the desiderata perspective↩︎

Each identified gravity well contains aspects that support progress toward at least some of the desiderata, while simultaneously introducing tensions with others (Table 2). No gravity well is uniformly enabling or uniformly constraining across all four dimensions, a finding that is consistent with the spectrum-based framing established in the gravity well analysis and that underscores the context-dependence of any evaluation.

The api-server and kubelet together form a cluster of open, composable dependencies that perform well against transparency, skill portability, and experimentation, but whose contribution to avoiding irreversible constraints depends on the quality of the abstraction maintained at the node boundary. Slurm, by contrast, offers operational maturity and domain-specific transparency within the HPC context, but performs more weakly against portability and the avoidance of irreversible constraints, particularly as quantum workload requirements begin to diverge from the classical batch processing assumptions that Slurm was designed to serve [67]. Across both gravity wells, the desideratum of preserving productive experimentation emerges as the most nuanced to evaluate: each well simultaneously supports and constrains experimentation, depending on whether one is experimenting within the well’s operational domain or attempting to integrate across domain boundaries.

The two gravity wells are structurally distinct in character. The Kubernetes api-server is a deliberately extensible and vendor-neutral component as an open-source project with broad community participation. Its design as a general-purpose declarative control plane means that it can accommodate heterogeneous resource types and integration patterns without requiring practitioners to commit to a specific vendor ecosystem. Critically, the tools that extend it in case study 2 operate as additive layers that augment the API server’s capabilities without introducing new proprietary constraints. They conform to the Kubernetes extension model, meaning that their adoption does not narrow the architectural choices available downstream. The api-server therefore functions as a high-versatility gravity well: its pull is real and its centrality is significant, but the dependencies it introduces are relatively open and composable.

Slurm, by contrast, is a domain-specific scheduler optimized for the static, tightly managed resource environments of traditional HPC infrastructure. Its dominance in HPC job scheduling means that, in practice, HPC integration is largely synonymous with Slurm integration — regardless the practitioner’s preferences. Unlike the Kubernetes api-server, Slurm does not offer the same degree of architectural openness or community-driven extensibility, and the workflow configurations built around it tend to be more tightly coupled to its scheduling semantics. The gravity well it constitutes is therefore more constraining in character: the pull it exerts tends to concentrate workflow specialization around its specific abstractions and operational assumptions, with fewer composable escape routes available to practitioners who wish to evolve their environments.

6 Evaluation and Discussion↩︎

In this section, we revisit the research questions, reflect on the framework’s performance in the case studies, and outline the study’s threats to validity.

6.1 Research questions revisited↩︎

To conclude the contributions of this article, we will provide explicit answers to our research questions:

• RQ1: The orchestration infrastructure can be designed by using the proposed framework: identifying gravity wells and evaluating them through the socio-technical desiderata.

• RQ2: We identified four attributes: (I) operational and governance transparency, (II) knowledge and skill portability, (III) avoiding irreversible choices and constraints, and (IV) preserving productive failure and allowing experimentation for evolution.

• RQ3: Through this study, we concluded that the highly connected points in the technological ecosystem graphs can be gravity wells if they affect workflow specialization, technology entrenchment, or ecosystem convergence.

6.2 Framework Reflection↩︎

The demonstration reveals that the application of the framework can be organized into three sequential phases, corresponding to its three core concepts. In the first phase, the target environment is examined and represented as a technological and/or architectural graph. This graph is then evaluated against the technological criteria, with particular attention paid to heavily connected nodes. In the second phase, potential problem points identified within the graph serve as the basis for recognizing gravity wells. Once the gravity wells have been identified – and their existence and relative prominence assessed by the proposed gravity well properties – the third phase begins: evaluating their impact using the desiderata.

This evaluation determines whether the heavily weighted nodes that give rise to the gravity wells genuinely advance the field by creating conditions that enable the desiderata to be satisfied. Taken together, the three phases allow the framework to support more informed and rationally grounded decision-making in the design of technological environments within a given context. In a broad sense, the contribution of this paper, the framework, is not an evaluation of QC-HPC ecosystems but rather a guide on how to evaluate these ecosystems.

The application of the framework to the three cases demonstrates both its analytical reach and its current limitations. On the productive side, the gravity well construct with the three properties proved effective at surfacing structural features of the environment that would not be visible through a purely feature-based evaluation of individual tools. The identification of the API server and Slurm as the two densest nodes in the unified technological graph, and the subsequent analysis of how their structural characters differ, generated insights about architectural risk and evolutionary potential that are not captured by asking simply whether a tool is mature or interoperable. The desiderata similarly proved useful as a multi-dimensional evaluative lens: by requiring the analyst to assess each gravity well against four distinct normative goals rather than a single axis, the framework resists the tendency toward reductive good or bad judgments that would obscure the context-dependence of environment choices.

At the same time, the demonstration reveals areas where the framework would benefit from further development. The construction of the technological graph currently relies on the analyst’s familiarity with the cases, and a more systematic method for identifying nodes, edges, and gravity wells from documented architectures would increase the framework’s reproducibility and reduce its dependence on tacit knowledge. The desiderata evaluations in the table are necessarily qualitative, and the framework does not yet provide guidance on how to weight competing desiderata when they point in different directions. Finally, the three cases examined here represent a specific slice of the QC-HPC integration landscape. Further validation across a broader range of environment configurations would strengthen the generalizability of the framework’s findings.

6.3 Threats to validity↩︎

Several threats to validity, according to [68], are identified in the context of this work. Regarding conclusion validity, the framework was not subjected to systematic empirical evaluation. Moreover, the evaluation procedure depends on practitioner expertise regarding the system under consideration, rendering the assessment inherently subjective and potentially difficult to reproduce. Internal validity is threatened for analogous reasons. With respect to construct validity, the concepts and criteria comprising the framework represent a first iteration, remain incomplete, and continue to be under development, and thus may not yet fully or accurately capture the underlying theoretical constructs they are intended to operationalize. Finally, external validity is threatened by the fact that the framework was designed with the QC-HPC context specifically in mind.

7 Conclusions and Future Work↩︎

QC-HPC integration is a socio-technical problem in the broad sense. By characterizing it in this manner and abstracting aspects of the stack to those relevant to individual component choices, we obtain a picture of the complexity and possible reasons for the emergence of frictions across the stack. These partition the space of choices into those creating advantageous and disadvantageous outcomes as we approach gravity wells. The socio-technical desiderata helps us understand the impact of these gravity wells. The framework as a whole guides the evaluation of technological environments. After developing the framework, we demonstrated it in three different use cases: Qubernetes, CERN, and HPC. We applied the framework to these cases and saw the benefits of using it. None of the gravity wells seem to be uniformly enabling or constraining, and the desiderata appear to guide the technological decisions towards enabling a future of evolving through experimentation.

Future work will proceed along four principal directions. First, a systematic survey of existing software solutions will be conducted to characterize the stack. Second, a broader understanding of the scope and interdependencies among gravity wells will be developed. Third, the framework itself will be refined and extended, for instance, by applying graph theory and developing scoring methods for nodes and paths, incorporating TRLs in those methods. Fourth, the framework will be applied to real-world case studies.

Acknowledgments↩︎

This work has been supported by Business Finland projects EM4QS (155/31/2024) and the Research Council of Finland project DEQSE (349945). S. Núñez-Corrales thanks the National Center for Supercomputing Applications for partial funding support via by the Leadership-Class Compute Facility project (NSF #2323116).

References↩︎