Die Bausteine erfolgreicher Daten-Teams

Während meiner 7 Jahre Erfahrung im Bereich Daten habe ich in mehreren Datenteams gearbeitet, von denen einige erfolgreich waren, während andere es nicht waren. In diesem Blogbeitrag beschreibe ich 5 Bausteine, die entscheidend für den Erfolg eines Datenteams sind.

Datenverantwortung zuweisen

Datenverantwortung beginnt damit, klare Verantwortlichkeiten für bestimmte Teams zuzuweisen, die für den Aufbau und die Wartung verschiedener Komponenten Ihrer Datenlandschaft verantwortlich sind, wie Pipelines, Anwendungen und Dashboards. Ich bin oft auf Situationen gestoßen, in denen niemand für eine fehlerhafte Komponente verantwortlich war, was zu einem Schuldspiel unter Teams führte, die mehr auf Selbstbewahrung als auf die Lösung des eigentlichen Problems fokussiert waren.

Zu versuchen, das Problem eigenständig zu beheben, kann zeitaufwändig sein, da es oft erforderlich ist, zu verstehen, wie jede Komponente interagiert, den Code zu lokalisieren und den Bereitstellungsprozess des Produkts zu lernen. Um diesen Prozess zu optimieren, sind aktuelle Dokumentationen von unschätzbarem Wert, auch wenn es leider selten ist, umfassende Dokumentationen zu finden. Neben der Dokumentation Ihrer Arbeit kann auch die Standardisierung von Praktiken in diesen Szenarien erheblich helfen.

Ein zweiter Aspekt in Bezug auf Verantwortung ist die Entwicklung eines Produktdenkens in Ihren Teams. Dieser Ansatz konzentriert sich darauf, wie Menschen Ihr Produkt nutzen werden, und betont die Einfachheit. Oft erfordert es ein breiteres Denken über den anfänglichen Anwendungsfall hinaus und berücksichtigt potenzielle zukünftige Anwendungen der Daten.

Vor mehreren Jahren war ich Teil eines Projekts, bei dem wir dieses Produktdenken nicht anwendeten. Wir entwickelten einen maßgeschneiderten Workflow für jedes Unternehmen, das unsere Daten anforderte. Folglich hatten wir am Ende sechs APIs, die alle dieselben Eingabedaten verwendeten, sie jedoch mit geringfügigen Unterschieden, wie Datenformat und exponierten Eigenschaften, bereitstellten. Die wichtigste Erkenntnis war die Notwendigkeit einer besseren Voraussicht hinsichtlich der langfristigen Auswirkungen dieses Ansatzes. Im Laufe der Zeit wurde dieses Setup schwierig zu warten, da jede Datenänderung Anpassungen in sechs verschiedenen Repositories erforderte.

Ein wichtiger Aspekt bei der Definition Ihres Datenprodukts besteht darin, Service-Level-Ziele (SLOs) und Service-Level-Vereinbarungen (SLAs) zu definieren. Diese können Frequenzen für Datenaktualisierungen oder Garantien für die Verfügbarkeit des Produkts festlegen. Für potenzielle Verbraucher Ihrer Daten könnte die Verfügbarkeit der SLA ein entscheidender Faktor für deren Entscheidung sein, ob sie Ihr Produkt nutzen oder nicht.

Konzentration auf Geschäftsergebnisse

Jeder Dateningenieur hat seine bevorzugten Technologien. Persönlich schreibe ich gerne Code in Golang und setze Anwendungen auf Kubernetes ein. Was einen großartigen Dateningenieur jedoch auszeichnet, ist die Fähigkeit, die beste Lösung für einen Anwendungsfall auszuwählen, anstatt sich nach der persönlichen Vorliebe zu richten. In meiner Arbeit bedeutet dies oft, Datenumwandlungen in Python anstelle von Scala zu schreiben, da unsere Kunden damit vertrauter sind.

Als Ingenieur ist es wichtig, sich daran zu erinnern, dass das Geschäft sich nicht um Ihre technische Implementierung kümmert. Sie sind mehr an den Ergebnissen Ihrer Arbeit interessiert: ob die Daten korrekt sind oder ob eine neue Funktion ihre Arbeit vereinfacht. Es wird ihnen egal sein, ob Sie Snowflake anstelle von Postgres verwenden, um Daten zu speichern, es sei denn, es macht einen greifbaren Unterschied für sie, wie schnellere Abfragegeschwindigkeiten.

