Datenpipeline aufbauen oder kaufen?
Ich habe diese Entscheidung selbst getroffen – auf beiden Seiten. Ich habe Pipelines gebaut, die ich heute noch betreibe. Ich habe Pipelines gebaut, die ich nach sechs Monaten durch externe Services ersetzt habe. Und ich habe Pipelines übernommen, die irgendwann jemand gebaut hat und seitdem niemand mehr wirklich versteht.
Die Make-or-Buy-Entscheidung bei Datenpipelines ist keine Frage von Kompetenz. Sie ist eine Frage von Eigentumsverantwortung.
Erst die Definition: Was ist eine Datenpipeline?
Weil der Begriff verschieden verwendet wird: Eine Datenpipeline ist eine automatisierte Abfolge von Schritten, die Daten aus einer oder mehreren Quellen extrahiert, transformiert und in ein Zielsystem lädt. In der Fachliteratur: Extract, Transform, Load – ETL.
Quellen können sein: Webseiten (via Scraping), externe APIs, Datenbanken anderer Systeme, ERP- oder CRM-Exporte, FTP-Server.
Ziele können sein: interne Datenbanken, BI-Tools (Metabase, Tableau, Power BI), Data Warehouses, oder direkte Weiterverarbeitung in anderen Systemen.
Die Pipeline selbst ist der Teil dazwischen: Bereinigung, Normalisierung, Deduplizierung, Anreicherung, Fehlerbehandlung.
Wann selbst bauen die bessere Entscheidung ist
Wenn du die Quelle kontrollierst. Interne Systeme, eigene APIs, eigene Datenbanken. Kein Anti-Scraping-Problem, keine unerwarteten Layout-Änderungen, keine externe Abhängigkeit.
Wenn du die Datenstruktur genau kennst und sie sich selten ändert. Je stabiler das Schema der Quell- und Zieldaten, desto geringer der Wartungsaufwand. Ein eigener ETL-Job, der einmal konfiguriert ist und jahrelang läuft, ist oft die richtige Lösung.
Wenn du Data Engineering Kapazität im Team hast. Nicht nur die Fähigkeit, eine Pipeline zu bauen – sondern die Kapazität und Bereitschaft, sie zu pflegen. Das ist ein Unterschied.
Wenn du hochspezifische Anforderungen hast. Proprietäre Formate, proprietäre Schnittstellen, komplexe Transformationslogik, die kein Standardprodukt kennt.
Das ist ein relevanter Teil der Projekte. Nicht alle, aber ein relevanter.
Wann Outsourcing sinnvoller ist
Wenn die Quelle extern und volatil ist. Webseiten, deren Layout sich ändern. APIs mit wechselnder Authentifizierung. Drittanbieter-Systeme, über deren Änderungszyklen du keine Kontrolle hast.
Wenn die Pipeline kritisch ist, aber kein Kerngeschäft. Die Preisdaten deiner Wettbewerber täglich zu haben ist wichtig für dein Business – aber das Betreiben des Scrapers ist kein Teil deiner Wertschöpfung. Der Unterschied ist relevant.
Wenn der Eigenverantwortlichkeit fehlt. Wenn das Gebäude der Pipeline auf einem einzelnen Entwickler basiert – und dieser Entwickler das Unternehmen verlässt, in einem anderen Projekt ist, oder krank wird – ist das Pipeline das schwächste Glied. Ein Managed Service hat kein Sabbatical.
Wenn das Monitoring nicht existiert. Eine Pipeline ohne Monitoring ist eine Pipeline, von der du nicht weißt, ob sie läuft. Das klingt offensichtlich, ist aber der häufigste Zustand: Pipelines, die still falsche Daten produzieren, weil niemand Alerts eingerichtet hat.
Die Kostenrechnung, die oft fehlt
Selbst bauen hat sichtbare Kosten und unsichtbare Kosten.
Die sichtbaren: Entwicklungszeit, Server, Tools.
Die unsichtbaren:
Wartung: 4–8h/Monat × Stundensatz
Monitoring: Setup-Zeit + laufende Aufmerksamkeit
Fehler-Debug: unberechenbar, aber regelmäßig
Wissenstransfer: bei Personalwechsel oft: 0Die unsichtbaren Kosten sind schwer zu schätzen – deswegen werden sie systematisch unterschätzt. Wer nur die Entwicklungszeit in die Kalkulation einrechnet, rechnet sich arm.
Die Frage, die mehr zählt als jede Kostenkalkulation
„Wer besitzt diese Pipeline in 18 Monaten?“
Nicht im technischen Sinn – sondern im organisatorischen. Wer ist verantwortlich, wenn sie ausfällt? Wer bemerkt, wenn sie falsche Daten produziert? Wer passt sie an, wenn die Quelle sich ändert?
Wenn die Antwort „wir schauen dann mal“ ist, oder wenn die Antwort auf einem einzelnen Mitarbeiter lastet, der vielleicht nicht mehr da ist – dann habt ihr die Make-or-Buy-Entscheidung noch nicht wirklich getroffen. Ihr habt nur die Bauphase entschieden.
Hybrid ist oft die ehrlichste Antwort
In der Praxis ist die Entscheidung selten binär. Viele Teams bauen interne Pipelines für interne Quellen (eigene Datenbanken, eigene APIs) und nutzen Managed Services für externe Quellen (Webdaten, Drittanbieter-Systeme). Das macht Sinn: Dort, wo ihr die Quelle kontrolliert, habt ihr auch die Expertise und die Anreize, die Pipeline zu pflegen. Dort, wo ihr sie nicht kontrolliert, ist Outsourcing das ehrlichere Modell.
Weitere Ressourcen
Vertiefende Seite zu Datenpipelines – was konkret enthalten ist, welche Quellen eingebunden werden können und was das kostet:
→ Datenpipeline – ETL und Datenintegration
Wenn du die Make-or-Buy-Entscheidung für Scraping-Pipelines im Detail durchdenken willst:
→ Selbst scrapen oder beauftragen? Meine ehrliche Einschätzung.
Und was automatische Datenbeschaffung insgesamt kostet:
