Shopify Agentur finden: Architektur-orientierte Auswahl und technische Evaluation

Problem Statement

```mermaid graph LR A[Input] --> B[Process] B --> C[Output] ``` ```typescript // Configuration Example export const config = { environment: 'production', apiEndpoint: 'https://api.example.com', timeout: 5000, retries: 3 }; ```

„Shopify Agentur finden“ klingt operativ. In der Praxis ist es ein Architektur-Problem. Viele Unternehmen wählen nach Design-Portfolio oder Tagessatz. Und übersehen die Systemarchitektur. Das Ergebnis: instabile Integrationen, langsame Storefronts, fehlerhafte Datenflüsse, eskalierende Betriebskosten und ein Vendor-Lock-in, der jede Änderung teuer macht.

Die richtige Shopify Agentur ist kein „Theme-Bauer“. Sie ist ein Engineering-Partner. Sie muss Ihre Zielarchitektur verstehen. Sie muss Shopify-spezifische Constraints in eine saubere Integrationsarchitektur übersetzen. Sie muss messbar liefern. Und sie muss den Betrieb danach beherrschbar machen.

In diesem Guide definieren wir technische Auswahlkriterien. Architektur-orientiert. Mit Abnahmekriterien. Mit Artefakten, die Sie im Pitch wirklich prüfen können.

Technical Background

Shopify ist kein monolithisches Shopsystem, das Sie beliebig „umbauen“. Shopify ist ein SaaS-Kern. Erweiterungen passieren über klar definierte Schnittstellen: Themes/Storefront, Apps, Admin-API, Webhooks, Flow, Functions (abhängig vom Plan/Setup) und externe Systeme wie ERP, PIM, OMS, CRM, DWH.

Das führt zu einer zentralen Frage bei der Agenturauswahl: Wie entwirft die Agentur die Integrations- und Datenarchitektur um Shopify herum? Nicht: „Welche App installieren wir?“. Sondern: „Welches Zielbild ist robust, auditierbar und skalierbar?“

Ein typisches Architektur-Zielbild sieht so aus. Shopify bleibt Source of Truth für Orders und Checkout-nahe Daten. PIM bleibt Source of Truth für Produktdaten. ERP für Buchhaltung und Lagerbewertung. DWH für Reporting. Die Agentur muss diese Grenzen respektieren. Und die Synchronisation sauber designen.

flowchart LR
  A[Storefront / Theme] -->|Checkout & Cart| S[(Shopify Core)]
  S -->|Admin API| I[Integrationsservice]
  S -->|Webhooks| I
  I --> P[PIM]
  I --> E[ERP]
  I --> O[OMS / Versand]
  I --> D[(Data Warehouse)]
  I --> Q[(Queue / Event Bus)]
  Q --> I
  P -->|Produktdaten| S
  E -->|Bestand, Preise (falls ERP führend)| S
  D -->|BI / Reporting| B[Analytics]

Bei der Agenturevaluation prüfen Sie daher nicht nur „Funktionalität“, sondern Architektur-Eigenschaften:

Kriterium	Warum relevant	Mess- / Prüfpunkt
Integrationsmuster	Verhindert Punkt-zu-Punkt-Chaos	Event-getrieben, Idempotenz, Retry-Strategie dokumentiert
Datenhoheit (SoT)	Reduziert Konflikte	Matrix „System → Datenbereich → SoT“ vorhanden
Performance	Conversion und SEO	LCP/INP-Ziele, Liquid/JS-Budget, Bild-Pipeline
Sicherheit	Token, PII, Compliance	Secrets-Management, RBAC, Audit-Logging, DSGVO-Prozesse
Betriebsmodell	Stabilität nach Go-Live	SLOs, On-Call/Incident, Monitoring, Runbooks
Teststrategie	Regressionen vermeiden	Contract-Tests für Webhooks/APIs, E2E Smoke Tests

Wichtig: „OTHER“ als Plattform-Strategie bedeutet hier. Wir bleiben Shopify-fokussiert. Wir erwähnen andere Systeme nur als Integrationspartner. Kein Plattform-Wechsel. Keine alternativen Shop-Engines als Vergleich.

Implementation Steps

Die Auswahl einer Shopify Agentur ist ein technischer Prozess. Sie brauchen ein minimales Architektur-Lastenheft. Und eine strukturierte Evaluation. Unten ein Ablauf, der in der Praxis funktioniert.

1) Zielarchitektur als Auswahlfilter definieren

Formulieren Sie Ihr Zielbild in 1–2 Seiten. Kein Roman. Aber präzise. Mit folgenden Punkten:

