Die meisten Tech-Unternehmen kämpfen nicht mit der Menge der Daten, sondern mit ihrer Verfügbarkeit und Vertrauenswürdigkeit. Daten liegen in einem Dutzend Systemen, jedes Team zählt den Umsatz auf eigene Weise, und der Bericht, der im Vorstand landet, ist eine von Hand zusammengeflickte Tabelle. An diesem Punkt geht es nicht mehr um ein weiteres Werkzeug, sondern um eine Datenplattform: ein über Jahre gepflegtes Fundament, auf dem Analytik, Produkt und Entscheidungen ruhen.
Aus unserer Erfahrung ist der schwierige Teil nicht die Wahl der Technologie, sondern sie zu einem stimmigen Ganzen zu verdrahten und am Laufen zu halten, während die Daten wachsen. Eine Referenz für die Datenplattform eines Tech-Unternehmens haben wir nicht im Portfolio, und wir tun auch nicht so. Was wir haben, sind Data- und Big-Data-Engineers, die Pipelines, Warehouses und Qualitätsschichten anderswo gebaut haben und die wir in Ihr Projekt einbinden.
Warum braucht ein Tech-Unternehmen eine Datenplattform?
Eine Datenplattform ist nicht bloß eine weitere Datenbank. Sie ist die Schicht, die Daten aus vielen Quellen sammelt, ordnet und aus einem vertrauenswürdigen Ort heraus bereitstellt. Ohne sie beantwortet jedes Team dieselbe Frage anders, und Analysten bereinigen Daten, statt Schlüsse zu ziehen. Mit ihr können Sie auf einer einzigen Version der Wahrheit berichten und gewinnen ein Fundament für Dinge, die vorher außer Reichweite lagen: Scoring, Personalisierung, Vorhersagemodelle und später eine AI-Schicht.
Wie bauen Sie Datenpipelines: Batch-Ingest und Streams?
Im Herzen der Plattform stehen Datenpipelines, die Prozesse, die Daten von den Quellen dorthin bringen, wo man mit ihnen arbeiten kann. Sie teilen sich in Batch und Streaming, und die Wahl folgt daraus, wie frisch die Daten sein müssen. Meist bauen wir beide Wege nebeneinander:
- Batch-Ingest für Daten, die stündlich oder täglich aufgefrischt werden müssen,
- Streaming für Ereignisse, die die Plattform nahezu sofort erreichen müssen,
- eine Orchestrierungsschicht (z. B. Airflow), die über Reihenfolge, Abhängigkeiten und Wiederholungen wacht,
- Fehler- und Retry-Behandlung, damit ein nicht erreichbares System nicht den ganzen Fluss umwirft.
Eine gut entworfene Pipeline ist idempotent und beobachtbar: Sie können sie gefahrlos erneut starten, und wenn etwas bricht, sehen Sie sofort, wo.
Warehouse oder Lakehouse: worauf sollte eine Datenplattform setzen?
Diese Frage kommt in fast jedem Projekt auf. Ein Data Warehouse (z. B. Snowflake, BigQuery) glänzt bei strukturierten Daten und SQL-Analytik; es ist planbar und einfach. Ein Lakehouse (z. B. Databricks) verbindet günstigen Speicher für Rohdaten mit der Möglichkeit, darauf zu rechnen wie in einem Warehouse, und kommt mit halbstrukturierten Daten und ML-Lasten besser zurecht. Selten ist das eine Entweder-oder-Frage, deshalb empfehlen wir oft ein Warehouse als Bereitstellungsschicht für die Analytik und ein Lakehouse oder einen Data Lake für Rohdaten und ML. Entscheidend ist nicht, welches Logo gewinnt, sondern dass Datenmodell, Kosten und Kompetenzen des Teams zum Maßstab des Unternehmens passen, und bei dieser Entscheidung helfen wir Ihnen bewusst.
Was ist Analytics Engineering und eine Metrikschicht?
Zwischen Rohdaten und Dashboard liegt eine Schicht, die oft übersprungen wird: Analytics Engineering. Hier werden aus Rohtabellen Datenmodelle mit klaren Definitionen, Tests und Dokumentation, meist mit dbt, sodass Geschäftslogik an einem Ort lebt statt in Dutzenden Abfragen, verstreut über BI-Werkzeuge. Darauf baut die Metrikschicht (Semantic Layer) auf, ein einziger Ort, an dem „Umsatz”, „aktiver Nutzer” oder „Churn” je eine Definition haben, sodass zwei Teams auf dieselbe Frage dieselbe Zahl bekommen. Für ein Tech-Unternehmen ist das oft ein größerer Umbruch als das Warehouse selbst.
Wie überwachen Sie die Datenqualität auf der Plattform?
Eine Datenplattform ist so viel wert wie das Vertrauen in die Zahlen, die aus ihr fließen. Deshalb behandeln wir Datenqualität als eigene, gemessene Schicht. In der Praxis verdrahten wir in die Plattform:
- Datentests (Vollständigkeit, Eindeutigkeit, Wertebereiche, Schlüsselintegrität),
- Datenverträge zwischen Produktteam und Plattform, damit eine Änderung an einer Quelle keine Berichte bricht,
- Überwachung von Aktualität und Volumen, die warnt, wenn Daten zu spät kommen oder plötzlich die Hälfte fehlt,
- Data Lineage, eine Abhängigkeitskarte, die zeigt, was bricht, wenn Sie eine bestimmte Tabelle ändern.
Im Ergebnis löst das Problem einen Alarm aus, bevor der Bericht überhaupt entsteht.
Wie steuern Sie Zugriffe, Compliance und Plattformkosten?
Je mehr die Plattform kann, desto wichtiger wird Governance, also die Frage, wer worauf Zugriff hat. Sobald personenbezogene Daten und die DSGVO ins Spiel kommen, ist eine Schicht für Zugriffssteuerung, Maskierung sensibler Felder und Audit nicht optional; sie ist der Eintrittspreis.
Ein eigenes Thema, das viele überrascht, sind die Kosten. Ein Warehouse oder Lakehouse in der Cloud rechnet nach Nutzung ab, also kann eine schlecht geschriebene Abfrage oder eine zu häufig aufgefrischte Pipeline eine Rechnung auftürmen, die niemand eingeplant hat. Deshalb legen wir die Plattform von Anfang an mit Blick auf FinOps an, damit sie mit dem Unternehmen skaliert und nicht gegen dessen Budget.
Wann sollten Sie der Plattform eine AI-Schicht hinzufügen?
Eine AI-Schicht ist die natürliche Erweiterung einer guten Datenplattform, aber sie ergibt erst Sinn, wenn das Fundament stabil steht. Ein Vorhersagemodell ist nur so gut wie die Daten, die es bekommt, deshalb ist die Reihenfolge „zuerst saubere Daten, dann AI” keine Formalie. Unsere Kompetenz hier ist real: In der RITS Group arbeiten unsere AI-, LLM- und Datenteams an AI, LLMs und Daten, und als Gruppe haben wir Projekte mit GenAI, RAG und Sprachmodellen geliefert. Das erlaubt uns, die Plattform von Anfang an für spätere AI-Lasten auszulegen: Feature Store, Vektorisierung der Daten, Pipelines für Training und Bereitstellung von Modellen. Wir sprechen von Kompetenz, nicht von einer AI-Einführung von der Stange in Ihrem Unternehmen.
Welche Kompetenzen stellen wir für ein Datenplattform-Projekt?
Der Kern ist einfach: Wir stellen die Menschen, die die Datenplattform bauen und betreiben werden. Wir formen das Team um die Projektphase, nicht „auf Vorrat”, und prüfen die Kompetenzen vor dem Start. Am häufigsten besetzen wir diese Rollen:
- einen Data Engineer, der Pipelines, Ingest und Quellintegrationen baut,
- einen Analytics Engineer, der Datenmodelle, dbt und die Metrikschicht verantwortet,
- einen Data Architect, der die Richtung setzt: Warehouse oder Lakehouse, Datenmodell, Kosten,
- einen Platform- bzw. DevOps-Spezialisten (DataOps), der über Infrastruktur, CI/CD und Zuverlässigkeit wacht,
- optional einen ML- bzw. AI-Engineer, sobald die Modellschicht ins Spiel kommt.
Ein solches Team kann sich in eine bestehende Datenabteilung einfügen oder einen Teil der Plattform durchgängig verantworten.
Wie machen wir das bei RITS?
Wir tun das als Nearshore-Partner aus Polen, der einsatzbereite Data Engineers mitbringt und keine Präsentation über Daten. Wir besetzen das Projekt mit Data- und Big-Data-Engineers, die echte Erfahrung mit Pipelines, Warehouses und Datenqualität haben, und stützen die AI-Schicht auf die Kompetenz der RITS Group. In einer nahen Zeitzone finden wir ohne langen Anlauf in Ihren Arbeitsrhythmus.
Wir sind ehrlich mit den Grenzen: Ohne fertige Referenz für eine Datenplattform im Tech-Umfeld verkaufen wir Kompetenz und Menschen und nicht die Erfolgsgeschichte eines anderen - für Entscheidende ist das ein ehrlicherer Ausgangspunkt als eine retuschierte Referenz.
Womit beginnen Sie beim Aufbau einer Datenplattform?
Beginnen Sie mit einer geschäftlichen Frage, die sich heute schwer beantworten lässt (etwa „wie viele wirklich aktive Nutzer haben wir, und was kostet es, sie zu halten”). Sie legt fest, welche Daten zu sammeln sind, wie frisch sie sein müssen und wie sie definiert werden, und damit die Architektur der ersten Version der Plattform. Bauen Sie schmal, aber durchgängig. Der zweite Schritt ist die Entscheidung, wer sie baut: die eigene Abteilung, Team-Verstärkung oder ein dediziertes Team. Die Unterschiede zwischen diesen Modellen haben wir in unserem Artikel zu IT-Kooperationsmodellen dargelegt.
Bauen Sie eine Datenplattform oder wollen Sie Ihre ordnen? Sprechen wir darüber - wir stimmen Data Engineers und Architektur auf Ihre Daten ab.