Architektur einer Datenplattform

Wenn ein Unternehmen seine erste Datenplattform aufbaut, liegt der Fokus oft auf schnellen Lösungen, die unmittelbare Bedürfnisse erfüllen, anstatt eine Architektur zu entwerfen, die skalierbar ist. Das ist verständlich — Startups bewegen sich schnell, und Dateninfrastruktur scheint oft zweitrangig zu sein im Vergleich zu anderen Aufgaben. Eine Einführung in einen Beitrag auf dlthub Blog bringt dies perfekt auf den Punkt:

„Unternehmen, die ihren ersten Datenstack aufbauen, beginnen meist mit einer kleinen Investition – daher ist es unwahrscheinlich, dass sie ein Senior-Team und die Vision oder Ressourcen haben, um eine Plattform zu bauen. Aus diesem Grund wird das Team wahrscheinlich mit etwas starten, das funktioniert, und sich von dort aus weiterentwickeln. (…) Das ist weit entfernt von einer konsistenten, nachhaltigen Möglichkeit, Datenpipelines oder Datenflüsse zu verwalten.“

Adrian Brudaru

Das ist natürlich wahr. Wir haben viele Unternehmen gesehen, deren Datenpipelines von einem Python-Programmierer, einem Datenanalysten, einem angehenden Data Scientist oder einem Junior Data Engineer aufgebaut wurden. Sie waren wahrscheinlich schnell und kostengünstig zu erstellen und haben damals ihre Aufgabe erfüllt. Aber auf lange Sicht waren sie weder erweiterbar noch skalierbar. Tatsächlich waren sie oft auch nicht zuverlässig und schwer wartbar.

Schnelle Lösungen halten nicht lange

Natürlich wächst mit dem Unternehmen nicht nur das Volumen der verarbeiteten Daten, sondern auch die Nachfrage nach Informationen und es entstehen immer mehr Anwendungsfälle für Daten. Diese adhoc zusammengestellten Datensysteme können mit diesen Veränderungen nicht mithalten. Sie wurden nicht dafür entwickelt. Tatsächlich wurden sie oft überhaupt nicht richtig geplant.

Sehr oft muss der ursprüngliche Datenstack vollständig verworfen und neu gestaltet werden, um die neuen Anwendungsfälle zu bewältigen und die gewachsene Organisation zu unterstützen. Dies ist eine schwierige Entscheidung und wird in der Regel aufgeschoben, bis das Problem eskaliert. Das alte System, das nicht für wenig Wartung gebaut wurde, zu pflegen, während man eine neue Datenplattform aufbaut, ist eine Aufgabe, die viele Daten-Teams überfordert. Es besteht ein hohes Risiko, dass die Datenoperationen für viele Monate behindert werden. Zudem passiert dies meist genau dann, wenn die Nachfrage rasant wächst. Es ist einfach ein Risiko für das Unternehmen.

Und wir machen nicht den Junior Engineer oder Analysten verantwortlich, der die ersten Pipelines erstellt hat. Sie bauten für das „Hier und Jetzt“ und konnten aufgrund begrenzter Erfahrung nicht vollständig vorhersagen, wie sich die Nachfrage im Laufe der Zeit entwickeln würde. Sie haben die bestmögliche Arbeit geleistet, unter Berücksichtigung ihres Wissensstandes. Es ist einfach so, dass ihre Fähigkeit, eine robuste, skalierbare und erweiterbare Architektur zu entwickeln, begrenzt war.

Der andere Weg

Es muss nicht so laufen. Sie können von Anfang an eine geeignete Datenarchitektur erhalten. Das bedeutet nicht, dass Sie ein vollständig ausgereiftes System von Tag 1 an aufbauen müssen. Es geht mehr darum, einige Schlüsselentscheidungen zu treffen, wie das zukünftige System aussehen wird, welche Teile Sie jetzt vorbereiten müssen und welche warten können. Man kann (und sollte) immer noch einige Ecken abschneiden, aber dies sollte eine bewusste Entscheidung sein.

Und Sie müssen keinen vollzeit Data Architect einstellen, um die Datenplattform zu entwerfen — etwas, das in der Anfangsphase prohibitiv teuer sein kann. Es gibt Möglichkeiten, dies strategischer anzugehen, ohne Ressourcen zu überbeanspruchen. Der Schlüssel ist, die unmittelbaren Bedürfnisse mit dem langfristigen Wachstum in Einklang zu bringen und zu erkennen, dass nicht alles sofort gebaut werden muss. Aber die Teile, die Sie bauen, sollten in der Lage sein, bei Bedarf zu skalieren.

Eine Möglichkeit, dies zu erreichen, besteht darin, frühzeitig erfahrene Beratung hinzuzuziehen. Sie können sich einen Fractional Head of Data holen, um sowohl Ihr Datenteam als auch die Datenarchitektur aufzubauen. Auf diese Weise stellen Sie sicher, dass Ihre Systeme von Anfang an mit Blick auf das Wachstum entwickelt werden — modular und skalierbar. Entworfen nicht nur für die bestehenden Bedürfnisse, sondern auch unter Berücksichtigung der Unternehmensvision für die Zukunft. Diese Art von Weitblick ermöglicht es Ihnen, später einen vollständigen Neubau zu vermeiden, der oft störend und kostspielig ist. Stattdessen können Sie es Stück für Stück skalieren, wenn es notwendig ist, oder die einzelnen Teile ersetzen, ohne das gesamte System neu zu entwerfen.

