Datenarchitektur und Organisation

Kurzfassung

Datenarchitektur ist der Bauplan, nach dem eine Organisation ihre Daten für Auswertungen sammelt, speichert, verbindet und bereitstellt. Zu ihr gehört immer auch die Frage, wer für welche Daten zuständig ist. Die bekannten Ansätze beantworten zwei Fragen verschieden: wo die Daten technisch liegen und ob ein zentrales Team oder die Fachbereiche sie verantworten. Data Warehouse, Data Lake, Lakehouse und Data Fabric sind vor allem Antworten auf die erste Frage, Data Mesh ist vor allem eine Antwort auf die zweite. Besonders dringlich wird die zweite Frage, wenn ein zentrales Datenteam zum Engpass wird oder Fachbereiche ihre Daten anders verstehen als die Zentrale.

Am besten belegt ist der Zusammenhang, der beide Fragen verbindet: Technische Systeme bilden häufig die Kommunikationsstruktur der Organisation ab, die sie baut (Conways Gesetz). Untersucht ist das vor allem an Software, nicht an Datenarchitekturen. Ob ein bestimmter Ansatz zu besseren Daten oder Entscheidungen führt, ist dagegen kaum untersucht. Die Belege bestehen überwiegend aus Fallberichten, Herstellerangaben und Analystenurteilen.

Gestritten wird darüber, ob die Verantwortung für Daten zentral gebündelt oder auf die Fachbereiche verteilt werden soll, ob Data Mesh eine Architektur oder ein Organisationsmodell ist und wie viel an neuen Begriffen wie Lakehouse oder Data Fabric Vermarktung ist.

Was Datenarchitektur ist und welche Formen es gibt

Organisationen arbeiten mit zwei Arten von Systemen. In operativen Systemen wie Warenwirtschaft, Buchhaltung oder Kundenverwaltung entstehen Daten im laufenden Geschäft. Für Auswertungen werden sie zusammengeführt, bereinigt und in eine Form gebracht, die Vergleiche über Bereiche und Zeiträume erlaubt. Datenarchitektur meint hier die Struktur dieser analytischen Seite. Der Begriff ist doppeldeutig: Mal bezeichnet er nur Technik wie Speicher, Formate und Ladeprozesse, mal auch Rollen und Zuständigkeiten. Data Mesh besteht ausdrücklich darauf, dass beides zusammengehört.

Data Warehouse. Ein Data Warehouse ist eine zentrale Datenbank für Auswertungen, in die Daten aus den operativen Systemen regelmäßig geladen werden. Die IBM-Mitarbeiter Barry Devlin und Paul Murphy beschrieben 1988 eine solche Architektur. Der amerikanische Informatiker Bill Inmon definierte das Data Warehouse 1992 als themenorientierte, integrierte, zeitbezogene und nicht flüchtige Datensammlung zur Unterstützung von Managemententscheidungen. Er sah ein unternehmensweit einheitlich modelliertes Warehouse vor, aus dem kleinere Data Marts für einzelne Bereiche gespeist werden. Der Datenbankfachmann Ralph Kimball ging 1996 den umgekehrten Weg: Data Marts je Geschäftsprozess, modelliert als Sternschema, also eine Tabelle mit Messwerten wie Umsatz, umgeben von beschreibenden Dimensionen wie Kunde, Produkt und Zeit. Gemeinsam genutzte Dimensionen verbinden die Data Marts. In beiden Schulen wird die Struktur festgelegt, bevor Daten geladen werden (schema on write), und ein zentrales Team übernimmt die Integration.

Data Lake. James Dixon, damals Technikchef des Softwareanbieters Pentaho, prägte den Begriff 2010. Er verglich einen Data Mart mit abgefülltem Wasser, gereinigt und verpackt, und einen Data Lake mit einem Gewässer im natürlichen Zustand, in das Quellen strömen und aus dem jeder schöpfen kann. Ein Data Lake speichert Rohdaten in beliebigen Formaten, oft günstig auf verteilten Dateisystemen wie Hadoop. Die Struktur wird erst beim Auswerten festgelegt (schema on read). Gartner warnte 2014 vor dem Trugschluss, Daten würden schon dadurch nutzbar, dass sie an einem Ort liegen. Ohne Beschreibungen der Daten (Metadaten) und Regeln für ihre Verwaltung wird aus dem See ein Sumpf (data swamp).

