Data-as-a-Service «at scale»: Warum gängige Datenplattformen allein nicht ausreichen

Datenplattformen wie Microsoft Fabric, Databricks oder Snowflake haben den Aufbau moderner Dateninfrastrukturen um einiges erleichtert. Im Gegensatz zu früheren PaaS-Ansätzen hat sich die Fertigungstiefe deutlich verringert, was den Time-to-Market stark reduziert. 

Doch für Data-as-a-Service «at scale», insbesondere in der hochregulierten Welt des Banking, braucht es mehr: eine hochautomatisierte Self-Service-Funktionalität, die die darunterliegende Komplexität abstrahiert, und eine Governance, die als Enabler wirkt statt als Bremse. 

Beides bringt auch heute noch einiges an Individualentwicklung mit sich. Wir zeigen die Herausforderungen auf und wie sich die Lücke schliessen lässt. 

Die Motivation: Daten müssen raus aus dem Silo, rein in den Wertschöfungsprozess

Wer die Chancen von KI, Open Finance oder Cloud nutzen will, muss zuerst sein Datenfundament sanieren. Solange Daten in Silos zwischen Core-Banking, CRM und einzelnen Saas-Applikationen gefangen sind, bleibt Data-Driven Banking ein Schlagwort. Genau diese Botschaft von Branchenexpert:innen wird in unserem aktuellen Paper «Top Tech Trends im Schweizer Banken- und Finanzwesen 2026» deutlich.

In der Praxis bedeutet das: Ein:e Kundenberater:in sollte per Knopfdruck eine 360°-Sicht (KYC-Status, Transaktionen, Depotstruktur) erhalten, während das Riskmanagement für das ESG-Reporting auf konsolidierte, qualitätsgeprüfte Datenströme zugreift, ohne jedes Mal ein IT-Projekt starten zu müssen.

Das strategische Ziel ist klar: Daten sollen nicht länger ein Nebenprodukt einzelner Systeme sein, sondern als eigenständiges Produkt behandelt werden. Dazu gehören definierte Qualitätsstandards, ein Data Owner, klare Governance und die richtigen Werkzeuge, um die Plattform im Self-Service-Modus durch das Business bewirtschaften und für Systeme und Agenten zugänglich machen zu können. Immer unter Einhaltung der Governance.

Die Lücke: Zwischen Plattform und Business-Nutzen

Moderne SaaS-Datenplattformen liefern viel Funktionalität von der Stange. Doch für die Bewirtschaftung «at scale» braucht es neben der technologischen Basis, auch den Zugang zum Business-Nutzer. 

Ein Datenprodukt besteht aus vielen Elementen, die über den gesamten Lifecycle hinweg,  von der Erstellung über den laufenden Betrieb bis hin zu Archivierung und Löschung, konsistent aktualisiert werden müssen:

1. Die Daten selbst, abgebildet in Form von Storage-Formaten (Parquet-Files, Delta-Tables etc.) sowie logischen Strukturen (Tabellen, Views, Schemas etc.). 
2. Metadaten zu Ownership und Verantwortung, Datenklassifizierungen, Data Contracts, Schema-Informationen, Beschreibung der Semantik, Verknüpfung zum Geschäftsmodell, Verwendungszweck, Lineage, Versionen und Changelog.
3. Verarbeitungslogik in Form von Pipelines, Notebooks und Triggers, inklusive kaskadierter Aktualisierung abhängiger Downstream-Datenprodukte etc.
4. Output-Ports in Form von Reports, Analytics-Endpoints und/oder kuratierten Daten für Konsument:innen und Downstream Datenprodukten.
5. Governance- und IAM-Integration, um bestehende Freigabeprozesse zu nutzen und einen sauberen Audit-Trail für Datenfreigaben zu führen.
6. Discoverability, z.B. über einen Datenkatalog, damit das Datenprodukt und seine Output-Ports von potenziellen Konsument:innen gefunden und genutzt werden können.

Der letzte Schritt bis zum Business-Nutzer ist jedoch steinig: 

1. Fehlender Self-Service: Fachabteilungen können Datenprodukte nicht ohne tiefe IT-Kenntnisse definieren oder beziehen.
2. Governance als Bremse: Manuelle Freigabeprozesse und unklare Verantwortlichkeiten verzögern die Bereitstellung um Wochen.
3. Mangelnde Transparenz: Es fehlt oft an einem zentralen Katalog, der zeigt, welche Datenprodukte «ready for audit» sind.

In der Praxis wird die Lücke deshalb behelfsmässig geschlossen, mit einer Kombination aus Tickets (die von einem zentralen Team abgearbeitet werden), Scripts und manuellen Schritten, was zu Abhängigkeiten und Inkonsistenz führt.

