Wie konnte das passieren?
Der Vorstand war von den Vorteilen eines Data Mesh überzeugt: Dezentralisierung, Domänenautonomie, Datenprodukte, Self-Service und föderierte Governance. Data Mesh adressierte die wesentlichen Probleme der heutigen, zentralisierten Datenplattform, die im Unternehmen seit über 30 Jahren im Einsatz war. Diese gewachsene Struktur war schon lange nicht mehr flexibel genug, um den steigenden Anforderungen des Unternehmens gerecht zu werden.
Data Mesh klang nach der Zukunft, und die wollte das Unternehmen schließlich nicht verpassen. Es war nicht schwer die IT von der Idee zu begeistern. Nach einer kurzen Toolauswahl wurde umgehend in eine neue, hochmoderne Datenplattform investiert.
Doch nun begann der Ärger. Die so beglückten Fachbereiche wollten nichts von der neuen Plattform wissen. Ihnen ging es im Wesentlichen darum, dass alle Funktionen wieder so zur Verfügung standen, wie im alten System. Natürlich wäre eine bessere Datenqualität schön, aber warum sollten Sie für den Anfangs sogar nun geringeren Funktionsumfang nun mehr Arbeit aufwenden?
Die IT schaltete auf Stur und wollte nur die Anwendungsfälle ins neue System bringen, für die die Fachbereiche die Verantwortung übernehmen wollten. Alles andere sollte nach einer Übergangszeit abgeschaltet werden.
So fanden sich schließlich doch erste "Freiwillige", die sich bereit erklärten in den "sauren Apfel zu beißen". Doch, als die so motivierten begannen mehr Handlungsspielräume und Freiheiten einzufordern, zuckte man zurück. Das schöne neue System sollte vor Wildwuchs und unkontrollierbaren Handlungen geschützt werden - und so nahm das Unglück seinen Lauf.
Jeder blieb seiner alten Arbeitsweise treu, als wäre der Monolith nie gegangen. Wie konnte das passieren?
Data Mesh klang nach der Zukunft, und die wollte das Unternehmen schließlich nicht verpassen. Es war nicht schwer die IT von der Idee zu begeistern. Nach einer kurzen Toolauswahl wurde umgehend in eine neue, hochmoderne Datenplattform investiert.
Doch nun begann der Ärger. Die so beglückten Fachbereiche wollten nichts von der neuen Plattform wissen. Ihnen ging es im Wesentlichen darum, dass alle Funktionen wieder so zur Verfügung standen, wie im alten System. Natürlich wäre eine bessere Datenqualität schön, aber warum sollten Sie für den Anfangs sogar nun geringeren Funktionsumfang nun mehr Arbeit aufwenden?
Die IT schaltete auf Stur und wollte nur die Anwendungsfälle ins neue System bringen, für die die Fachbereiche die Verantwortung übernehmen wollten. Alles andere sollte nach einer Übergangszeit abgeschaltet werden.
So fanden sich schließlich doch erste "Freiwillige", die sich bereit erklärten in den "sauren Apfel zu beißen". Doch, als die so motivierten begannen mehr Handlungsspielräume und Freiheiten einzufordern, zuckte man zurück. Das schöne neue System sollte vor Wildwuchs und unkontrollierbaren Handlungen geschützt werden - und so nahm das Unglück seinen Lauf.
Jeder blieb seiner alten Arbeitsweise treu, als wäre der Monolith nie gegangen. Wie konnte das passieren?
Daten als Produkt
„Im Data Mesh wird jedes Datenteam sein eigenes Produkt entwickeln“, hieß es auf den schönen PowerPoint-Folien der Projektleitung. Jede Abteilung sollte die Verantwortung für ihre eigenen Datenprodukte übernehmen. Marketing, Finanzen, Logistik – alle sollten autonom arbeiten und ihre Daten wie wertvolle Produkte behandeln.
Das klang gut – bis die Realität zuschlug. Alle „Datenprodukte“ lagen zwar nun in einem eigenen Layer des neuen Systems, doch technische Änderungen an einem Datenprodukt durchzuführen traute man den Datenprodukt-Verantwortlichen nicht zu.
"Wenn wir mehr Data Engineers und Data Science Experten im Unternehmen hätten, würden wir ja mehr Autonomie zulassen." erklärte der BI Verantwortliche. So verwalten wir die knappen Ressourcen lieber zentral.
Das ein wesentliches Ziel zu Beginn der Data Mesh Initiative war mehr Menschen zu befähigen mit Daten umzugehen, um die Abhängigkeit von einem zentralen Team zu reduzieren war in Vergessenheit geraten...
Das klang gut – bis die Realität zuschlug. Alle „Datenprodukte“ lagen zwar nun in einem eigenen Layer des neuen Systems, doch technische Änderungen an einem Datenprodukt durchzuführen traute man den Datenprodukt-Verantwortlichen nicht zu.
"Wenn wir mehr Data Engineers und Data Science Experten im Unternehmen hätten, würden wir ja mehr Autonomie zulassen." erklärte der BI Verantwortliche. So verwalten wir die knappen Ressourcen lieber zentral.
Das ein wesentliches Ziel zu Beginn der Data Mesh Initiative war mehr Menschen zu befähigen mit Daten umzugehen, um die Abhängigkeit von einem zentralen Team zu reduzieren war in Vergessenheit geraten...
So mussten die Domänen ihre Anforderungen in altbewährte Change-Requests formulieren. Einmal eingereicht, durchlief jede Anpassung den klassischen „Wir-prüfen-das-in-unserem-nächsten-Bi-Weekly-Meeting“-Prozess. Nach Freigabe plante der zentrale IT-Dienstleister die Änderungen dann in seinen monatlichen Releasezyklus ein.
„Es funktioniert wie ein Data Mesh, nur ohne diese nervigen Freiheiten“, scherzte ein frustrierter Product Owner.
Domain Ownership
Die Idee, dass die Domänen im neuen Data Mesh-Ansatz die Verantwortung für ihre Daten übernehmen sollten, stieß folglich nicht auf die erwartete Begeisterung. Statt echter Dezentralisierung, behielt die zentrale IT weiterhin die Kontrolle über alle Entwicklungen im System. „Wir müssen ja sicherstellen, dass keine Abteilung irgendwelche Änderungen macht die zu Inkonsistenzen führen“, erklärte der IT-Leiter. Zu diesem Zweck wurden neue Gremien geschaffen, an denen immer alle Data Product Owner teilnehmen mussten, damit alle "im Loop" bleiben.
„Wir hatten bisher nie die Möglichkeit, die Datenqualität wirklich zu beeinflussen“, murmelte der Leiter der Marketingabteilung in einem dieser Governance-Meetings. „Und daran hat sich im neuen System auch nichts geändert. Die meisten Daten produzieren wir ja nicht selbst, sondern wir bekommen sie aus Quellen, auf die wir als Owner gar keinen Einfluss nehmen können."
So konnten sie zwar aufwändig testen, ob die gelieferten Daten brauchbar waren, aber das war es dann auch. So saßen die Domänen auf einem Datenberg, den sie nicht wirklich steuern konnten, und mussten zusehen, wie die IT weiterhin den Schlüssel zum Datenzugang fest in der Hand hielt.
„Wir hatten bisher nie die Möglichkeit, die Datenqualität wirklich zu beeinflussen“, murmelte der Leiter der Marketingabteilung in einem dieser Governance-Meetings. „Und daran hat sich im neuen System auch nichts geändert. Die meisten Daten produzieren wir ja nicht selbst, sondern wir bekommen sie aus Quellen, auf die wir als Owner gar keinen Einfluss nehmen können."
So konnten sie zwar aufwändig testen, ob die gelieferten Daten brauchbar waren, aber das war es dann auch. So saßen die Domänen auf einem Datenberg, den sie nicht wirklich steuern konnten, und mussten zusehen, wie die IT weiterhin den Schlüssel zum Datenzugang fest in der Hand hielt.
„Verantwortung ohne Kontrolle – das ist wie Autofahren mit verbundenen Augen“, schloss ein frustrierter Analyst.
Moderne Governance
Die Krönung der unternehmensweiten Data Mesh-Transformation sollte der neue Governance-Ansatz werden. Jede Domäne installierte einen Data Steward, der für die Datenprozesse, die Datenqualität, Qualitätsmetriken und Governance-Regeln zuständig sein sollte. Auf dem Papier sah das beeindruckend aus: Die Stewards würden für klare Verantwortlichkeiten sorgen und die Qualität der Daten endlich auf ein neues Niveau heben. Doch wie so oft in der Praxis lief das Ganze anders.
Weil als primäres Ziel der Data Stewards die Verbesserung der Datenqualität war, hatten sie an der eigentlichen Kernidee eines Data Mesh kein Interesse – nämlich den Anwendern mehr Autonomie zu geben und sie in die Lage zu versetzen, ihre eigenen Datenprodukte zu verwalten. Stattdessen wurde der Steward schnell zur Anlaufstelle für alle Datenprobleme und damit auch zum Sündenbock, wenn etwas schiefging.
„Wir sollen die Qualität verbessern, aber die Verantwortung für Datenfehler gleich mittragen“, murmelte ein Steward frustriert, während er das neueste Beschwerdeformular durchging.
„Wir sollen die Qualität verbessern, aber die Verantwortung für Datenfehler gleich mittragen“, murmelte ein Steward frustriert, während er das neueste Beschwerdeformular durchging.
Um sich gegen diese Verantwortung zu wappnen, entwickelten die Stewards eine Art Verteidigungsstrategie:
Immer mehr Rollen und Verantwortlichkeiten wurden geschaffen (Änderung), um die Last auf möglichst viele Schultern zu verteilen. Keiner der Stewards wollte am Ende allein für alle Datenprobleme verantwortlich gemacht werden.
Immer mehr Rollen und Verantwortlichkeiten wurden geschaffen (Änderung), um die Last auf möglichst viele Schultern zu verteilen. Keiner der Stewards wollte am Ende allein für alle Datenprobleme verantwortlich gemacht werden.
So entstand eine neue Struktur – eine Art dezentrale Bürokratie, die frappierend an die alte, zentralisierte Monolith-Struktur erinnerte. „Wir haben jetzt zwar Data Mesh, aber die Freiheiten, die uns versprochen wurden, sind irgendwo in den vielen Rollenbeschreibungen verloren gegangen“, bemerkte ein Steward sarkastisch.
Das Data Mesh Theater
Das Unternehmen hatte technologisch alles richtig gemacht: Eine moderne Datenplattform wurde aufgebaut, und die Voraussetzungen für Data Mesh waren geschaffen. Doch in den Köpfen und Prozessen der Organisation blieb alles beim Alten. Die IT und das zentrale Governance-Team behielten weiterhin die volle Kontrolle, und die Domänen-Teams fanden sich in den gleichen langsamen Prozessen wie zu Monolith-Zeiten wieder.
„Es fühlt sich an, als hätten wir uns auf eine Reise zur digitalen Zukunft begeben, aber sind im selben alten Büro geblieben“, fasste der Chief Data Officer das Dilemma zusammen.
Fazit: Moderne Technologie allein macht keine erfolgreiche Transformation. Selbst die fortschrittlichste Datenplattform bringt nichts, wenn Organisationen weiterhin an alten Prozessen und zentralen Strukturen festhalten. Der wahre Wandel findet in der Arbeitsweise und der Kultur statt – nicht in der Technologie.
Erstellt mit
