2  Overview

Quiver separates source extraction, customer-specific data staging, transformation, and application-serving environments. This keeps the source interface flexible while giving Quiver a stable internal mapping layer for planning, KPIs, and visualizations.

flowchart LR
  ERP["Customer APIs (ERP, BI etc.)"]
  FileExports["Customer File Exports"]
  Orchestrator["Quiver Orchestrator<br/>(schedules and monitors)"]
  QuiverTeam["Quiver Team"]

  subgraph CustomerInputs[" "]
    direction TB
    FileExports
    ERP
  end

  subgraph CustomerEnvironment["Customer Namespace i"]
    SFTP["Quiver-Managed SFTP"]
    Connector["Integration Connector & Extraction"]
    Staging[("Data Staging")]
    TransformProd["Transformation Layer"]
    FrontendProd["Quiver Frontend"]
  end

  style CustomerInputs fill:transparent,stroke:transparent

  FileExports -->|Push files| SFTP
  SFTP --> Connector
  ERP -->|Pull data| Connector
  Connector --> Staging
  Staging --> TransformProd
  TransformProd --> FrontendProd

  Orchestrator -.-> Connector
  Orchestrator -.-> TransformProd
  Orchestrator -->|Alerts| QuiverTeam

Figure 2.1: High-level integration architecture

2.1 Environments

From an integration perspective, Quiver normally receives production source data into a customer-specific production staging area. Quiver then runs at least two application environments: production and test. Each application environment has its own mapping layer from the staged source data, so Quiver can maintain production mappings separately from test mappings and can produce reduced or adjusted test datasets where needed.

Additional environments can be added when required for feature testing or implementation work. They use the same security and network model as the production environment.

flowchart LR
  Source["Production Source Data"]

  subgraph QuiverEnvironment["Customer Namespace i"]
    Staging[("Customer-Specific Staging DB")]
    MappingProd["Production Mapping Layer"]
    MappingTest["Test Mapping Layer"]
    MappingAdditional["Additional Mapping Layer, If Needed"]
    AppProd["Quiver Production"]
    AppTest["Quiver Test"]
    AppAdditional["Additional Test Environment"]
  end

  Source --> Staging
  Staging --> MappingProd --> AppProd
  Staging --> MappingTest --> AppTest
  Staging -. optional .-> MappingAdditional -. optional .-> AppAdditional

Figure 2.2: Default environment model

2.2 Components

Component	Responsibility	Operated By
Customer ERP / Source Systems	Provides source data through approved access paths	Customer
Customer BI / Data Warehouse	Provides curated or reporting-oriented data when this is the preferred source	Customer
Quiver-managed SFTP	Receives customer-delivered files for push-based integrations	Quiver
Integration Connector	Extracts source data from approved push or pull sources and applies connector-level normalization	Quiver
Quiver Orchestrator	Schedules and monitors synchronization jobs, transformation jobs, and operational alerts	Quiver
Data Staging	Stores raw and normalized integration data in the customer-specific environment	Quiver
Mapping / Transformation Layer	Applies customer-specific mapping and prepares curated data models for production and test environments	Quiver
Quiver Application Environments	Provide the customer-facing application experience for production and test environments	Quiver

2.3 Security Principles

The integration is designed and operated using standard security practices for business-critical data integrations.

Key principles include:

• Data traffic is encrypted in transit using secure protocols such as HTTPS, TLS-enabled database connections, or SFTP.
• Source-system access is limited to the approved systems, datasets, and environments required for the integration.
• Customer data is stored in customer-specific isolated infrastructure boundaries on Google Cloud, with default hosting in Germany.
• Access to production data is limited to authorized Quiver personnel with an operational need.
• Cloud infrastructure is operated in alignment with Google Cloud security recommendations for identity, access control, network configuration, and managed services.
• Data residency requirements are confirmed during onboarding and respected throughout the integration lifecycle.
• Customer-side filtering should be applied before delivery where required by the customer’s data governance model. Where approved, Quiver can also apply scope filtering in the mapping layer.