Self-Service-Plattform Dragonfly: Die Lücke schliessen – ein Praxisbericht

Genau hier setzt Dragonfly an. Gemeinsam mit einem Kunden aus einem stark regulierten Umfeld haben wir genau diese Herausforderung adressiert. 

Das Ergebnis ist eine Self-Service-Plattform, die über der bestehenden Datenplattform des Kunden liegt, den gesamten Lebenszyklus von Datenprodukten abdeckt und dabei Governance konsequent durchsetzt, ohne als Bremse zu wirken.

Was Dragonfly für den Finanzsektor auszeichnet:

• IAM-Integration mit bestehenden Approval-Prozessen: Dragonfly nutzt die bestehenden Berechtigungs- und Genehmigungsworkflows des Kunden. Statt ein paralleles Governance-System aufzubauen, fügt sich die Plattform in das vorhandene IAM ein. Der Fokus liegt auf Enablement statt Verhinderung, bei gleichzeitiger Einhaltung der Governance.
• Logische Data-Lineage mit interaktiver Navigation: Anstatt nur eine technische Lineage auf Ebene von Tabellen und Views zu zeigen, bildet Dragonfly die Abhängigkeiten entlang logischer Datenprodukte und Output-Ports ab. Das macht Datenflüsse auch für Fachbereiche nachvollziehbar, nicht nur für Data Engineers.
• Data Residency & Souveränität: Die Daten verlassen die Hoheit der Bank nicht. Dragonfly orchestriert, aber die Speicherung erfolgt gemäss den strengen Schweizer Compliance-Vorgaben auf der eigenen Infrastruktur. 
• Lifecycle Management: Dragonfly unterstützt den gesamten Lebenszyklus von Datenprodukten, von der Erstellung über die Veröffentlichung bis hin zu Archivierung und Löschung.
• Laufende Aktualisierung: Business-Nutzer konfigurieren Trigger für Aktualisierungszyklen selbstständig. Abhängige Downstream-Produkte werden automatisch nachgezogen, was die Konsistenz für das regulatorische Reporting garantiert.
• FINMA- und BAG-konform: Jede Datenbewegung und jede Logikänderung wird lückenlos protokolliert. Dies reduziert den Vorbereitungsaufwand für FINMA-Audits von Wochen auf Stunden.

Maximale Datensouveränität und Exit-Fähigkeit per Design

Ein zentrales Designprinzip von Dragonfly ist die Plattformunabhängigkeit. Für Banken ist dies aufgrund der regulatorisch geforderten Exit-Strategien essenziell: Die Daten, Tabellen und Verarbeitungslogik (Pipelines, Jobs) liegen ausschliesslich auf den Datenplattformen der Kund:innen. 

Dragonfly orchestriert und bewirtschaftet, aber die Daten werden auf der bestehenden Datenplattform der Kund:innen gespeichert. Die Bank behält jederzeit die volle Souveränität über ihre strategischen Daten-Assets, da Dragonfly lediglich bewirtschaftet, aber keinen proprietären Lock-in erzeugt.

Das bedeutet: Wenn Dragonfly nicht mehr bezogen wird, sind alle Artefakte, Tabellen, Pipelines, Reports, nach wie vor vorhanden und lauffähig. Kein Lock-in.

Ausblick: Agent-Ready Data als Basis für die Bank der Zukunft

Das Versprechen von Data-as-a-Service wird erst dann real, wenn Daten als qualitätsgesichertes, governiertes und einfach konsumierbares Produkt (Self-Service) vorliegen. Wer diese Lücke zum Business-Nutzer nicht schliesst, wird Data-as-a-Service zwar aufbauen können, aber nicht in der Breite skalieren. Und spätestens bei der nächsten Welle der Automatisierung scheitern: KI-Agenten.

Ob ein Large Language Model im Wealth Management komplexe Portfolios analyisert oder ein Agent im Retailbanking die Front entlastet: Die KI ist nur so sicher wie die Datenbasis, die sie konsumiert. 

Dragonfly stellt sicher, dass KI-Systeme nur auf autorisierte, governierte Daten zugreifen. Dies ermöglicht in einem ersten Schritt ein echtes Data-Driven Banking, bei dem jede Entscheidung auf verlässlichen Fakten basiert, und schafft so die notwendige Vertrauensbasis für die nächste Stufe: das Automated Banking.

Mit Dragonfly schliessen wir genau diese Lücke: Daten verlassen das Silo und werden im Self-Service durch das Business bewirtschaftet. Und das alles unter konsequenter Einhaltung der Governance. 

Ab Q3 2026 ist Dragonfly auch für andere Unternehmen verfügbar.