Marin Ivezic
A team orders a superconducting quantum processor from one company, a dilution refrigerator from a second, and a control electronics rack from a third. Three purchase orders, three warranties, three sets of documentation. The equipment arrives, the room gets cold, and the first circuits run. Then the qubits drift out of calibration on a Tuesday morning, and somebody has to answer a question none of the three contracts covers. Whose problem is this?
Quantum Open Architecture (QOA) is the design philosophy that says a quantum computer should be assembled from interchangeable, standards-based parts rather than delivered as one vendor’s sealed box. Quantum Systems Integration (QSI) is the engineering discipline that makes the assembly work: component selection, interface management, acceptance testing, and operations across parts that were never designed together. QOA is the promise. QSI is the invoice.
The comparison everyone reaches for is the mainframe, and it holds on the main point. IBM once built the processor, the memory, the operating system, and the applications, and customers bought the whole thing or nothing. Standardized buses broke that apart and let specialists compete layer by layer. Where the comparison stops helping is at the interface itself. A PC expansion bus carried digital signals with defined voltages and timing tolerances. The internal boundaries of a quantum system carry analog microwave pulses, thermal load, magnetic field constraints, and calibration state that changes hour to hour. Turning those boundaries into contracts is the hard part, and it is most of the job.
What makes a seam real
An interface becomes a seam – a place the system can be cut and reassembled with parts from different suppliers – when three things are true. There is a specification at the boundary. There is a test that passes or fails at that boundary without opening either side. And there is a named owner for the failure. Miss the third and you have a diagram, not an architecture.
Four seams carry most of the risk in a modular quantum program. They are worth walking in order, because each one constrains the next.
The chip and the control rack
Underneath the software, a quantum processor is a set of physical systems steered by precisely timed signals. Superconducting qubits are driven by microwave pulses, trapped ions by laser sequences, spin qubits by gate voltages. The seam is the wiring plane and its signal specification. How many lines, at what frequencies, with what attenuation, delivering how much heat per line.
Companies including Quantum Machines, Zurich Instruments, and Keysight build the control side. QuantWare sells superconducting processors as standalone components to customers who bring their own control electronics and cryogenics. The pairing works when the processor vendor publishes a complete signal map and the control vendor can generate to it. It fails quietly when a qubit underperforms and neither side can demonstrate that the pulse arrived as specified. Acceptance testing here is the only thing that keeps a fidelity dispute from becoming a standoff between two suppliers who each have data.
Control and orchestration
Above the pulse hardware sits the software that runs the machine, including compilers that turn circuits into pulse schedules, hardware abstraction layers, schedulers, and the error-correction decoders. Error correction spreads one logical qubit across many physical ones. A logical qubit is the stable unit an algorithm actually uses. The encoding is maintained by repeatedly measuring syndromes, patterns of parity checks that reveal where an error occurred without disturbing the encoded state. A decoder reads those syndromes and decides what correction to apply.
On superconducting hardware, syndrome rounds are fast. Google Quantum AI’s 2023 surface-code experiment in Nature (arXiv:2207.06431) reports a cycle time of about 1.1 microseconds, and the decoder has to keep pace at that rate or fall permanently behind. That timing converts a software boundary into a hardware boundary. The decoder can’t run in a cloud region. It runs next to the control rack, often on FPGAs, inside a latency budget the architect writes down before either side is chosen. This is the seam where modularity is hardest to preserve, and it is where vendors have the strongest commercial reason to close the box again.
The cold budget
Superconducting and silicon-spin processors operate at millikelvin temperatures, a few thousandths of a degree above absolute zero. Getting there commercially means a dilution refrigerator, which cools by forcing helium-3 atoms across a phase boundary into a helium-4-rich phase. The method rests on a specific physical fact. Helium-3 stays soluble in helium-4 all the way down to absolute zero, at roughly 6.6 percent, so the dilution never stops, and Pobell’s Matter and Methods at Low Temperatures gives that finite solubility limit as the reason the technique works at all. Helium-4 on its own can’t do it, and no amount of supply substitution changes that.
Trapped-ion, neutral-atom, and photonic systems don’t need dilution refrigeration at all. Modality choice and facility design are therefore the same decision, made once, early, and expensively if made twice.
Every added qubit adds signal lines, every line carries heat down to the coldest stage, and cooling power at millikelvin is small and fixed. The cold budget is an architectural constraint rather than a facilities detail. Wiring density, attenuator placement, and multiplexing scheme all get decided against a power ledger measured in microwatts. Adiabatic demagnetization is the alternative worth tracking. It applies a magnetic field to a paramagnetic salt and then removes it to pull heat out, and it reaches millikelvin without helium-3. Reaching a temperature and holding it under the load of several hundred wires are different engineering problems, and continuous operation at competitive cooling power is still being demonstrated rather than sold.
The machine and the user
Most organizations will meet quantum computing through a cloud endpoint rather than a loading dock. Quantum-as-a-Service (QaaS) platforms such as IBM Quantum, Amazon Braket, and Microsoft Azure Quantum already place multiple backends behind a single interface. That is modularity at the delivery layer, and it inherits the same seam question.
Job submission formats, transpilation behavior, error-mitigation defaults, and result formats differ between backends. Code moves. The performance characteristics do not move with it, so a portability claim needs a benchmark attached before anyone plans around it. The second question at this seam is jurisdictional. Where does the circuit execute, who can see it, and is the circuit itself the intellectual property the program was funded to protect. Answer that during architecture, not during procurement.
What the role becomes
Integration used to be the last step in a program. In a modular quantum program it is the first. The architect’s deliverables move from a component list to a set of interface documents, including signal maps, latency budgets, thermal ledgers, calibration ownership, and acceptance criteria written before anything is ordered.
Three failure modes recur in programs that stall. A seam with a specification and no test. A seam with a test and no owner. And a modality chosen before the facility was costed. All three are avoidable at the design stage and expensive at every stage after it.
This is the skill set our quantum systems integration program is built around: reading a quantum stack as a set of seams, specifying what crosses each one, and holding vendors to a test rather than a datasheet. If your organization is moving from evaluating quantum hardware to specifying it, that is the transition the program is designed for. Program details and enrollment are at Quantum Academy.