Die ideale DataOps-Organisationsstruktur

Die externe Kommunikation eines Unternehmens spiegelt in der Regel seine interne wider. Das hat uns Melvin Conway beigebracht, und das gilt auch für Data Engineering. Wenn Sie kein klar definiertes Datenoperations- oder „DataOps“-Team haben, werden die Ausgaben Ihres Unternehmens genauso unübersichtlich sein wie seine Eingaben.

Datenoperationen sind der Prozess des Aufbaus der Infrastruktur zur Erzeugung und Verarbeitung von Daten sowie deren Wartung. Es ist auch der Name des Teams, das diese Arbeit erledigt (oder erledigen sollte) – Datenoperationen oder DataOps. Was macht DataOps? Nun, wenn Ihr Unternehmen Datenpipelines unterhält, kann die Gründung eines Teams unter diesem Namen zur Verwaltung dieser Pipelines ein Element der Organisation und Kontrolle bieten, das sonst fehlt.

DataOps ist nicht nur für Unternehmen gedacht, die ihre Daten verkaufen. Die jüngste Geschichte hat gezeigt, dass man ein Datenoperationsteam benötigt, unabhängig von Herkunft oder Verwendungszweck der Daten. Interner Kunde oder externer Kunde, es ist alles dasselbe. Man braucht ein Team, das die Pipelines aufbaut (oder, seien wir ehrlich, sie übernimmt und dann neu aufbaut). Sie sollten dieselben Personen (oder, für viele Unternehmen, Person) sein, die Observability- und Tracking-Tools implementieren und die Datenqualität in ihren vier Attributen überwachen.

Und natürlich sollten die Leute, die die Pipeline gebaut haben, dieselben Leute sein, die die gefürchtete PagerDuty-Warnung erhalten, wenn ein Dashboard ausfällt – nicht weil es Strafwirkung hat, sondern weil es lehrreich ist. Wenn sie etwas zu verlieren haben, bauen die Leute anders. Das ist ein guter Anreiz und ermöglicht eine bessere Problemlösung und schnellere Problembehebung.

Nicht zuletzt braucht das Datenbetriebsteam eine Mission – eine, die über das bloße „Verschieben der Daten“ von Punkt A nach Punkt B hinausgeht. Und deshalb ist der Teil „Operations“ in ihrem Titel so wichtig.

Datenoperationen bauen resiliente Prozesse auf, um Daten für ihren beabsichtigten Zweck zu verschieben. Alle Daten sollten aus einem bestimmten Grund verschoben werden. Oft ist dieser Grund der Umsatz. Wenn Ihr Datenoperationsteam keinen klaren Zusammenhang zwischen dem Endziel, beispielsweise besseren Prognosen und höheren Umsätzen der Vertriebsteams, und seinen Pipeline-Management-Aktivitäten herstellen kann, dann haben Sie ein Problem.

Ohne operative Maßnahmen werden bei der Skalierung Probleme auftreten:

• Duplizierung von Daten
• Gestörte Zusammenarbeit
• Warten auf Daten
• Pflaster, die Narben hinterlassen
• Discovery-Probleme
• Nicht verbundene Tools
• Inkonsistenzen bei der Protokollierung
• Fehlender Prozess
• Fehlende Eigentumsverhältnisse und SLAs

Wenn es eine Unterbrechung gibt, üben Sie einfach das einfache alte Datenverwaltung. Datenverwaltung ist der Wartungsaspekt von Datenoperationen. Das ist zwar wichtig, aber nicht strategisch. Im Wartungsmodus sucht man nach der Ursache für eine fehlende Spalte oder einen Pipelinefehler und behebt das Problem, hat aber keine Zeit für Planung und Verbesserung.

Ihre Arbeit wird zu echten „Operationen“, wenn Sie Problemtickets in wiederholbare Lösungen umwandeln. Nehmen wir an, Sie entdecken einen Transformationsfehler bei einem Partner und kontaktieren diesen per E-Mail, um ihn beheben zu lassen, bevor er in Ihre Pipeline gelangt. Oder Sie implementieren ein „Warnbanner“ auf dem Dashboard Ihrer Führungskräfte, das sie darüber informiert, wenn etwas nicht stimmt, damit sie wissen, dass sie auf die Aktualisierung warten müssen. Datenoperationen zielen, genau wie Entwickleroperationen, darauf ab, wiederholbare, testbare, erklärbare und intuitive Systeme einzuführen, die letztendlich den Aufwand für alle reduzieren.

Das ist der Unterschied zwischen Datenoperationen und Datenverwaltung. Die Frage lautet also: Wie sollte dieses Datenoperationsteam strukturiert sein?