Artefakt	Inhalt	Warum es Agenturen trennt
Systemkontext	Shopify + ERP/PIM/OMS/CRM/DWH	Agenturen müssen Integrationsfähigkeit beweisen
NFRs	Performance, Verfügbarkeit, RPO/RTO	Engineering-Reife sichtbar
SoT-Matrix	Wer „besitzt“ welche Daten?	Reduziert spätere Konflikte
Risiko-Liste	PII, Rate Limits, Peak Load	Erfahrung im Betrieb erkennbar

2) RFP als Architektur-Test aufbauen

Schreiben Sie keine „Feature-Liste“ als RFP. Schreiben Sie Architektur-Fragen. Beispiel-Fragen:

• Wie wird Webhook-Processing idempotent umgesetzt?
• Wie gehen Sie mit Shopify API Rate Limits um?
• Welche Observability-Standards liefern Sie (Logs, Metrics, Tracing)?
• Wie sieht Ihr Rollback-Plan für Theme-Deployments aus?
• Wie definieren Sie Ownership zwischen Agentur und Inhouse-Team?

3) Technische Due Diligence im Pitch: Live-Review statt Folien

Fordern Sie konkrete Artefakte. Keine Marketing-Slides. Minimal-Set:

• Beispiel-Repo (redacted) mit TypeScript/Node oder bevorzugtem Stack
• Beispiel eines Runbooks (Incident: Webhook-Backlog, Payment-Failures)
• Beispiel eines Architektur-Decision-Records (ADR)
• CI/CD-Pipeline-Screenshot oder YAML-Ausschnitt

4) Integration Design Review: Referenz-Use-Case erzwingen

Wählen Sie einen realen, kritischen Use-Case. Beispiel: „Order created → ERP → Fulfillment → Tracking zurück nach Shopify“. Die Agentur muss Datenflüsse, Fehlerpfade und Retries erklären. Ohne Nebel.

Ein typisches Beispiel für eine robuste Webhook-Verarbeitung zeigt der folgende TypeScript-Ausschnitt. Fokus: Signaturprüfung, Idempotenz-Key, Queueing, Retry-Sicherheit.

import crypto from "crypto";

type WebhookEvent = {
  topic: string;
  shopDomain: string;
  webhookId: string; // Shopify-Webhook-Header (oder aus Payload ableiten)
  payload: unknown;
  hmacHeader: string;
  rawBody: Buffer;
};

function verifyShopifyHmac(rawBody: Buffer, hmacHeader: string, secret: string): boolean {
  const digest = crypto
    .createHmac("sha256", secret)
    .update(rawBody)
    .digest("base64");

  // Timing-safe compare
  const a = Buffer.from(digest);
  const b = Buffer.from(hmacHeader);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

export async function handleWebhook(
  evt: WebhookEvent,
  deps: {
    secret: string;
    isProcessed: (id: string) => Promise<boolean>; // idempotency store
    markProcessed: (id: string) => Promise<void>;
    enqueue: (job: { key: string; topic: string; payload: unknown }) => Promise<void>;
  }
) {
  if (!verifyShopifyHmac(evt.rawBody, evt.hmacHeader, deps.secret)) {
    throw new Error("Invalid HMAC");
  }

  // Idempotenz: gleiche Events dürfen keine Doppelbuchungen erzeugen.
  const idempotencyKey = `${evt.shopDomain}:${evt.topic}:${evt.webhookId}`;
  if (await deps.isProcessed(idempotencyKey)) {
    return { status: 200, body: "Already processed" };
  }

  // Entkopplung: Verarbeitung asynchron in Queue.
  await deps.enqueue({ key: idempotencyKey, topic: evt.topic, payload: evt.payload });
  await deps.markProcessed(idempotencyKey);

  return { status: 202, body: "Accepted" };
}

5) Datenmodell und Reporting: DWH-Extrakt definieren

Viele Shopify-Projekte scheitern „leise“ im Reporting. Orders, Refunds, Discounts, Taxes. Das ist kein Excel-Thema. Das ist Datenmodellierung. Die Agentur muss einen belastbaren Extrakt liefern. Inkrementell. Reproduzierbar.

Ein typisches Beispiel für eine schlanke ELT-Stufe ist der folgende Python-Job. Er lädt Orders inkrementell (updated_at), normalisiert und schreibt in ein DWH-Staging. Details wie Pagination und Rate-Limit-Handling sind bewusst angedeutet. Die Logik muss jedoch vorhanden sein.

import os
import time
import requests
from datetime import datetime, timezone

SHOP = os.environ["SHOPIFY_SHOP"]
TOKEN = os.environ["SHOPIFY_TOKEN"]
API_VERSION = "2024-07"