Ich habe auch gelernt, dass, wenn man die Wahl zwischen der Neuformulierung eines Workflows zur Wartbarkeit oder einfach dem Hinzufügen von Code hat, Geschäftspartner in der Regel die schnellste Option bevorzugen. Wartbarkeit ist für sie nicht so greifbar, da sie hauptsächlich technische Arbeiten beeinflusst. Deshalb liegt es an Ihnen, diese Entscheidung zu treffen und sie gegebenenfalls zu überzeugen.

Ich erinnere mich an ein Projekt, bei dem drei Softwareingenieure unsere Datenbank von Postgres auf Cassandra wegen Leistungsproblemen migrieren wollten. Dieser Wechsel hätte Wochen Arbeit erfordert, um Cassandra vor Ort bereitzustellen und alle unsere Daten zu migrieren. Nach einer kurzen Untersuchung zur Optimierung langsamer Abfragen fanden wir jedoch, dass das Hinzufügen von nur zwei Indizes alle unsere Probleme löste, und diese Lösung ist seit Jahren stabil.

Ihr primärer Fokus sollte immer darauf liegen, Wert für das Unternehmen zu liefern, da sie Ihre Kunden sind und für Ihre Arbeit bezahlen. Dies sollte Vorrang vor persönlicher Entwicklung haben, wie dem Erlernen einer neuen Technologie oder Programmiersprache.

Verwenden Sie bewährte Verfahren in der Software

Viele bewährte Verfahren in der Datenverarbeitung stimmen mit denen in der Softwaretechnik überein. Da die Softwaretechnik eine längere Geschichte hat, können wir verschiedene Praktiken übernehmen, anstatt zu versuchen, neue zu erfinden. Während das Schreiben von Code entscheidend ist, ist es nur eine Komponente zur Bereitstellung einer neuen Funktion. Viele andere Aspekte vereinfachen die Entwicklung und die Wartbarkeit des Codes. Hier ist eine nicht erschöpfende Liste dieser zusätzlichen Aspekte:

• Versionierung Ihres Codes

• Schreiben von Unit- und Integrationstests

• Einrichten eines CI/CD für Ihr Projekt

• Überwachung und Nachverfolgung einrichten

• Dokumentation schreiben

• Verwaltung Ihrer Infrastruktur mit Code

Für mich weiß ein guter Dateningenieur all diese Aspekte und integriert sie bei der Implementierung eines neuen Anwendungsfalls. Ich habe einen vorherigen Blogbeitrag darüber geschrieben, warum ich glaube, dass Dateningenieure mehr wie Softwareingenieure sein sollten, den Sie hier lesen können. Eine Person, die diese Praktiken nicht befolgt und sich darauf konzentriert, Code zu schreiben und ihn ad hoc in einer Ausführungsumgebung bereitzustellen, ist ein Cowboy und kein Ingenieur.

Ich weiß, dass das Befolgen dieses Ansatzes auf kurze Sicht mehr Zeit in Anspruch nehmen könnte, aber die zusätzliche Investition wird sich langfristig leicht amortisieren. Wenn Qualitätsprobleme, Bugs gefunden werden oder Versionsupdates durchgeführt werden müssen, bieten diese Praktiken Leitplanken und helfen Ihnen.

Bereitstellung einer Self-Service-Datenplattform

Bei der Arbeit in größeren Datenorganisationen (> 15 FTE) erstellt ein Datenplattform-Team typischerweise Bausteine (z. B. gepflasterte Straßen) für die Nutzung durch verschiedene Datenteams. Diese generischen Bausteine sind so konzipiert, dass sie in verschiedenen Projekten wiederverwendbar sind. Hier ist eine nicht erschöpfende Liste beliebter Bausteine:

• Workflow-Planer (Airflow, Dagster,…)

• Rechenumgebung (Kubernetes, AWS Batch, Lambda)

• Datenablage (S3, AWS RDS, Snowflake)

• Datenverarbeitungsengines (Spark, dbt, Polars)

• Zugriff auf Daten steuern (Pbac, Rbac)

• Projektschablonen (cookiecutter)

• CI/CD-Pipeline (Github Actions, AWS CodeBuild)