Lassen Sie uns also zum Anfang zurückkehren und darüber sprechen, wie Ihre Systemausgaben Ihre Organisationsstruktur widerspiegeln. Wenn Ihr Data Operations Team nur dem Namen nach ein „Operations“ -Team ist und größtenteils nur Wartungsarbeiten durchführt, werden Sie wahrscheinlich einen ewig wachsenden Rückstand an Anfragen erhalten. Sie werden selten Zeit haben, sich Zeit für langfristige Wartungsarbeiten zu nehmen, wie zum Beispiel den Austausch eines Systems oder die Anpassung eines Prozesses. Sie stecken in der Jira- oder ServiceNow-Antworthelle fest.

Wenn Sie hingegen Ihr Datenoperationsteam mit starken Prinzipien und einer klaren Struktur gegründet (oder neu aufgestellt) haben, produzieren Sie Daten, die Ihre hohe interne Qualität widerspiegeln. Gute Strukturen von Datenverarbeitungsteams produzieren gute Daten.

Bringen Sie einen Data Engineer, einen Data Scientist und einen Analysten in einer Gruppe oder einem Pod zusammen und lassen Sie sie gemeinsam Dinge angehen, die sie sonst vielleicht getrennt angegangen wären. Diese drei Perspektiven führen ausnahmslos zu besseren Entscheidungen, weniger Unentschlossenheit und mehr Weitsicht. Anstatt dass der Data Scientist beispielsweise ein sinnloses Notebook schreibt und es dann an den Ingenieur weitergibt, was zu einer endlosen Rücksprache führt, können sie und der Analyst besprechen, was sie benötigen, und der Ingenieur kann erklären, wie es umgesetzt werden soll.
Viele Datenverarbeitungsteams arbeiten bereits auf diese Weise. "Teams sollten darauf abzielen, als 'Full-Stack' besetzt zu sein, damit das notwendige Data-Engineering-Talent verfügbar ist, um den gesamten Lebenszyklus der Daten langfristig zu betrachten", sagen Krishna Puttaswamy und Suresh Srinivas von Uber. Und am Reisestandort Agoda verwendet das Ingenieurteam aus demselben Grund Pods.

Tun Sie dies auch, wenn Sie nur eine Person sind. Jede Rolle ist ein „Hut“, den jemand tragen muss. Für ein leistungsstarkes Datenoperationsteam ist es hilfreich zu wissen, wer welche Rolle innehat und wer für welche Daten verantwortlich ist. Außerdem müssen Sie die Kontrollbefugnisse jedes Einzelnen auf ein überschaubares Maß reduzieren. Vielleicht hilft Ihnen diese detaillierte Darstellung dabei, Ihre Argumente für die Einstellung zu untermauern.

Was ist Datenbetriebsmanagement? Eine Koordinationsebene oberhalb Ihrer Pod-Strukturen, die die Rolle des dienenden Leiters übernimmt. Sie leiten Projekte, coachen und entblocken. Idealerweise sind sie die kompetentesten Personen im Team.

Wir haben unsere eigene ideale Struktur entwickelt, wie abgebildet, obwohl sie noch in Arbeit ist. Wichtig ist, dass es eine einzige Person gibt, die eine Vision für die Daten hat (der VP). Unter ihnen befinden sich mehrere Führungskräfte, die verschiedene Datenfunktionen auf diese Vision ausrichten (die Direktoren), und unter ihnen, interdisziplinäre Teams, die sicherstellen, dass Datenorganisation und Datenfunktionen zusammenarbeiten. (Dank an unseren Data Solution Architect Michael Harper für diese Ideen.)

Die Wahl einer übergeordneten Metrik hilft allen Beteiligten zu verstehen, worauf sie hinarbeiten sollen. Ohne eine solche Vereinbarung kommt es zu Streitigkeiten. Vielleicht beschweren sich Ihre internen Daten- „Kunden“ darüber, dass die Daten langsam sind. Aber der Grund, warum es langsam ist, ist, weil Sie wissen, dass ihr unausgesprochener Wunsch darin besteht, zuerst die Qualität zu optimieren.

Gemeinsame Leitprinzipien von DataOps: Datenqualität, Automatisierung (wiederholbare Prozesse) und Prozessdezentralisierung (auch bekannt als Selbstständigkeit der Endbenutzer).

Sobald Sie einen Nordstern haben, können Sie auch über untergeordnete Metriken oder Prinzipien entscheiden, die auf diesen Nordstern hinweisen, der fast immer ein nachlaufender Indikator ist.

