Enterprise Architecture Integration Patterns — Operating Quantum Computers

Quantum platforms do not exist outside the enterprise. They touch identity, cloud accounts, HPC clusters, data warehouses, MLOps pipelines, security programs, procurement, finance, research governance, customer-success systems, and executive reporting. The architecture decision is whether quantum becomes an isolated science project or a governed enterprise capability.

The correct pattern is rarely “give every team direct provider access.” Direct access maximizes short-term velocity and long-term inconsistency. A brokered platform preserves experimentation while centralizing policy, evidence, cost controls, and target abstraction.

Diagram loads as you read

Enterprise Architecture Integration Patterns · Figure 1

View diagram source

flowchart LR
    Users[Users and teams] --> Portal[Quantum portal/API]
    Portal --> Broker[Quantum broker]
    Broker --> Providers[Cloud providers and labs]
    Broker --> HPC[HPC/GPU/simulators]
    Broker --> Evidence[Evidence warehouse]
    Broker --> Policy[Policy engine]
    Broker --> FinOps[FinOps]

Integration map

Diagram loads as you read

Integration map · Figure 2

View diagram source

mindmap
  root((Enterprise quantum integration))
    Identity
      SSO
      service accounts
      approvals
    Data
      warehouse
      catalog
      lineage
    Compute
      cloud QPU
      HPC
      GPU
      simulators
    Governance
      policy
      claims
      risk
    Finance
      budgets
      chargeback
      reservations
    Product
      customer pilots
      roadmaps

Quantum should integrate with the systems that already control trust, cost, and reproducibility.

Broker pattern

Diagram loads as you read

Broker pattern · Figure 3

View diagram source

sequenceDiagram
    participant App
    participant Broker
    participant Policy
    participant Provider
    participant Evidence
    App->>Broker: submit workload contract
    Broker->>Policy: evaluate
    Policy-->>Broker: allow with obligations
    Broker->>Provider: provider-specific submission
    Provider-->>Broker: result and metadata
    Broker->>Evidence: normalize and store
    Broker-->>App: stable enterprise response

The broker provides:

stable enterprise API;
provider abstraction;
target-class routing;
policy enforcement;
evidence capture;
cost controls;
audit;
graceful provider exit.

Direct-provider anti-pattern

Diagram loads as you read

Direct-provider anti-pattern · Figure 4

View diagram source

flowchart TB
    TeamA[Team A notebook] --> ProviderA[Provider account]
    TeamB[Team B script] --> ProviderB[Provider account]
    TeamC[Team C workflow] --> ProviderC[Provider account]
    ProviderA --> Fragment[Fragmented evidence]
    ProviderB --> Fragment
    ProviderC --> Fragment
    Fragment --> Risk[Uncontrolled cost and claims]

Direct provider access may be acceptable for early exploration. It should not become the production integration model.

Enterprise API contract

Illustrative listing · yaml

quantum_workload_contract:
  project_id: portfolio-optimization-rd
  workload_type: variational_optimization
  target_class: gate_model_small
  data_class: internal_research
  budget:
    max_usd: 200
    max_wall_clock_hours: 6
  evidence:
    level: reproducibility
  output:
    format: distribution_with_metadata

Diagram loads as you read

Enterprise API contract · Figure 5

View diagram source

flowchart LR
    Contract[Workload contract] --> Validate[Validate]
    Validate --> Route[Route]
    Route --> Execute[Execute]
    Execute --> Normalize[Normalize result]
    Normalize --> Return[Return stable API response]

The application should not need to know every provider-specific option unless it explicitly requests expert mode.

Data architecture

Diagram loads as you read

Data architecture · Figure 6

View diagram source

erDiagram
    BUSINESS_USE_CASE ||--o{ QUANTUM_PROJECT : sponsors
    QUANTUM_PROJECT ||--o{ WORKLOAD : contains
    WORKLOAD ||--o{ RUN : executes
    RUN ||--o{ RESULT : produces
    RESULT ||--o{ DATA_PRODUCT : feeds
    DATA_PRODUCT ||--o{ DASHBOARD : surfaces

Quantum data products should be discoverable through the enterprise catalog:

benchmark datasets;
validated result distributions;
cost curves;
target health summaries;
evidence packages;
reusable workload templates.

HPC and simulator integration

Diagram loads as you read

HPC and simulator integration · Figure 7

View diagram source

flowchart TB
    Workload[Quantum workload] --> Pre[Pre-processing]
    Pre --> Sim[Simulator/HPC/GPU]
    Sim --> HardwareGate{Hardware needed?}
    HardwareGate -- no --> Store[Store result]
    HardwareGate -- yes --> QPU[QPU execution]
    QPU --> Post[Post-processing]
    Post --> Store

Many workloads should spend most of their lifecycle outside the QPU. The enterprise architecture must make simulator and HPC paths first-class, not secondary.

Identity and approval integration

Diagram loads as you read

Identity and approval integration · Figure 8

View diagram source

flowchart LR
    SSO[Enterprise SSO] --> Role[Role mapping]
    Role --> Capability[Quantum capabilities]
    Capability --> Approval[Approval workflow]
    Approval --> Broker[Broker token]
    Broker --> Audit[Audit event]

Approvals should be integrated into existing enterprise mechanisms where possible. Avoid one-off approval spreadsheets.

Finance integration

Diagram loads as you read

Finance integration · Figure 9

View diagram source

flowchart TB
    Run[Run] --> Cost[Cost record]
    Cost --> Project[Project budget]
    Cost --> Chargeback[Chargeback/showback]
    Cost --> Forecast[Forecast]
    Cost --> Portfolio[Portfolio decision]

Finance needs workload-level cost, not just provider invoices. Cost records should link to project, user, target, evidence class, and outcome quality.

Customer-facing integration

Diagram loads as you read

Customer-facing integration · Figure 10

View diagram source

flowchart LR
    Pilot[Customer pilot] --> Contract[Evidence contract]
    Contract --> Run[Approved runs]
    Run --> Review[Claim review]
    Review --> Report[Customer report]
    Report --> CRM[Customer-success system]

Customer reports should not be hand-built from notebook screenshots. They should be generated from evidence packages and claim reviews.

Architecture review board

Diagram loads as you read

Architecture review board · Figure 11

View diagram source

journey
    title Quantum architecture review
    section Intake
      New use case: 3: Product
      Data classification: 4: Security
    section Design
      Target class: 4: Platform
      Evidence contract: 5: Research
      Cost envelope: 4: FinOps
    section Decision
      Approve pilot: 4: Review board
      Record ADR: 5: Architect

Architecture review should answer:

why quantum is being used;
what classical baseline is required;
what evidence level applies;
what target class is allowed;
what data and cost constraints apply;
how the result will be consumed.

Integration maturity

Diagram loads as you read

Integration maturity · Figure 12

View diagram source

flowchart LR
    AdHoc[Ad hoc notebooks] --> Shared[Shared tooling]
    Shared --> Brokered[Brokered platform]
    Brokered --> Governed[Governed enterprise capability]
    Governed --> Productized[Productized service]

A quantum platform becomes enterprise-ready when it can be used without bypassing enterprise controls.