• Überwachungs- und Protokollierungsfunktionen (ELK-Stack, Prometheus-Grafana-Alertmanager-Stack)
  
  

Es ist wichtig, dass diese Bausteine self-servicefähig sind, um zu verhindern, dass das Datenplattform-Team zu einem Engpass wird. Das Ziel ist es, die Funktionen zu ermöglichen, dass Feature-Teams autonom arbeiten können, ohne von der Verfügbarkeit des Plattform-Teams abhängig zu sein. Durch die Automatisierung dieser Fähigkeiten können Sie mehr Anwendungsfälle mit derselben Anzahl von Personen unterstützen. Die Reduzierung von Reibung stellt sicher, dass die meisten Anwendungsfälle diese optimierten Wege nutzen, was eine schnelle Bereitstellung neuer Anwendungsfälle ermöglicht.

Die Bausteine müssen nicht jede Funktion unterstützen, die von anderen Datenteams benötigt wird, sollten jedoch der 80/20-Regel entsprechen. Indem 80 % der Anwendungsfälle durch gemeinsame Bausteine abgedeckt werden, ermöglicht das Plattform-Team den Datenteams, die meisten Standardanwendungsfälle schnell zu liefern. Wenn ein Datenteam vom Standardprozess abweichen muss, kann es dies tun, muss jedoch einige der gängigen Bausteine für seinen Anwendungsfall neu implementieren.

Zusätzliche Vorteile von optimierten Wegen in Ihrer Organisation sind:

• Die meisten Projekte haben eine ähnliche Struktur und sind somit leicht von jedem in Ihrem Team zu warten und anzupassen.

• Die Einführung neuer Bausteine ist einfach, da sie auf der gemeinsamen Struktur basieren kann.

Eine unternehmensweite Datenstrategie erstellen

Dieser letzte Aspekt ist nicht wirklich ein Merkmal des Datenteams selbst, sondern eher der Organisation als Ganzes. Damit ein Datenteam gedeihen und die Datenreife der Organisation steigern kann, muss jeder deren Bedeutung anerkennen und handeln. Dies beginnt damit, dass das Management seine Bedeutung anerkennt. Neben der Geschäftsführung ist es entscheidend, kompetente Personen auf allen Ebenen des Datenteams einzustellen. Letztendlich sollte jeder in der Organisation die Datenstrategie verstehen und wie sie dem Unternehmen zugutekommt.

Vor einigen Jahren erlebte ich die Auswirkungen einer Fehlanpassung zwischen einem Datenteam und dem Geschäft in einem Unternehmen, für das ich gearbeitet habe. Das Datenteam entwickelte viele neue Datenprodukte, die die Geschäftsabläufe optimierten. Das Geschäft hatte jedoch Schwierigkeiten, diese Produkte zu übernehmen, was sich folgendermaßen äußerte:

• Herausforderungen in gemeinsamen Diskussionen zur Erfassung der Geschäftsbedürfnisse

• Verlängerte Validierungszeiträume für neue Funktionen aufgrund niedriger geschäftlicher Priorität

Das Ergebnis war, dass diese Datenprodukte selten verwendet wurden, was zu Frustration im Datenteam führte. Die Lösung bestand darin, die Implementierung eines Anwendungsfalls erst zu beginnen, wenn ein klarer Geschäftsvertreter identifiziert war. Diese Person diente als einziger Ansprechpartner für das Team und förderte die neue Arbeitsweise unter ihren Kollegen.

Schlussfolgerung

In diesem Blogbeitrag habe ich fünf wesentliche Merkmale identifiziert, die ich für den Erfolg eines Datenteams für entscheidend halte:

• Verantwortung für Daten

• Ein Fokus auf Geschäftsergebnisse

• Übernahme bewährter Praktiken der Softwaretechnik

• Bereitstellung einer Self-Service-Datenplattform

• Anerkennung, dass die Datenstrategie ein unternehmensweites Anliegen ist

Ich hoffe, diese Punkte können dazu beitragen, den Erfolg Ihres Datenteams zu verbessern.

Wenn Sie denken, dass es andere Merkmale zu berücksichtigen gibt, oder wenn Sie mit einem meiner Punkte nicht einverstanden sind, teilen Sie bitte Ihre Gedanken im Kommentarbereich mit.