Lakehouse. Michael Armbrust, Ali Ghodsi, Reynold Xin und Matei Zaharia beschrieben 2021 das Lakehouse. Die Daten liegen wie im Data Lake in offenen Dateiformaten auf günstigem Speicher, darüber liegen Funktionen eines Warehouse wie Transaktionen, feste Schemata und schnelle Abfragen. Die Autoren arbeiteten bei Databricks, das eine solche Plattform verkauft.

Data Mesh. Zhamak Dehghani, damals Technologieberaterin bei Thoughtworks, schlug 2019 vor, die Verantwortung für analytische Daten nicht mehr bei einem zentralen Team zu bündeln, sondern bei den Fachbereichen, in denen die Daten entstehen (Domänen). Ihr Buch von 2022 nennt vier Prinzipien: Domänenverantwortung (domain ownership); Daten als Produkt, das andere verlässlich nutzen können (data as a product); eine Self-Service-Plattform, die den Domänen die Technik abnimmt; und eine föderierte Governance, bei der Vertreter der Domänen gemeinsame Regeln beschließen, die möglichst automatisch durchgesetzt werden. Data Mesh ist damit ausdrücklich ein soziotechnischer Ansatz und keine Software. Was Zuständigkeit für Daten heißt, behandelt Data Ownership, wie sich Zusagen zwischen Anbietern und Nutzern von Daten festhalten lassen, Data Contracts.

Data Fabric. Data Fabric bezeichnet eine Integrationsschicht, die Daten in den verteilten Quellen belässt und über Metadaten, Kataloge und automatisierte Integration zugänglich macht. Das Analystenhaus Gartner zählte Data Fabric zu den strategischen Technologietrends für 2022. Data Fabric verteilt die Daten, legt aber nicht fest, wer für sie verantwortlich ist.

Nutzen und Beleglage

Welcher Ansatz zu besseren Daten oder Entscheidungen führt, ist kaum belastbar untersucht. Am besten belegt ist nicht ein einzelner Ansatz, sondern der Zusammenhang zwischen Organisation und Systemstruktur.

Vergleichsstudien zu Organisation und Systemstruktur. Der Informatiker Melvin Conway formulierte 1968 die Beobachtung, dass Systeme die Kommunikationsstruktur der Organisation abbilden, die sie entwirft. Forschende um Alan MacCormack und Carliss Baldwin (Harvard Business School) verglichen 2012 Paare von Softwareprodukten mit ähnlichem Zweck: eines jeweils von einer lose verbundenen, verteilten Gemeinschaft entwickelt, das andere von eng zusammenarbeitenden Teams eines Unternehmens. In allen Paaren war das Produkt der verteilten Gemeinschaft modularer. Lyra Colfer und Carliss Baldwin werteten 2016 142 empirische Studien zu dieser Spiegelungshypothese (mirroring hypothesis) aus. In Branchen- und Unternehmensstudien war die Entsprechung ein verbreitetes, aber kein universelles Muster; Studien zu offenen, gemeinschaftlichen Projekten stützten sie nicht. Die Studien betreffen Produkte und Software allgemein, nicht Datenarchitekturen. Dass der Zusammenhang dort ebenso gilt, ist eine plausible Übertragung, keine eigene Messung.

Befragungen zu Data-Warehouse-Architekturen. Die Wirtschaftsinformatiker Thilini Ariyachandra und Hugh Watson verglichen 2006 in einer Befragung von Unternehmen fünf Architekturtypen. Die Bus-Architektur nach Kimball, die Nabe-und-Speichen-Architektur nach Inmon und ein zentrales Warehouse schnitten bei den meisten Erfolgsmaßen ähnlich ab, unabhängige, nicht verbundene Data Marts schlechter. Die Maße beruhen auf Einschätzungen der Befragten.

Praxisstudien zu Data Mesh. Die Belege zu Data Mesh bestehen bislang vor allem aus Erfahrungsberichten früher Anwender. Eine Interviewstudie von Jan Bode und Kollegen am Karlsruher Institut für Technologie (2023) beschreibt Beweggründe, Hürden und bewährte Vorgehensweisen. Abel Goedegebuure und Kollegen werteten 2023 systematisch die graue Literatur aus, also Blogbeiträge, Vorträge und Whitepaper. Dass sich eine Übersichtsarbeit darauf stützen muss, zeigt den Stand: Vergleiche von Organisationen mit und ohne Data Mesh fehlen.

