Marin Ivezic
A team at the University of Naples Federico II brought up a superconducting quantum computer that no single vendor sold them as a finished product. The quantum processing unit, or QPU, is the chip that holds the qubits, and theirs came from QuantWare, a Dutch company that sells superconducting processors much as a semiconductor firm sells CPUs. The refrigeration, the control electronics and the software around the chip were sourced and assembled separately. The group works under Francesco Tafuri, a superconductivity physicist at the university, and the arrangement changed what the team spent its time on: a commercially available processor meant the effort went into the system and its applications rather than into fabricating qubits.
For most of the past two decades a quantum computer arrived as one indivisible product from a company such as IBM, Google or D-Wave, or it was built by a national laboratory from scratch. Increasingly it arrives as parts. Someone has to assemble those parts into a machine that performs, and then connect that machine to the infrastructure an organisation already runs. That work is quantum systems integration, and the people who do it are quantum systems integrators.
This article sets out what the role involves: what has to be made to agree at the hardware level, what has to be made to agree at the enterprise level, and which skills a team needs before it takes on either job.
Two Jobs Under One Title
Quantum systems integration covers two distinct kinds of work, and treating them as one is the fastest route to an under-scoped project.
The first is platform integration, which is the work of building the quantum machine itself from components. It reaches from the qubit chip up through the control electronics, the cryogenics, the firmware and the calibration software to the point where the machine reliably executes a circuit and returns a trustworthy result.
The second is enterprise integration, which begins where the first ends. It connects that working machine to schedulers, identity systems, data pipelines, developer toolchains and monitoring, so that people other than the physicists who built it can use it as part of their normal work.
Different skills, different failure modes, different budgets. A team can be excellent at one and useless at the other, and we see that pattern often enough that we teach the two tracks separately.
From Closed Stacks to Component Catalogues
Under the closed-stack model a single vendor supplies everything: qubits, control hardware, refrigerator, firmware, software, support contract. The interfaces between the layers are internal and mostly undocumented, which is efficient for the vendor and restrictive for the buyer. You get the vendor’s control electronics because nothing else will drive their chip, and you get their software because nothing else speaks to their control electronics.
Quantum open architecture, usually shortened to QOA, is the practice of publishing those interfaces so that parts from different suppliers can be connected. Signal formats, connector standards, timing conventions and software APIs are specified openly, and any supplier who meets them can sell into the resulting market. One firm concentrates on qubit chips, another on microwave control racks, a third on refrigeration, a fourth on calibration software.
The parallel with classical computing is exact enough to be useful. In the 1960s and 1970s a computer came from IBM or DEC as a complete system, including the processor, the storage, the operating system and the terminals. What broke that model was not a single better machine, it was the arrival of documented interfaces: a bus specification, an instruction set, a disk protocol. Once those existed, Intel could specialise in processors without building a computer, Seagate could specialise in drives, and a systems integration industry grew up between the component makers and the customers. Progress accelerated because a hundred companies were each optimising one thing, and because a buyer could replace one part without replacing the whole.
Quantum hardware is at the very beginning of that transition. The component suppliers exist, the interface specifications are partial, and the integration industry is a handful of companies. Germany’s ParTec AG moved from high-performance computing into building quantum computers as an integrator, and describes its approach as qubit-agnostic, meaning it selects the qubit technology to suit the workload rather than committing to one. TreQ, working in the UK and the US, builds bespoke quantum clusters from open-architecture components and designs them to be upgradable and compatible with the customer’s existing infrastructure. QuantWare, Qblox and Q-CTRL have announced a joint offering, the Quantum Utility Block, that ships as pre-integrated reference systems in several sizes, so that a buyer gets a validated combination rather than a shopping list.
Here we should be blunt about the marketing. The language around open architecture often suggests something close to plug-and-play, with parts snapping together and a machine appearing at the end. It doesn’t work that way yet, and organisations that budget as if the integration were as modular as the components routinely under-fund the engineering.
Platform Integration, Layer by Layer
What follows is the work that sits between a delivered crate of components and a machine that produces results you’d put in a paper or a production pipeline.
Calibration Never Finishes
Calibration is the process of measuring how each qubit actually behaves and adjusting the control signals to match. Every qubit on a chip has a slightly different resonant frequency, a slightly different response to a given microwave pulse and a slightly different noise environment. The control system has to be told all of it, pulse shape by pulse shape.
When the chip and the controller come from the same vendor, much of that mapping ships pre-computed. When they come from different vendors, the integrator establishes it. That means weeks of measurement, and it means building the automated routines that repeat the measurement, because qubits drift. Temperatures shift, components age, a nearby piece of equipment starts emitting, and yesterday’s calibration produces today’s errors. A production quantum system runs calibration as a scheduled job, not as a commissioning task.
Interfaces Before Standards
QOA implies common standards. In practice the standards are partial and still being written, so two components that both claim compliance may still disagree about something specific: the shape of a readout pulse, the trigger timing on a fast feedback line, the exact meaning of a field in an instruction stream.
None of these gaps is fatal, and all of them cost time. The integrator’s real product is knowing which combinations have been made to work, where the mismatches sit, and what adapter, whether a physical component or a translation layer in software, closes each one. That knowledge is currently held in a small number of heads and a small number of engineering wikis, which is a reasonable description of where the field is.
The Physical Build
Superconducting qubits operate at around ten millikelvin, a hundredth of a degree above absolute zero, inside a dilution refrigerator. The refrigerator is roughly the size of a wardrobe, weighs a great deal, needs vibration isolation, and takes a day or more to cool down and considerably longer to warm up safely.
Every control signal reaching the chip travels down a cable that also conducts heat, so the wiring is a thermal budget as much as an electrical one. Attenuators, filters and thermal anchoring at each temperature stage are what keep the cooling power ahead of the heat load, and a scaled-up machine may need thousands of such lines. Where the control rack sits relative to the refrigerator affects signal latency and noise pickup. Power, floor loading, helium supply and acoustic isolation are facility questions that need answering before the hardware is ordered, not after it arrives on a loading dock.
Coherence Is Lost at the Joins
Coherence is the property that makes a qubit useful: the ability to hold a quantum state long enough to compute with it. Decoherence is the loss of that state, and it is caused by essentially any uncontrolled interaction with the environment, including stray electromagnetic fields, thermal photons and mechanical vibration.
Interfaces are where this gets expensive. A ground loop created by connecting two vendors’ instruments, an unfiltered line, an unshielded run of cable near a switching power supply: each one can shorten coherence times enough to change what algorithms the machine can run. Shielding, filtering and grounding discipline are ordinary electrical engineering, applied with unusual severity, and they are the least glamorous and most consequential part of a platform build.
Software and Firmware
A quantum computer runs several software stacks that were not written to know about each other. One drives pulses to the qubits. One monitors the refrigerator’s temperature and pressure. One manages calibration data. One presents a job queue to users. The integrator connects them, and then writes the logic that makes them behave sensibly together, so that a refrigerator excursion pauses experiments rather than quietly corrupting a week of results.
Some of this is glue code, and some of it is genuine systems software: driver layers, instrument abstraction, a results database, an API. A quantum system that works only when the person who built it is in the room is a research instrument. Turning it into a service is mostly a software engineering job.
Who Owns the Fault
Multi-vendor builds create an accountability question that closed stacks avoid. When gate performance is below specification, each vendor’s diagnosis tends to point at the other vendor’s box, and none of them can see the whole system.
The integrator carries the diagnosis. That requires enough measurement capability to isolate a fault to a layer, and it requires working relationships with each supplier, often under non-disclosure agreements, because calibration models and pulse-shaping details are exactly the intellectual property a component vendor is least willing to publish. Contracting matters here more than people expect. Responsibility for end-to-end performance, and the evidence that triggers a supplier obligation, belongs in the contract, settled before the first crate arrives.
Provenance sits alongside this. If a quantum system is going to hold a position in critical infrastructure, the supply chain for its components deserves the same vetting any other critical hardware gets.
Benchmarking the Assembled System
The assembled machine has to be measured, because integration can degrade performance in ways nobody intended. The core measurements are coherence times, single-qubit and two-qubit gate fidelities, readout error and crosstalk between neighbouring qubits. Gate fidelity is the fraction of operations that do what they were asked to do, and two-qubit gate fidelity is usually the number that limits what an algorithm can achieve.
Benchmarking serves two purposes. It tells you whether the system meets the specification the components promised, and it gives you the baseline against which future drift is detected. A result below expectation starts a diagnosis that crosses vendor boundaries again, and the ability to run that diagnosis quickly is one of the clearest differences between an experienced integration team and a first-time one.
Enterprise Integration
A quantum machine that works is not yet a quantum capability. The second job is connecting it to how the organisation actually computes.
Scheduling a Resource That Behaves Unlike a Node
High-performance computing, or HPC, centres run their work through batch schedulers such as Slurm, which queue jobs and allocate them to compute nodes according to policy. A QPU can be presented to a scheduler as a resource, but it is an unusual one: there is typically a single unit rather than a pool, it may be unavailable during calibration, and the jobs that use it are short bursts embedded inside longer classical computations.
ParTec and Quantum Machines co-developed QBridge, announced jointly by the two companies, to address exactly this, coupling quantum hardware into HPC scheduling so that multiple users can run hybrid workflows without each opening a separate portal. The goal is worth stating clearly, because it defines success for the whole enterprise track: a researcher submits one job, and the scheduler dispatches the quantum portion to the QPU and the rest to CPUs and GPUs, with the user never handling the split manually.
The Latency of the Hybrid Loop
Many near-term quantum algorithms run as a variational loop. The quantum processor executes a parameterised circuit, returns a measurement, a classical optimiser computes better parameters from that measurement, and the loop repeats, often thousands of times. Each iteration is short. The round trip between quantum and classical is what dominates the wall-clock time.
That makes placement an architectural decision rather than a procurement detail. A QPU sitting beside the classical cluster on a fast interconnect can run loops that are simply impractical across a public cloud API, where the round trip on each iteration is compounded by queue waits, and thousands of iterations turn a same-day experiment into a multi-day one, driven largely by queuing rather than raw network latency. When the quantum resource is remote and the data is on-premises, the integration work shifts to moving classical compute closer to the quantum service, or to restructuring the algorithm so that fewer round trips are needed.
An Interface Developers Already Know
Quantum programming today mostly happens in Python, using vendor libraries that talk to a specific backend. An enterprise application written in Java or C++ should not have to be rewritten to make use of a quantum routine.
The usual answer is a service boundary. A portfolio optimisation application calls an internal endpoint, sends a problem in a format its own developers understand, and receives a result. Behind that endpoint sits the translation into a quantum circuit, the submission, the error mitigation and the classical fallback. Your developers do not need to learn quantum mechanics to call it, and we consider designing that boundary well to be one of the highest-value things an integrator does, because it determines how many people in the organisation can actually reach the machine.
Access Control, Monitoring and Fallback
An on-premises quantum computer is a new piece of infrastructure and inherits the ordinary obligations. Access is federated with the corporate identity provider rather than managed by a local user list. Job submissions are logged. The control workstation that drives the QPU is hardened and segmented, because it is the single point from which the machine can be misconfigured. Data moving to and from the system is protected to whatever standard the source data demands.
Monitoring matters more than for a classical node, because the failure modes are less familiar. Refrigerator excursions, calibration failures and qubits dropping out of specification all need alerting, and someone needs to have decided in advance what happens to queued work when they occur. Where the algorithms are portable, a cloud quantum service can serve as a fallback during maintenance, and where they aren’t, the schedule needs to account for downtime honestly.
More Than One Modality
Superconducting qubits are not the only technology, and an organisation with more than one quantum resource has an allocation problem. Trapped-ion systems typically offer longer coherence and higher gate fidelity at slower clock speeds and full connectivity between qubits. A quantum annealer, which is a special-purpose device that finds low-energy configurations of a problem rather than running general circuits, suits certain combinatorial optimisation tasks and cannot run general algorithms at all. Photonic systems bring different trade-offs again.
Cloud platforms such as AWS Braket already expose several hardware types behind one interface, with the choice left to the user. What doesn’t exist yet is an orchestration layer that reads a workload and routes each part to the appropriate processor automatically. Until it does, the routing decision is an architectural one, made by people who understand both the algorithm and the hardware, and documented so that it can be revisited when the hardware moves. It moves often.
What the Role Demands
The skills below rarely sit in one person, and a competent integration team covers all of them between its members.
Quantum hardware familiarity. Enough understanding of superconducting, trapped-ion, photonic and annealing systems to know what each needs from its environment and which workloads suit which.
Cryogenics and analogue electronics. For any hardware build, practical knowledge of refrigeration, vacuum, microwave signal chains, filtering and grounding. This is hands-on experimental work, not theory.
HPC architecture and networking. Schedulers, interconnects, storage, parallel job design. Integrators who came from the HPC world, ParTec among them, brought this in and it turned out to be one of the harder gaps to fill from the physics side.
Software engineering and DevOps. Firmware and pulse-level control at the bottom, drivers and APIs in the middle, user-facing services at the top, with version control, testing and deployment pipelines applied throughout.
Algorithm literacy. Not invention, but enough understanding of the intended workloads to make trade-offs. A platform tuned for chemistry simulation prioritises two-qubit gate fidelity. One tuned for optimisation may prioritise qubit count and connectivity.
Security and operational risk. Hardening, access control, logging, supply chain assurance, and contingency planning for when the machine is unavailable. A production quantum system deserves the rigour applied to any other critical platform.
Multidisciplinary project management. Coordinating physicists, engineers, facilities staff, vendors and end users, under genuine technical uncertainty, and translating between the physics team and the people approving the budget.
Very few organisations hold all of that today. Some will build it internally, some will buy it from an integrator, and most will do both, which is why we treat the skill set as something to be taught deliberately rather than accumulated by accident.
Where This Is Going
Three things are reasonably predictable from the current position. Interface standards will firm up, and combinations of components will start being certified as validated together rather than assembled hopefully. Pre-integrated reference systems will get better, reducing the platform work while leaving the enterprise work untouched. And shared facilities will multiply, with regional hubs and consortia operating open-architecture machines that several organisations use, which spreads the cost of the integration expertise across more than one balance sheet.
None of that removes the role. Standardisation in classical computing didn’t eliminate systems integrators, it moved them up the stack, from making the parts work to making the system serve the business. The same shift is coming here, and the people who are useful during it will be the ones who understand both ends.
For an organisation with a pilot underway, the deployment questions are worth asking early: who builds it, who operates it, who secures it, who upgrades it, and how it connects to the infrastructure already running. Those questions have answers, and the answers determine whether a promising proof of concept becomes infrastructure or stays a demonstration.
Learning the Role
Quantum Academy built the Certified Quantum Systems Integrator (CQSI) program around the two tracks described here. Candidates work through platform integration, covering component selection, calibration, cryogenic and signal-chain engineering, and benchmarking of an assembled system, and then through enterprise integration, covering hybrid scheduling, hybrid loop architecture, service interfaces, access control and operational monitoring. The assessment is built around integration decisions rather than recall, because the decisions are what the role consists of.
You can review the program and its prerequisites at quantumacademy.com/. If you’re weighing this against other routes into quantum engineering, QuantumCareers.com maps how the integration path relates to hardware, software and security roles. And for a longer technical treatment of the open architecture shift itself, the underlying analysis is published at PostQuantum.com.