Was ist mit dem Team?

Darüber hinaus kann der Fractional Head of Data Ihnen helfen, die richtigen Talente zu finden, wenn Ihr Unternehmen wächst. Wenn Sie gerade erst damit beginnen, Ihr Datenteam aufzubauen, gibt es wahrscheinlich niemanden im Unternehmen, der die zukünftigen Bedürfnisse des Teams richtig vorhersagen und die technischen Fähigkeiten der Kandidaten beurteilen kann. Fälle, in denen der Gründer oder der CTO kürzlich von einer Position als z.B. Director of Data gekommen ist und tatsächlich domänenspezifische Expertise hat, sind selten.

Wie stellen Sie also sicher, dass Sie die richtigen Leute einstellen? Der externe Head of Data ad interim versteht sowohl die Bedürfnisse des aktuellen Systems als auch seine zukünftige Entwicklung. Er kann sicherstellen, dass neue Mitarbeiter — sei es Ingenieure oder Analysten — gut geeignet sind, die bestehende Infrastruktur zu unterstützen und auszubauen. Dies reduziert nicht nur die Lernkurve für neue Teammitglieder, sondern hilft auch, ein Szenario zu vermeiden, in dem die Fähigkeiten des Teams nicht mit der Architektur des neuen Systems übereinstimmen.

Intelligent aufbauen

Es ist sehr wahrscheinlich, dass die Art der Arbeitsbelastung während des Aufbaus des Systems sehr unterschiedlich sein wird von der typischen Arbeitsbelastung beim Betrieb des Systems. Also auch der Satz an Fähigkeiten, der notwendig ist, um erfolgreich zu sein. Zu Beginn des Projekts wird es erheblichen Aufwand im Bereich der Datenarchitektur und -technik erfordern, während Analysten wenig zu tun haben werden. Sobald das System näher an der Fertigstellung ist und ohne größere Probleme läuft, könnte der Fokus auf Analytics verschieben, während der Engineering-Aufwand auf den Standardbetrieb und gelegentliche Verbesserungen beschränkt wird.

Es wäre sinnvoll, zu Beginn des Projekts ein oder zwei zusätzliche Dateningenieure auf Vertragsbasis hinzuzuziehen. Sie bringen nicht nur zusätzliche Entwicklungskapazitäten. Vor allem bringen sie das Fachwissen und die Fähigkeiten mit, die Sie möglicherweise noch nicht im Team haben. Idealerweise sollten sie länger bleiben, mit stark reduziertem Engagement, um Ihre neuen Mitarbeiter auszubilden und bei der Wartung zu helfen, bis Ihr Team in der Lage ist, die Arbeit vollständig zu übernehmen. Dies gewährleistet eine reibungslose Übergabe, und das ist einer der Gründe, warum wir Data Engineering as a Service anbieten.

Richtig bauen, ohne das Budget zu sprengen

Wir verstehen, dass Unternehmen in der Frühphase auf Ressourcen achten müssen. Es ist nicht immer realistisch, die Datenplattform von Anfang an perfekt zu bauen, und das ist auch in Ordnung. Wichtig ist, eine klare Vorstellung davon zu haben, wie das System später aussehen soll, und sicherzustellen, dass die frühen Entscheidungen — sei es bei Design, Tools oder Prozessen — später keine Wachstumsbarrieren schaffen. Dadurch können Sie das Beste aus Ihrer ersten Investition machen, ohne Ihre frühen Bemühungen ständig überarbeiten oder ersetzen zu müssen.

Indem Sie sorgfältig überlegen, wie sich Ihre Datenbedürfnisse entwickeln werden, können Sie die „Schnelllösungs“-Mentalität vermeiden, die häufig zu späteren Problemen führt. Ob es nun darum geht, eine langfristige Datenstrategie festzulegen oder effiziente, skalierbare Pipelines zu erstellen, die richtigen Entscheidungen zu Beginn werden Ihnen Zeit, Geld und Mühe sparen, wenn Ihr Unternehmen wächst. Die Datenstrategie geht nicht darum, alle potenziellen zukünftigen Anwendungsfälle und Anforderungen vorherzusagen. Es reicht aus, einige von ihnen vorherzusehen und die Tatsache anzuerkennen, dass Sie einige Teile des Systems im Laufe der Zeit ändern müssen. Bauen Sie es so, dass Änderungen leicht vorgenommen werden können, ohne etwas zu zerstören.

Und es muss nicht überwältigend sein. Mit Zugang zu der richtigen Expertise, sogar auf Teilzeitbasis, können Sie Systeme aufbauen, die Ihren aktuellen Bedürfnissen entsprechen, ohne das zukünftige Wachstum zu blockieren.