Analystenurteile. Gartner ordnete Data Mesh 2022 in seinem Hype Cycle für Datenmanagement als „obsolet, bevor es das Plateau erreicht“ ein, bei geringer Marktdurchdringung und geringem bisher realisiertem Nutzen. Nach einer Gartner-Umfrage von 2021 hatten nur 18 % der Organisationen die Reife in der Daten-Governance, die Data Mesh voraussetzt. Gartner erwartet, dass mit wachsender Reife wieder stärker zentrale Ansätze Zuspruch finden könnten. Solche Einordnungen sind Urteile von Fachleuten, keine Messungen.

Worauf die Ansätze beruhen

Zentrale und verteilte Ansätze setzen Verschiedenes voraus, und keine der Voraussetzungen ist selbstverständlich.

Zentrale Ansätze wie Warehouse, Data Lake und Lakehouse setzen voraus, dass ein zentrales Team die Bedeutung der Daten aus allen Bereichen versteht, dass sich die Bereiche auf gemeinsame Definitionen einigen, etwa was als Kunde oder als Umsatz zählt, und dass das Team mit der Nachfrage mitwächst. Das ist eher gegeben, wo es wenige und stabile Quellen gibt, wo einheitliche Berichte verlangt werden, etwa gegenüber Aufsichtsbehörden, und wo die Organisation überschaubar ist.

Verteilte Ansätze wie Data Mesh setzen voraus, dass die Fachbereiche Fachleute für Daten und Zeit haben, Daten für andere aufzubereiten (Datenkompetenz). Sie brauchen zudem einen Grund dafür, denn den Aufwand hat, wer die Daten pflegt, den Nutzen haben oft andere. Eine gemeinsame Plattform muss das Bereitstellen billig machen, und die gemeinsamen Regeln müssen verbindlich genug sein, dass Datenprodukte verschiedener Domänen zusammenpassen. Dehghani selbst beschreibt den Ansatz für große Organisationen mit vielen Domänen und komplexer Datenlandschaft, nicht für kleine mit wenigen Quellen.

Data Fabric ist breit eingetragen, weil der Ansatz die Zuständigkeit offenlässt. Technisch verteilt er die Daten stärker als ein Warehouse, organisatorisch nicht zwingend.

Conways Gesetz als Bindeglied. Wer nur die Architektur ändert, ohne die Organisation zu ändern, muss nach Conways Gesetz damit rechnen, dass die alte Struktur zurückkehrt. Ein Data Mesh, dessen Datenprodukte weiterhin das zentrale Team baut, ist der Sache nach eine zentrale Plattform mit neuen Bezeichnungen. Umgekehrt nützt Domänenverantwortung wenig, wenn die Fachbereiche keine Plattform haben, über die sie Daten bereitstellen können. Die Teams bewusst so zu schneiden, wie die Architektur aussehen soll, ist als umgekehrtes Conway-Manöver bekannt.

Herkunft, Schulen und Streitfragen

Die Ansätze lösten einander nicht ab, sondern kamen hinzu. Jeder grenzte sich ausdrücklich von einem Vorgänger ab: Kimball von Inmons Unternehmensmodell, Dixon von den Data Marts, das Lakehouse vom Nebeneinander aus Data Lake und Warehouse, Dehghani schon im Titel ihres Aufsatzes vom „monolithischen“ Data Lake.

Hervorgehoben ist Data Mesh, weil es als erster der hier genannten Ansätze bei der Verantwortung ansetzt und nicht beim Speicherort.

Inmon oder Kimball? Über Jahre war das die Grundsatzfrage der Warehouse-Praxis: erst ein einheitliches Unternehmensmodell oder schnell nutzbare, nach und nach verbundene Data Marts. Die Befragung von Ariyachandra und Watson spricht dafür, dass der Streit weniger folgenreich war als die Frage, ob Data Marts überhaupt verbunden werden.

Zentral oder verteilt? Dehghani argumentiert, ein zentrales Datenteam werde in großen Organisationen zum Engpass und sei zu weit von der Bedeutung der Daten entfernt, die in den Fachbereichen entstehen. Gartner hält dagegen, dass die meisten Organisationen die nötige Reife nicht haben. Beide Seiten stützen sich auf Erfahrung und Argumente, nicht auf Vergleichsdaten.

Architektur oder Organisationsmodell? Data Mesh schreibt keine bestimmte Technik vor; neu ist vor allem die Zuordnung der Verantwortung. Daraus folgt, dass sich Data Mesh nicht als Produkt kaufen lässt. Werkzeuge können die Plattform liefern, nicht die Zuständigkeiten.

