• Edge-zu-Core-Pfade testen: Stromausfall, Netzwerkflaps, Uhrzeit-Drift. Store-and-Forward mit Idempotenz und Deduplizierung; Checksummen prüfen, bevor Daten „gold“ werden.

Harte Trade-offs, die Sie bewusst treffen sollten

  • Zentralisierung vs. Autonomie:
  • Zu viel Zentralisierung erstickt Domänenexpertise.
  • Zu viel Autonomie wird teuer in Sicherheit, Monitoring und Duplicate Work.
  • Lösung: Starke, schlanke Plattform; klare Produktverträge; wenige, harte „Non-Negotiables“ (Identity, Encryption, Logging).
  • Governance vs. Geschwindigkeit:
  • Keine Governance ist schnell – einmalig. Beim dritten Incident verlieren Sie mehr Zeit.
  • Automatisieren Sie Governance: Policies als Code, Reviews in Git, Tests in CI, Self-Service-Templates.
  • Eine Technologie vs. Polyglott:
  • Ein Stack ist einfacher zu betreiben, aber nicht jedes Problem ist SQL. Erlauben Sie Spark/Flink dort, wo sinnvoll – aber standardisieren Sie Schnittstellen und Artefaktformate.
  • On-Prem vs. Cloud:
  • Cloud beschleunigt PoCs, aber Datenabfluss, SLA-Abhängigkeit und Rechtssicherheit sind in vielen Industrien inakzeptabel.
  • On-Prem braucht Disziplin im Betrieb. Setzen Sie auf wiederholbare Automatisierung, Monitoring und klare SRE-Praktiken.

LLM in der Industrie: Observability und Governance sind kein „Nice-to-have“

Sobald LLMs in Prozesse greifen (z. B. Störungstickets vorschreiben, Wartungsanweisungen zusammenfassen, Procurement-Assistenz), entstehen neue Datenflüsse: Prompts, Kontexte (Dokumente), Outputs, Tool-Nutzung. Technische Anforderungen aus Projekten:

  • Prompt-/Kontext-Logging on-prem, mit selektiver PII-Redaktion vor Persistenz.
  • Policies: Welche Quellen dürfen eingeblendet werden? Welche Werk-/Personendaten sind tabu?
  • Auditierbarkeit: Wer hat welches Ergebnis auf Basis welcher Wissensstände wann erhalten?
  • Drift- und Sicherheits-Monitoring: Erkennen von Halluzinationen, Prompt-Injection, Datenabfluss.

Ein dediziertes Observability- und Governance-System für LLM-Agenten hilft, diese Anforderungen umzusetzen – integriert in Ihre Dateninfrastruktur, nicht als SaaS außerhalb Ihrer Kontrolle.

Migration: Von „aktueller Zustand“ zu „zielarchitektur“

  • Bewahren, was trägt: Ihr bestehendes Warehouse bleibt das Herz für BI. Ergänzen Sie daneben ein Lakehouse für Roh-/ML-Daten. Führen Sie langsam „gold“-Datasets aus dem Lakehouse als Marts ins Warehouse.
  • Datenverträge einführen: Starten Sie mit 3–5 kritischen Datasets. Schreiben Sie Schemata, Qualitäts-Checks, SLAs nieder und setzen Sie sie in CI/CD durch.
  • Streaming dort, wo es Mehrwert bringt: Beginnen Sie mit CDC aus ERP/MES, um Replikationslatenzen zu reduzieren; erweitern Sie schrittweise.
  • Pilot-Mesh: Zwei Domänen, ein gemeinsames Datenprodukt. Ziel: Verantwortlichkeit einüben, Plattform-Lücken finden, ohne das Haus zu zerlegen.
  • LLM-Governance früh bedenken: Auch wenn Sie heute nur RAG auf internen Richtlinien testen – bauen Sie observierbar, auditierbar und auf on-prem Vektor-/Metadatenspeichern.

Antipatterns, die wir häufig ausbügeln

  • Mesh ohne Plattform: „Jede Domäne macht’s selbst“ endet in fünf Security-Standards, zehn Katalogen und null Interoperabilität.
  • Bilder im Warehouse parken: Sie zahlen Speicher doppelt und machen ML langsam. Bilder gehören in den Lake, mit Referenzen im Warehouse.
  • Keine Versionierung/Time Travel: Wenn Trainingsdaten nicht fixierbar sind, sind Modelle nicht reproduzierbar. ACID-Tabellenformat ist Pflicht.
  • Externe SaaS für Telemetrie/Logs in streng regulierten Umgebungen: Datenabfluss ist ein Audit-Fail. Observability gehört on-prem.
  • Governance im Confluence-Dokument: Policies müssen durchgesetzt werden – in Code und im Access Layer.