Organisieren Sie das Team so, dass die verschiedenen Gruppen innerhalb des Teams häufig miteinander interagieren und andere Gruppen um Dinge bitten müssen. Diese Interaktionen können sich als sehr wertvoll erweisen. „Wenn die Data Scientists und Ingenieure lernen, wie der jeweils andere arbeitet, sind diese Teams schneller und produktiver“, sagt Amir Arad, Senior Engineering Manager bei Agoda.

Amir sagt, er findet, dass einer der verborgenen Werte einer kleinen funktionsübergreifenden Redundanz darin besteht, dass Sie Leute dazu bringen, Fragen zu stellen, an die niemand in diesem Team gedacht hat.

„Die technische Wissenslücke ist eigentlich ziemlich cool.“ „Sie kann dazu führen, dass sie uns auffordern, es zu vereinfachen“, sagt Amir. „Sie könnten sagen: ‚Aber warum können wir das nicht tun?‘“ Und manchmal gehen wir zurück und stellen fest, dass wir diesen Code oder diesen Server gar nicht brauchen. Manchmal bringen Nicht-Experten neue Dinge auf den Tisch.“

Genau wie bei DevOps sind die besten Datenbetriebsteams unsichtbar und arbeiten ständig daran, sich selbst überflüssig zu machen. Anstatt den Helden zu spielen, der gerne alle spart, aber letztendlich das System anfällig macht, sollten Sie den dienenden Anführer spielen. Ziel ist es, wie Lao Tzu es ausdrückte, die Menschen so zu der Lösung zu führen, dass sie denken: „Wir haben es selbst gemacht.“

Behandeln Sie Ihr Data Operations Team wie ein Produktteam. Studieren Sie Ihren Kunden. Führen Sie eine Liste mit ausstehenden Fixes. Ziel ist es, das Tool so nützlich zu machen, dass die Daten auch tatsächlich genutzt werden.

Für Datenmonitoring und Observability gibt es kein „zu früh“. Die Analogie, die oft als Entschuldigung für das Aufschieben der Überwachung herangezogen wird, lautet: „Wir bauen das Flugzeug im Flug.“ Denken Sie über dieses Bild nach. Sagt Ihnen das nicht alles, was Sie über Ihr langfristiges Überleben wissen müssen? Eine viel bessere Analogie ist die schlichte alte Architektur. Je länger Sie mit der Errichtung eines Fundaments warten, desto teurer wird es und desto mehr Probleme entstehen durch das Fehlen eines solchen.

Lesen Sie: Was ist Daten-Observability?

Die Entscheidungen, die Sie jetzt mit Ihrer Dateninfrastruktur treffen, werden, wie General Maximus es ausdrückte, „ein Echo in der Ewigkeit“ sein. Der heutige Wachstumshack ist morgen schon ein gigantischer, datenverändernder Albtraum, der in internem Systemchaos mündet. Sie müssen sich die Unterstützung der Geschäftsleitung sichern, um unbequeme, aber richtige Entscheidungen zu treffen, indem Sie beispielsweise allen sagen, dass sie die Anfragen aussetzen müssen, weil Sie ein Quartal benötigen, um die Dinge zu reparieren.

CASE steht für „Copy and steal everything“ (kopiere und stehle alles), eine ironische Umschreibung für: Bau nicht alles von Grund auf neu. Es gibt heutzutage so viele nützliche Microservices und Open-Source-Angebote. Stelle dich auf die Schultern von Giganten und konzentriere dich darauf, die 40 % deiner Pipeline zu entwickeln, die tatsächlich individuell angepasst werden müssen – und das richtig gut.

Schauen Sie sich die Tickets in Ihrem Backlog an. Wie oft reagieren Sie auf Probleme, anstatt ihnen vorzubeugen? Bei wie vielen der von Ihnen behandelten Probleme ließ sich eine klar identifizierbare Ursache feststellen? Wie viele konnten Sie dauerhaft fixen? Je mehr Sie im Voraus planen, desto mehr ähneln Sie einem echten Datenoperationsteam. Und desto hilfreicher wird ein Tool zur Daten-Observability für Sie. Vollständige Transparenz kann Ihnen helfen, den Übergang von der reinen Instandhaltung zur aktiven Verbesserung zu vollziehen.

Teams, die ihre Struktur aktiv verbessern, verbessern aktiv auch ihre Daten. Interne Harmonie führt zu externer Harmonie – eine Verbindung, auf die Melvin Conway stolz sein würde.

Erfahren Sie mehr über die Plattform für kontinuierliche Daten-Observability von IBM und wie sie hilft, Datenvorfälle früher zu erkennen, schneller zu lösen und dem Unternehmen vertrauenswürdigere Daten zu liefern. Wenn Sie bereit sind, einen genaueren Blick zu werfen, buchen Sie noch heute eine Demo.