def fetch_orders(updated_at_min: str):
    url = f"https://{SHOP}/admin/api/{API_VERSION}/orders.json"
    headers = {"X-Shopify-Access-Token": TOKEN}
    params = {
        "status": "any",
        "limit": 250,
        "updated_at_min": updated_at_min,
        "order": "updated_at asc",
    }

    while True:
        r = requests.get(url, headers=headers, params=params, timeout=30)
        r.raise_for_status()
        data = r.json().get("orders", [])
        for o in data:
            yield o

        # Pagination: Shopify liefert Link-Header. Hier nur schematisch.
        next_link = r.links.get("next", {}).get("url")
        if not next_link:
            break
        url = next_link
        params = None

        # Rate-Limit: Backoff, wenn nötig (vereinfachtes Beispiel)
        time.sleep(0.2)


def normalize_order(o: dict) -> dict:
    return {
        "order_id": o["id"],
        "order_number": o.get("order_number"),
        "currency": o.get("currency"),
        "total_price": float(o.get("total_price", "0")),
        "financial_status": o.get("financial_status"),
        "fulfillment_status": o.get("fulfillment_status"),
        "created_at": o.get("created_at"),
        "updated_at": o.get("updated_at"),
        "customer_id": (o.get("customer") or {}).get("id"),
    }


def run(updated_at_min: str):
    rows = []
    for o in fetch_orders(updated_at_min=updated_at_min):
        rows.append(normalize_order(o))

    # Hier: Insert in Staging (z.B. via COPY oder Batch-Insert).
    # In der Agentur-Bewertung prüfen: Idempotenz, Upserts, Schema-Evolution.
    return rows


if __name__ == "__main__":
    ts = (datetime.now(timezone.utc).replace(hour=0, minute=0, second=0, microsecond=0)).isoformat()
    out = run(updated_at_min=ts)
    print(f"rows={len(out)}")

6) Abnahmekriterien: technisch, messbar, unterschreibbar

Gute Agenturen akzeptieren harte Abnahmekriterien. Schlechte diskutieren „Gefühl“. Definieren Sie eine Abnahmematrix:

Bereich	Kriterium	Messung	Abnahme
Storefront	LCP < 2.5s (P75) auf Key-Templates	RUM + Lab	Go/No-Go
Integration	Webhook-Consumer idempotent	Replay-Test (1000 Events)	Keine Duplikate
Data	Order-Export inkrementell und reproduzierbar	Backfill + Delta	Reconciliation < 0.1%
Ops	Monitoring + Alerting produktiv	Test-Incident	MTTA < 10 min

Best Practices

Hier sind Best Practices, die bei der Agentur-Auswahl und der späteren Zusammenarbeit wirklich zählen. Technisch. Nicht kosmetisch.

1) Architektur-Entscheidungen schriftlich: ADRs

Jede relevante Entscheidung braucht einen ADR. Kurz. Versioniert. Prüfen Sie, ob die Agentur ADRs routinemäßig nutzt. Ohne ADRs: spätere Diskussionen ohne Faktenbasis.

2) Rate-Limits und Bulk-Strategien sind Pflicht

Shopify APIs haben Limits. Das ist normal. Die Architektur muss damit umgehen: Backoff, Queue, Bulk-Operationen wo möglich, Delta-Sync statt Vollsync. Fragen Sie explizit nach dem „Rate-Limit Playbook“.

3) Datenkonsistenz: Reconciliation Jobs

Webhooks sind nicht „genug“. Sie können verloren gehen. Sie kommen in falscher Reihenfolge. Sie brauchen periodische Reconciliation. Das ist keine Paranoia. Das ist Betrieb.

Ein typisches Beispiel für Reconciliation im DWH ist die folgende SQL-Prüfung. Sie vergleicht Shopify-Orders im Staging mit ERP-Orders und markiert Abweichungen.

-- Beispiel: tägliche Reconciliation zwischen Shopify-Staging und ERP-Faktentabelle
-- Annahme: beide Systeme schreiben eine kanonische order_id (Shopify ID) oder mapping.

WITH shopify AS (
  SELECT
    order_id,
    MAX(updated_at) AS last_update,
    SUM(total_price) AS total_price
  FROM dwh_staging.shopify_orders
  WHERE updated_at >= CURRENT_DATE - INTERVAL '2 days'
  GROUP BY order_id
),

erp AS (
  SELECT
    shopify_order_id AS order_id,
    MAX(updated_at) AS last_update,
    SUM(gross_amount) AS total_price
  FROM dwh_core.erp_orders
  WHERE updated_at >= CURRENT_DATE - INTERVAL '2 days'
  GROUP BY shopify_order_id
)