Konkrete Minimal-Setups je Muster

  • Minimal tragfähiges Warehouse-Setup:
  • Postgres/ClickHouse als analytische Engine (on-prem), CDC-Feeds aus ERP/MES, ETL mit Airflow, SCD2 im Core, Marts pro Domäne, BI-Tool on-prem.
  • Minimal tragfähiges Lakehouse-Setup:
  • MinIO/Ceph, Iceberg-Tabellen, Trino für Ad-hoc SQL, Spark für ETL/Backfills, Flink für Stream-to-Lake, OpenMetadata + OpenLineage, Great Expectations im CI.
  • Minimal tragfähiges Mesh-Setup:
  • Obiges Lakehouse als Plattform, plus: GitOps-Repos pro Data Product, OIDC + OPA Policies, Self-Service-Templates, Mandantenfähiger Katalog, domänenspezifische On-Call-Rotation.

Fazit

Es gibt keine eine, richtige Architektur. In der Industrie landen wir oft bei einem hybriden Modell: Warehouse für „eine Wahrheit“ in KPIs und Regulatorik, Lakehouse als Arbeitsbereich für ML und Rohdaten, Mesh als Organisationskappenschicht, wenn mehrere Domänen nachhaltig beitragen sollen. Entscheidend ist, dass Sie Governance, Reproduzierbarkeit und Souveränität von Anfang an in die Technik gießen – nicht als späteres Kontrollgremium. Wir bauen Systeme dort, wo die Daten entstehen, und halten die Kontrolle über Infrastruktur, Metadaten und Observability. Erst dann entfaltet KI in der Industrie ihren Wert – belastbar, auditierbar und ohne Lock-in.

FAQ

  • Muss ich mich für eines entscheiden – Warehouse, Lakehouse oder Mesh?
  • Nein. In vielen Industrieumgebungen ist eine Kombination sinnvoll: Warehouse für BI/KPIs, Lakehouse für ML/Rohdaten. Mesh ist eine Organisationsform, die Sie erst einführen, wenn Plattform und grundlegende Praktiken funktionieren.
  • Wie starte ich ein Data Mesh, ohne Bürokratiemonster zu erzeugen?
  • Beginnen Sie mit zwei Domänen und einem gemeinsamen Datenprodukt. Stellen Sie Self-Service-Plattform, Policies-as-Code, Katalog und CI/CD-Templates bereit. Vermeiden Sie Meetings als Governance-Mechanismus; erzwingen Sie Verträge und Tests in Pipelines.
  • Was mache ich mit bestehenden Historian-Systemen und proprietären SCADA-Formaten?
  • Nutzen Sie Edge-Connectoren, die Rohdaten in standardisierte, komprimierte Formate (Parquet) überführen und Metadaten anreichern. Replizieren Sie asynchron in ein Lakehouse. Halten Sie das Historian als „System of Record“, aber bauen Sie KI-Workloads auf dem Lake, nicht direkt auf dem Historian.
  • Wie sichere ich DSGVO-Compliance bei ML und LLM?
  • Pseudonymisieren Sie früh (Token-Vault), erzwingen Sie Zweckbindung über Access-Policies, loggen Sie Zugriffe manipulationssicher, planen Sie Löschketten über abgeleitete Datasets. Bei LLMs: On-Prem-RAG, Vektorstore lokal, automatische PII-Redaktion im Prompt-/Output-Logging und klare Freigabeprozesse für Wissensquellen.
  • On-Prem GPUs oder Cloud-Training?
  • Wenn Datenhoheit und Exportkontrollen kritisch sind, trainieren Sie on-prem. Nutzen Sie den Lakehouse-Storage als Datendrehscheibe, orchestrieren Sie Trainingsjobs über Kubernetes, versionieren Sie Artefakte. Cloud kann für synthetische, nicht sensible Daten nützlich sein, aber trennen Sie streng und vermeiden Sie Datenabfluss.