Wie viel ist Vermarktung? Das Lakehouse wurde von Gründern eines Anbieters beschrieben, der eine solche Plattform verkauft, Data Fabric von Gartner als Technologietrend herausgestellt. Das macht die Ansätze nicht falsch. Es bedeutet aber, dass ein großer Teil der Belege von Beteiligten stammt, die ein Interesse an neuen Kategorien haben.

Grenzen und Kritik

• Dünne Beleglage. Was über Data Mesh und die neueren Ansätze bekannt ist, stammt vor allem aus Berichten früher Anwender, und veröffentlicht wird eher, was gelungen ist (Survivorship Bias). Für Organisationen mit wenigen Datenfachleuten gibt es kaum Erfahrungswerte.
• Technik statt Zuständigkeit. Unklare Definitionen, fehlende Verantwortung und widersprüchliche Anreize können in jeder Architektur fortbestehen. Ein Wechsel der Plattform kann sie sichtbarer machen, löst sie aber nicht. Zugespitzt vertritt das die Perspektive Datenqualität ist ein Organisationsproblem.
• Kosten beider Richtungen. Verteilung bringt Doppelarbeit, abweichende Definitionen und den Bedarf an Datenfachleuten in jeder Domäne. Zentralisierung bringt Warteschlangen und Abstand zur Bedeutung der Daten. Keine Richtung ist umsonst.
• Begriffe wandern schneller als Praxis. Dieselbe Plattform kann je nach Jahr und Anbieter Data Lake, Lakehouse oder Data Mesh heißen. Was eine Organisation tatsächlich tut, zeigt sich an Zuständigkeiten und Abläufen, nicht am Etikett.
• Conways Gesetz ist eine Tendenz, kein Naturgesetz. Die Übersicht von Colfer und Baldwin zeigt Ausnahmen, besonders dort, wo digitale Werkzeuge die Abstimmung über Grenzen hinweg erleichtern. Das Bindeglied zwischen Organisation und Architektur ist damit gut begründet, aber schwächer, als es in Architekturdebatten oft klingt.

Die Wahl einer Datenarchitektur ist damit immer auch eine Entscheidung darüber, wer in einer Organisation die Bedeutung von Daten festlegt und wer den Aufwand dafür hat. Welche Verteilung unter welchen Bedingungen besser funktioniert, ist empirisch offen.

Quellen

• Devlin, B. A. & Murphy, P. T. (1988): An Architecture for a Business and Information System. IBM Systems Journal 27(1), 60–80.
• Inmon, W. H. (1992): Building the Data Warehouse. 1. Auflage.
• Kimball, R. (1996): The Data Warehouse Toolkit. Wiley.
• Dixon, J. (2010): Pentaho, Hadoop, and Data Lakes. Blogbeitrag. Einordnung: Wikipedia: Data lake.
• Gartner (28.07.2014): Gartner Says Beware of the Data Lake Fallacy. Pressemitteilung.
• Armbrust, M., Ghodsi, A., Xin, R. & Zaharia, M. (2021): Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. CIDR 2021.
• Dehghani, Z. (2019): How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh. martinfowler.com.
• Dehghani, Z. (2022): Data Mesh: Delivering Data-Driven Value at Scale. O’Reilly.
• Gartner (2021): Top Strategic Technology Trends for 2022. Darin: Data Fabric.
• Atlan: Gartner on Data Mesh. Zusammenfassung des Gartner Hype Cycle for Data Management 2022 und der Gartner-Umfrage von 2021.
• Conway, M. E. (1968): How Do Committees Invent? Datamation 14(4), 28–31.
• MacCormack, A., Rusnak, J. & Baldwin, C. Y. (2012): Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis. Research Policy 41(8), 1309–1324.
• Colfer, L. J. & Baldwin, C. Y. (2016): The Mirroring Hypothesis: Theory, Evidence, and Exceptions. Industrial and Corporate Change 25(5), 709–738.
• Ariyachandra, T. & Watson, H. J. (2006): Which Data Warehouse Architecture Is Most Successful? Business Intelligence Journal 11(1). Kurzfassung: (2008) Which Data Warehouse Architecture Is Best? Communications of the ACM 51(10).
• Bode, J., Kühl, N., Kreuzberger, D. et al. (2023): Data Mesh: Motivational Factors, Challenges, and Best Practices. arXiv.
• Goedegebuure, A. et al. (2023): Data Mesh: A Systematic Gray Literature Review. arXiv.