SELECT
  COALESCE(s.order_id, e.order_id) AS order_id,
  s.total_price AS shopify_total,
  e.total_price AS erp_total,
  CASE
    WHEN s.order_id IS NULL THEN 'missing_in_shopify'
    WHEN e.order_id IS NULL THEN 'missing_in_erp'
    WHEN ABS(s.total_price - e.total_price) > 0.01 THEN 'amount_mismatch'
    ELSE 'ok'
  END AS status
FROM shopify s
FULL OUTER JOIN erp e
  ON s.order_id = e.order_id
WHERE
  s.order_id IS NULL
  OR e.order_id IS NULL
  OR ABS(s.total_price - e.total_price) > 0.01;

4) Theme- und Code-Qualität: Budgets und Guardrails

Storefront-Performance ist ein Budget-Thema. Sie brauchen Guardrails:

• JS-Budget pro Template
• Keine unkontrollierten Third-Party-Skripte
• Bildoptimierung und Lazy-Loading Regeln
• Release-Prozess mit Canary/Preview-Umgebungen

5) Sicherheitsmodell: Token, PII, Zugriff

Agenturen arbeiten oft mit temporären Tokens. Das ist gefährlich, wenn es unsauber gemacht wird. Prüfen Sie:

• Secrets nur in Vault/Secret Manager, nie in Repos oder Tickets
• Least Privilege bei API-Scopes
• Trennung von Dev/Staging/Prod
• Logging ohne PII (Redaction)

6) Betriebsübergabe: Runbooks und SLOs

Go-Live ist kein Ende. Es ist der Beginn des Betriebs. Eine gute Shopify Agentur liefert:

• Runbooks: „Webhook-Backlog“, „ERP Down“, „Fulfillment stuck“
• SLOs: z.B. „99.9% Webhook processing success“
• Alarmregeln und Dashboards
• Post-Go-Live Hypercare Plan

Real-World Example

Szenario. D2C-Brand. Shopify als Commerce-Kern. ERP führt Bestand. PIM führt Produktdaten. Ziel: stabile Integrationen, sauberes Reporting, Peak-Load-resistent (Kampagnen).

Architektur-Setup

Domäne	System of Truth	Synchronisationsrichtung	Mechanismus
Produktstammdaten	PIM	PIM → Shopify	Batch + Delta, Validierung
Bestand	ERP	ERP → Shopify	Near-real-time, throttled
Orders	Shopify	Shopify → ERP/OMS	Webhooks → Queue → Worker
Tracking	OMS/Versand	OMS → Shopify	API update + Retry
Reporting	DWH	Alle → DWH	ELT + Reconciliation

Agentur-Evaluation anhand eines technischen Workshops

Sie lassen zwei Agenturen denselben Workshop durchführen. 90 Minuten. Whiteboard. Danach liefern sie eine 1-seitige Architektur-Skizze und eine Risiko-Liste.

• Agentur A schlägt Punkt-zu-Punkt-Integrationen vor. Ohne Queue. Ohne Reconciliation. „Webhooks reichen.“
• Agentur B schlägt Queue + Idempotenz + Dead-Letter-Handling vor. Sie benennt Rate-Limits. Sie definiert ein Backfill-Verfahren.

Ergebnis: Agentur B ist teurer. Aber billiger im Betrieb. Und schneller bei Änderungen, weil die Architektur entkoppelt ist.

Abnahme: messbare Checks

Sie definieren vor Vertragsabschluss technische Checks. Damit vermeiden Sie spätere Diskussionen.

Check	Testmethode	Erwartung
Webhook Replay	1000 Events erneut zustellen	0 doppelte ERP-Buchungen
ERP Downtime	ERP 30 Minuten offline	Queue puffert, kein Datenverlust
Peak Load	Lasttest auf Storefront + API	SLOs eingehalten, kein Timeout-Sturm

Wenn Sie im letzten Schritt eine Shortlist haben. Dann ist ein Soft-CTA legitim: Fordern Sie von der Agentur einen „Architecture Readiness Report“ als bezahlten Mini-Engagement (z.B. 2–5 Tage). Das ist kein Verkaufstrick. Es ist ein Engineering-Filter. Gute Agenturen liefern dabei Substanz. Schlechte nicht.

Optional, wenn Sie intern schnell standardisieren wollen: Definieren Sie einen Scorecard-Prozess. Bewertet werden Artefakte, nicht Meinungen. Nutzen Sie fixe Gewichtungen (z.B. Integration 30%, Performance 20%, Ops 20%, Security 15%, Delivery 15%).