ELT auseinandernehmen: Wenn man keinen Silo, sondern einen Graphen braucht

• ELT (Extract, Load, Transform) wird genutzt, um die „Silos“ zwischen Datenanalyse und Softwareentwicklung in einer Organisation zu verbinden, doch genau diese Silo-Struktur ist die eigentliche Ursache des Problems

• ELT ist nur eine Brücke zwischen Silos. Eine Welt ohne Silos ist ein „Graph“

Die Grenzen der ELT-Denkweise

• In einer Welt der Silos, in der sich in einem Silo die Software und in einem anderen die Datenanalyse befindet, ist ELT sehr sinnvoll
• ELT funktioniert unter der Voraussetzung einer Silo-Struktur
  • Die Arbeit des „Extrahierens (Extract)“ entsteht in einer Situation, in der Softwareentwicklungsteams und Datenanalyseteams getrennt sind
  • Das Softwareteam interessiert sich nicht für die Arbeit des Datenteams, und das Datenteam extrahiert mit Datenbankberechtigungen einfach blind Daten
  • Erst nach der Extraktion werden technische Prinzipien wie Datenqualität und Modellierung angewendet, doch dann ist es bereits zu spät
• Conways Gesetz greift
  • „Die Entwürfe von Systemen, die Organisationen erstellen, ähneln den Kommunikationsstrukturen dieser Organisationen.“
• Wegen der Silo-Denkweise sind ETL/ELT/Reverse ETL ungeeignet, um die Komplexität moderner Datenarchitekturen zu bewältigen
  • Daten befinden sich heute nicht mehr nur in operativen und analytischen Systemen, sondern erstrecken sich auch auf einen dritten Datenraum, repräsentiert durch SaaS
  • Daten fließen zwischen Regionen und der Cloud sowie zwischen Backend und SaaS
  • Heute gibt es 100-mal mehr Anwendungen als früher; Organisationen werden softwaregetrieben, und das Beziehungsgeflecht zwischen Softwaresystemen wird immer komplexer

Warum eine Graph-Denkweise nötig ist

• Wenn Softwareteams und Datenteams harmonisch zusammenarbeiten, kann man statt eines Modells wie ELT, bei dem Daten extrahiert und gespeichert werden, zu einem Graph-Modell wechseln
  • Man stellt sich einen Graphen vor, der aus Knoten besteht, die Daten „konsumieren (Consume)“
  • Jeder Knoten produziert oder konsumiert Daten und bildet so ganz natürlich ein Netzwerk bzw. einen Graphen
• Vorteile der Graph-Denkweise:
  • weniger Datenextraktion, mehr Konsum
  • mehr Datenmodellierung rund um hochwertige Datensätze
  • weniger Datenbereinigung, Speicherung von Rohdaten und Behebung von Pipeline-Fehlern
  • Nutzung inkrementeller Verarbeitung und von Streaming-Quellen als Ersatz für Batch-Prozesse
  • Analytik bleibt nicht auf strategische Entscheidungswerkzeuge beschränkt, sondern erweitert sich auf operative Anwendungen
  • mehr Zusammenarbeit und Abstimmung zwischen Teams, weniger Silos

Fazit

• Die ELT-Denkweise ist ein Ergebnis von Conways Gesetz, das die Trennung zwischen Software- und Datenteams widerspiegelt
• Es ist nicht nötig, alle bestehenden ETL/ELT-Tools zu verwerfen, aber der Fokus sollte auf Datenkonsum und dem Aufbau vertrauenswürdiger abgeleiteter Datensätze liegen
• Realistisch gesehen ist Shift Left noch immer eher ein aspiratives Stadium, und bestehende Legacy-Infrastrukturen sowie Integrationsprobleme sind weiterhin vorhanden
  • Shift Left: eine Strategie zur Integration wichtiger Entwicklungspraktiken früh im Software Development Lifecycle (SDLC)
• Organisationen, die eine Graph-Denkweise annehmen, werden bei Datennutzung, AI-ROI und Geschäftsergebnissen die größten Vorteile erzielen

„Es gibt kein Extrahieren. Es gibt nur Konsumieren.“ – Daten-Yoda

[udopeanut]

Nachdem ich das Buch über Data Mesh gelesen habe, verstehe ich vieles besser.

[softer]

Ich arbeite kontinuierlich an Ideen rund um graphbasierte Entscheidungsfindung, und es wäre schön, wenn sich Menschen zusammenfinden könnten, die ähnlich denken.

[kimsk]

Der Begriff dafür ist also „Ideation“ – wieder etwas gelernt. Persönlich ist das ein Thema, das mich sehr interessiert. Es wäre wirklich schön, wenn wir uns versammeln könnten.

[jwseo]

Kann das vielleicht jemand etwas genauer erklären? Bedeutet der vom Autor beschriebene Ansatz, dass alle aus dem Graphen abgeleiteten Datensätze jeweils separat gespeichert und verwaltet werden? Wenn nicht, verstehe ich nicht ganz, worin der Unterschied zu ETL besteht.

[rlaehdus2003]

Es wird gesagt, dass die Struktur, in der der bestehende operative Bereich und der Analysebereich getrennt sind, das strukturelle Problem von Silos hat. Beim Aufbau einer Datenarchitektur sollten die beiden daher nicht getrennt betrachtet werden, sondern entlang von Datenerzeugern und Datenkonsumenten.

Da die Grenze zwischen operativen und analytischen Daten inzwischen unscharf wird, sei nun ein graphisches Denken (graph thinking bzw. graph mindset) erforderlich.

So wie ich es empfinde, geht es weniger um eine explizite Trennung von operativen und analytischen Daten, sondern eher darum, Datenkonsumenten und -erzeuger als Erweiterung der operativen Daten zu unterscheiden und den Datenzugriff aus der Perspektive des Datenflusses zu betrachten (auch wenn die Rollen getrennt sein mögen).

Es scheint aus Sicht der Datenarchitektur darum zu gehen, dass man mit operativen Daten analysiert, die Ergebnisse wieder in den operativen Bereich zurückfließen und von dort erneut in die Analyse gehen.