Du willst eine Datenplattform aufbauen und stehst vor der scheinbar großen Grundsatzfrage: Erst Infrastruktur, dann Use-Cases. Oder erst Use-Cases, dann Infrastruktur. Viele Teams entscheiden sich reflexartig für „Infrastruktur first“ und wundern sich Monate später, warum die Plattform zwar existiert, aber niemand sie wirklich nutzt. Die harte Wahrheit: Eine Datenplattform ist kein Selbstzweck. Sie ist ein Produkt, das messbar Nutzen liefern muss. Und der schnellste Weg dorthin ist in den meisten Unternehmen konsequent „Use-Case first“.
Hier ist der Kern: Wenn du deine Plattform entlang echter Anwendungsfälle entwickelst, baust du automatisch das, was gebraucht wird. Wenn du dagegen versuchst, im Voraus die perfekte Zielarchitektur zu definieren, optimierst du auf Annahmen. Das kostet Zeit, Geld und Vertrauen.
Use-Case first als primäres Prinzip beim Datenplattform-Aufbau
„Use-Case first“ heißt nicht, dass du planlos losläufst. Es heißt: Du startest mit einem konkreten Problem, das einen klaren Business-Owner hat, einen Nutzen verspricht und Datenanforderungen erzeugt. Aus diesen Anforderungen leitest du Plattformfähigkeiten ab.
Warum ist das so wirksam?
- Du bekommst sofort Prioritäten. Ein Use-Case zwingt dich zu Entscheidungen: Welche Datenquellen zuerst? Welche Aktualität? Welche Datenqualität? Welche Zugriffsrechte?
- Du reduzierst Architektur-Debatten. Viele Diskussionen lösen sich auf, wenn der Use-Case klar macht, was wirklich nötig ist.
- Du baust Vertrauen. Eine Plattform gewinnt Akzeptanz, wenn sie innerhalb weniger Wochen sichtbar hilft.
Wichtig: Use-Case first bedeutet nicht „Quick and dirty“. Es bedeutet „minimal, aber belastbar“. Du baust von Anfang an so, dass du erweitern kannst, aber du investierst erst dann in Komplexität, wenn sie durch reale Anforderungen gerechtfertigt ist.
So wählst du die richtigen Start-Use-Cases aus
Nicht jeder Use-Case eignet sich als Plattform-Startschuss. Gute Kandidaten haben typischerweise:
- Klare Entscheidung oder Prozessverbesserung als Ziel (z. B. Forecast, Anomalie-Erkennung, Reporting-Automatisierung).
- Greifbaren Datenbedarf, aber keine exotischen Sonderlocken.
- Einen Owner, der Zeit investiert, Feedback gibt und Ergebnisse abnimmt.
- Einen messbaren Wert, idealerweise in Euro, Zeit oder Risiko.
Hier ist der Punkt: Dein erster Use-Case ist weniger „der wichtigste“, sondern „der beste Hebel“, um Plattform-Grundlagen sinnvoll zu erzwingen.
Welche Entscheidungen dich überhaupt erst zu einer Datenplattform führen
Viele Unternehmen starten mit einzelnen BI-Berichten, Excel-Exports oder punktuellen ETL-Jobs. Das funktioniert, bis es nicht mehr funktioniert. Eine Datenplattform wird dann notwendig, wenn wiederkehrende Muster auftreten, die du mit Einzellösungen nicht mehr sauber beherrschst.
Typische Auslöser:
- Mehrere Teams brauchen dieselben Daten, aber in unterschiedlichen Formen.
- Datenqualität wird zum Problem, weil Definitionen variieren (z. B. „aktiver Kunde“ je nach Abteilung).
- Time-to-Insight ist zu langsam, weil Datenbeschaffung und Aufbereitung jedes Mal neu beginnt.
- Compliance und Zugriffskontrolle müssen nachvollziehbar werden.
- Skalierung: mehr Quellen, mehr Volumen, mehr Nutzer, mehr Use-Cases.
Warum ist das wichtig? Weil diese Auslöser direkt bestimmen, welche Plattformfähigkeiten du zuerst brauchst. Wenn dein Hauptproblem Governance ist, sieht dein Start anders aus, als wenn dein Hauptproblem Performance oder Datenintegration ist.
Die entscheidende Frage vor der Tool-Auswahl
Bevor du über Produkte nachdenkst, klärst du besser drei Dinge:
- Welche Datenprodukte sollen in den nächsten 3 bis 6 Monaten entstehen (konkret benannt)?
- Welche Nutzergruppen konsumieren sie (Analysten, Fachbereiche, Data Science, externe Partner)?
- Welche Betriebsanforderungen sind nicht verhandelbar (z. B. Datenresidenz, Rollenmodelle, Auditierbarkeit)?
Wenn du das nicht beantwortest, wird jede Tool-Diskussion zur Glaubensfrage. Mit Antworten wird sie zur Einkaufsentscheidung.
Infrastruktur first: Wann es Sinn ergibt und wann es dich ausbremst
Es gibt Situationen, in denen „Infrastruktur first“ gerechtfertigt ist, zum Beispiel:
- Du musst verbindliche Sicherheits- und Compliance-Standards etablieren, bevor irgendjemand produktiv arbeiten darf.
- Du migrierst aus einer Altlandschaft und brauchst eine stabile Zielumgebung, um überhaupt starten zu können.
- Du hast bereits mehrere Use-Cases in der Pipeline und brauchst eine gemeinsame Basis, damit Teams nicht parallel Wildwuchs erzeugen.
Aber: In vielen Mittelstands- und Produktorganisationen wird Infrastruktur first als „wir machen es richtig“ verkauft, bedeutet in der Praxis jedoch „wir liefern lange nichts Sichtbares“. Das ist gefährlich, weil Datenplattformen Vertrauen brauchen. Ohne frühe Erfolge wird die Plattform schnell als Kostenblock wahrgenommen.
Ein pragmatischer Mittelweg: Plattform-Skelett plus Use-Case-Rhythmus
Wenn du nicht in Extreme fallen willst, funktioniert oft dieser Ansatz:
- Minimaler Plattform-Kern (Identität, Zugriff, Basis-Logging, Standard-Storage, CI/CD-Grundlage).
- Ein Use-Case als Taktgeber, der die nächsten Fähigkeiten erzwingt (z. B. Ingestion, Transformation, Datenmodell, Serving).
- Jede Erweiterung wird an einem realen Bedarf begründet.
So entsteht eine Plattform, die sowohl sicher als auch nützlich wird, ohne monatelange Vorleistung.
Managed Lösungen wie Databricks: Wann sie dir Tempo geben und wann du aufpassen musst
Managed Plattformen (z. B. Databricks in der Cloud) versprechen: schneller starten, weniger Betriebsaufwand, moderne Komponenten aus einer Hand. Das kann ein echter Vorteil sein, vor allem wenn dein Team nicht primär eine Plattform betreiben, sondern Datenprodukte liefern soll.
Wofür managed Lösungen oft besonders gut sind:
- Schneller Produktivstart für Analytics, Engineering und Machine Learning.
- Skalierung ohne eigenes Cluster-Tuning.
- Standardisierte Umgebungen, die Teams schneller arbeitsfähig machen.
- Integrierte Governance- und Katalog-Funktionen (je nach Setup), die den Einstieg in Datenprodukte erleichtern.
Aber es gibt zwei typische Stolpersteine:
- Kostenkontrolle: Wenn du nicht früh ein FinOps-Mindset aufsetzt (Budgets, Alerts, Kostenstellen, Nutzungsrichtlinien), frisst dich der Komfort auf.
- Lock-in und Architektur-Disziplin: Managed heißt nicht automatisch „gute Architektur“. Du brauchst weiterhin klare Datenprodukt-Standards, Ownership und Schnittstellen.
Hier ist die Leitfrage: Bringt dir die Managed-Lösung messbar mehr Delivery-Geschwindigkeit als ein selbst betriebenes Setup, und zwar für deine konkreten Use-Cases? Wenn ja, ist das oft die bessere Entscheidung. Wenn nein, kaufst du Komplexität ein, die du nicht brauchst.
Datenplattform als Produkt denken: Ownership, Standards, Datenprodukte
Eine Datenplattform scheitert selten an Technologie. Sie scheitert an fehlender Klarheit: Wer entscheidet, was „richtig“ ist? Wer betreibt? Wer priorisiert? Wer trägt Verantwortung für Datenqualität?
Wenn du deine Plattform als Produkt führst, brauchst du mindestens:
- Produktverantwortung für die Plattform (Priorisierung, Roadmap, Stakeholder-Management).
- Klare Standards für Datenmodelle, Naming, Versionierung, Tests, Dokumentation.
- Datenprodukt-Ownership in den Fach- oder Domänenteams (wer ist verantwortlich für Definition und Qualität?).
- Ein einfaches Onboarding für neue Nutzer, inklusive Templates und „Happy Path“.
Warum das so entscheidend ist: Plattformen werden schnell zu „allen gehört es ein bisschen“. Dann gehört es in Wahrheit niemandem. Und dann wird es teuer, langsam und politisch.
Minimal-Standards, die du früh festlegen solltest
Du musst nicht alles am Anfang regeln. Aber diese Standards zahlen sich fast immer aus:
- Definition von „Source of Truth“ pro Kernentität (Kunde, Auftrag, Produkt).
- Rollen- und Rechtekonzept (wer darf was sehen, wer darf was ändern?).
- Qualitätschecks für kritische Tabellen (Nulls, Duplikate, Wertebereiche).
- Versionierung und Deployment-Prozess (auch für Datenpipelines).
- Dokumentation als Teil des Done (kurz, aber verpflichtend).
Das Ziel: weniger Reibung, weniger Diskussionen, weniger Überraschungen.
Der praktische Aufbauplan: In 6 Schritten zur tragfähigen Datenplattform
Wenn du morgen starten müsstest, ist dieser Ablauf ein robuster Plan, der in vielen Organisationen funktioniert:
1) Starte mit einem Use-Case, der Ergebnisdruck erzeugt
Wähle einen Anwendungsfall, der innerhalb von 4 bis 8 Wochen sichtbar Nutzen liefert. Kein „wir bauen erstmal das Fundament“.
2) Definiere das Datenprodukt
Was genau ist das Ergebnis? Eine Tabelle? Ein Dashboard? Eine API? Ein Feature im Produkt? Wer nutzt es, wie oft, wofür?
3) Baue die Ingestion minimal, aber wiederholbar
Lieber eine saubere Standard-Pipeline für 1 bis 2 Quellen als fünf Sonderlösungen.
4) Setze Transformationen mit Tests und Ownership auf
Baue Transformationen so, dass du sie verändern kannst, ohne Angst zu haben. Tests müssen nicht perfekt sein, aber vorhanden.
5) Etabliere Governance dort, wo Risiko ist
Beginne mit den sensiblen Daten, den wichtigen Kennzahlen und den breit genutzten Tabellen. Governance überall auf einmal lähmt.
6) Wiederhole den Zyklus mit dem nächsten Use-Case
Jeder neue Use-Case erweitert die Plattform gezielt. Du baust Fähigkeiten, weil sie gebraucht werden, nicht weil sie im Architekturdiagramm gut aussehen.
Was du ab sofort anders machen solltest (konkret)
- Formuliere deine Datenplattform als Nutzenversprechen: Welche 2 bis 3 Entscheidungen oder Prozesse werden in 90 Tagen besser?
- Setze einen Use-Case als Taktgeber und plane Plattformarbeit nur, wenn sie diesen Use-Case schneller, sicherer oder günstiger macht.
- Führe Plattform-Ownership ein (eine Person oder ein kleines Team mit echter Entscheidungsmacht).
- Lege Minimal-Standards fest, besonders für Source of Truth, Qualität und Deployment.
- Prüfe Managed Optionen wie Databricks anhand eines Kriteriums: Wie viel schneller liefert ihr damit Datenprodukte, ohne Kosten und Governance zu verlieren?
Wenn du diesen Ansatz durchziehst, wird deine Datenplattform kein Großprojekt, das irgendwann fertig sein soll. Sie wird ein System, das kontinuierlich Wert liefert und mit jedem Use-Case besser wird.
