Wenn die Datenstrategie die Transformation blockiert: Warum agile Organisationen an ihrer eigenen Datenarchitektur scheitern
Die meisten agilen Transformationen stolpern nicht über fehlende Mindset-Workshops oder mangelnde Scrum-Kenntnisse. Sie stolpern über Daten. Genauer gesagt: über eine Datenarchitektur, die konzeptionell im Jahr 2008 steckengeblieben ist, während die Organisation drumherum versucht, sich in Richtung 2025 zu bewegen. Das ist die unbequeme Wahrheit, die in Retrospektiven selten auf dem Board landet — weil sie technisch klingt und niemand im Raum die Verantwortung übernehmen will.
Dabei ist die Verbindung zwischen Datenarchitektur und agiler Transformationsgeschwindigkeit empirisch gut belegt. Der McKinsey-Bericht "The data-driven enterprise of 2025" dokumentiert, dass Unternehmen mit modularen, domänenorientierten Datenstrukturen ihre Time-to-Market für neue Features um durchschnittlich 40 Prozent schneller realisieren als Wettbewerber mit monolithischen Data-Warehouses. Die agile Transformation ist also kein kulturelles Projekt, das irgendwann auf die Technologiefrage trifft. Sie ist von Anfang an beides — oder sie ist zum Scheitern verurteilt.
Dieser Artikel richtet sich an alle, die in Transformationsprozessen die Schnittstelle zwischen Organisationsdesign und technischer Infrastruktur gestalten: Agile Coaches, die merken, dass Teams trotz guter Ceremonies nicht liefern können. Product Owner, deren Backlogs von Datenabhängigkeiten blockiert werden. Führungskräfte, die in Steering Committees sitzen und verstehen wollen, warum die Velocity-Kurve trotz aller Investitionen stagniert.
Datenarchitektur als strategisches Führungsthema — nicht als IT-Problem
Die klassische Denktrennung lautet: Führung entscheidet über Strategie, IT liefert die Infrastruktur. Diese Trennung war schon immer eine Illusion — in agilen Kontexten ist sie schlicht dysfunktional. Wer Datenarchitektur als Enabler oder Blocker agiler Delivery begreift, muss sie als Führungsthema verankern.
Das zeigt sich besonders deutlich bei der Frage der Teamautonomie. Ein Kernversprechen agiler Organisationsdesigns — ob nach Spotify-Modell, SAFe oder LeSS — ist, dass Teams end-to-end Verantwortung für ihren Wertstrombeitrag übernehmen. Dieses Versprechen ist strukturell uneinlösbar, wenn Teams auf geteilte Datenbankinstanzen angewiesen sind, deren Schemaänderungen einen Change-Request-Prozess mit vier Wochen Vorlauf erfordern. Hier entsteht eine architektonische Heteronomie, die jede Team-Level-Autonomie aushebelt.
Die Lösung beginnt mit einem Reframing auf Leadership-Ebene: Datenarchitektur ist kein Infrastrukturthema, sondern ein Organisationsdesign-Thema. Conway's Law ist in diesem Zusammenhang nach wie vor die präziseste Diagnose: "Organisationen, die Systeme designen, produzieren Designs, die die Kommunikationsstrukturen dieser Organisation abbilden." Wer also monolithische Datenarchitekturen hat, hat mit hoher Wahrscheinlichkeit auch monolithische Entscheidungsstrukturen — und umgekehrt.
Aus dieser Erkenntnis folgt eine konkrete Führungsverantwortung: Architekturgrenzen müssen mit Teamgrenzen abgestimmt sein. Nicht perfekt, aber bewusst. Das bedeutet, dass CTO, Head of Data und agile Führung gemeinsam in einem Forum sitzen müssen — nicht in sequenziellen Abstimmungsrunden, sondern in echtem gemeinsamen Ownership. In der Praxis scheitert genau das häufig an Silo-Incentivierungen: Der CTO wird an Systemstabilität gemessen, der Transformation Lead an Rollout-Geschwindigkeit. Ohne geteilte OKRs über diese Domänen hinweg entsteht struktureller Konflikt.
Handlungsimpuls: Prüfe in deiner Organisation, ob es ein gemeinsames Artefakt gibt, das Teamtopologie und Datendomänen-Grenzen in Beziehung setzt. Fehlt dieses Artefakt, ist das ein Signal, nicht ein Detail.
Domain-Driven Design als konzeptuelle Brücke zwischen Agilität und Daten
Wenn es ein Konzept gibt, das die Welten agiler Organisationsgestaltung und moderner Datenarchitektur am überzeugendsten verbindet, dann ist es Domain-Driven Design (DDD) — insbesondere das Konzept der Bounded Contexts. Eric Evans' Kernidee, fachliche Domänen durch explizite Kontextgrenzen zu schützen, ist nicht nur ein Software-Design-Prinzip. Es ist ein Organisationsprinzip.
Im Kontext agiler Transformation bedeutet das: Jedes autonome Team — ob Squad, Feature-Team oder Produktteam — sollte, soweit möglich, Ownership über die Daten haben, die es zur Wertschöpfung benötigt. Daten-Ownership ist dabei kein technisches Konstrukt, sondern eine fachliche und organisatorische Vereinbarung. Das Team entscheidet über Schema, Qualitätsstandards und Zugriffspolitik für seinen Bounded Context. Andere Teams konsumieren diese Daten über definierte Schnittstellen — nicht durch direkten Datenbankzugriff.
Dieses Muster findet sich im Data-Mesh-Konzept von Zhamak Dehghani wieder, das in den letzten Jahren signifikante Aufmerksamkeit in datengetriebenen Organisationen gewonnen hat. Data Mesh überträgt die Prinzipien von Microservices — Dezentralisierung, klare Ownership, Self-Service — auf die Datenwelt. Die vier Prinzipien des Data Mesh (Domain Ownership, Data as a Product, Self-Serve Data Infrastructure, Federated Computational Governance) lesen sich fast wie ein agiles Manifest für Datenarchitektur.
Die konzeptuelle Brücke zur Team Topologies-Sprache ist dabei besonders erhellend: Stream-aligned Teams übernehmen Ownership für ihre Data Products. Platform Teams stellen die technische Infrastruktur für Self-Service bereit. Enabling Teams unterstützen beim Aufbau von Datenkompetenz. Diese Parallelität ist kein Zufall — sie reflektiert, dass gute Systemarchitektur und gutes Organisationsdesign denselben Grundprinzipien folgen: lose Kopplung, hohe Kohäsion, klare Verantwortlichkeiten.
In der Praxis empfiehlt sich eine Event-Storming-Session als Startpunkt: Gemeinsam mit fachlichen und technischen Stakeholdern werden Domänengrenzen identifiziert, Datenflüsse sichtbar gemacht und erste Ownership-Hypothesen formuliert. Der Output ist kein finales Architekturdesign, sondern ein gemeinsames mentales Modell — und das ist bereits ein enormer Fortschritt gegenüber dem Status quo.
Inkrementelle Datenmigration: Agile Prinzipien für Legacy-Architekturen
"Wir können nicht agil werden, solange wir auf unserem alten ERP-System sitzen" — dieser Satz fällt in Transformationsprojekten mit erschreckender Regelmäßigkeit. Er ist meistens falsch, aber er enthält einen wahren Kern: Legacy-Datenarchitekturen erzeugen reale Reibung. Die Frage ist nicht, ob man sie adressieren muss, sondern wie.
Die Antwort der meisten IT-Abteilungen lautet: Big-Bang-Migration. Ein großes Programm, ein definiertes Enddatum, ein neues System. Dieser Ansatz widerspricht jedem agilen Grundprinzip — er ist wasserfallartig, risikoreich und produziert in der Regel genau die Planungssicherheit, die er versprechen soll, nicht. Die Alternativen sind inkrementelle Migrationsstrategien, die sich an Prinzipien wie dem Strangler-Fig-Pattern orientieren.
Das Strangler-Fig-Pattern, ursprünglich von Martin Fowler beschrieben, ist eine elegante Metapher für inkrementelle Systemablösung: Neue Fähigkeiten werden im neuen System aufgebaut, während das Legacy-System sukzessive "erdrosselt" wird — Domäne für Domäne, Datenfluss für Datenfluss. Dieser Ansatz ermöglicht kontinuierliche Delivery, reduziert Migrationsrisiken und — entscheidend für agile Organisationen — erlaubt es Teams, frühzeitig in modernen Datenkontexten zu arbeiten, ohne auf die vollständige Migration zu warten.
Ein konkretes Beispiel: Ein mittelgroßer europäischer Retailer migrierte sein zentrales Produktdatenmanagement (PDM) über 18 Monate iterativ. Statt einer Gesamt-Migration wurden zunächst die Domänen mit der höchsten strategischen Relevanz (Online-Sortiment, Pricing) auf eine neue, event-getriebene Datenplattform gehoben. Die Bestandssysteme lieferten weiterhin an alle nicht-migrierten Domänen. Durch diesen Ansatz konnte das E-Commerce-Team bereits nach Monat vier eigenständig Features in Produktion bringen, die zuvor an Legacy-Abhängigkeiten gescheitert wären. Die geschätzte Time-to-Market-Verbesserung für digitale Produktfeatures: 60 Prozent.
Für Agile Coaches und Transformation Leads gilt: Fragt in euren Kickoffs aktiv nach den Datenabhängigkeiten eurer Teams. Welche Daten brauchen Teams, die sie aktuell nicht eigenständig produzieren oder verändern können? Wo entstehen Wartezeiten durch Daten-Handover? Diese Fragen machen Migrationsprioritäten sichtbar — und damit steuerbar.
Fallstudie: Wie ING die Datenarchitektur als Transformation-Enabler nutzte
ING ist in der agilen Szene vor allem für seine radikale Umstrukturierung in Squads und Tribes bekannt, die ab 2015 begann und als Blaupause für viele nachfolgende Transformationen diente. Weniger diskutiert wird, wie parallel dazu die Datenarchitektur umgebaut wurde — und wie entscheidend dieser Umbau für den Erfolg der Transformation war.
Die Ausgangslage war typisch für ein Großunternehmen mit Jahrzehnten IT-Geschichte: fragmentierte Datenpools, dezentrale Datenhaltung in Länderorganisationen, heterogene Technologiestacks ohne einheitliche Datenzugriffsstandards. Squads waren organisatorisch autonom, konnten diese Autonomie aber nur begrenzt realisieren, solange Daten als knappe, zentral verwaltete Ressource behandelt wurden.
ING investierte massiv in eine gemeinsame Datenplattform, die Self-Service-Zugang zu definierten Datenprodukten ermöglichte. Kernprinzipien dabei: Daten werden als interne Produkte behandelt, die dokumentiert, versioniert und mit Service-Level-Agreements versehen werden. Squads konnten Datenzugang über standardisierte APIs beantragen, ohne IT-Tickets zu erstellen. Die Governance-Seite wurde föderalisiert: Jede Tribe übernahm Ownership für ihre Kerndaten, während ein zentrales Daten-Chapter übergreifende Standards pflegte.
Was lässt sich aus diesem Beispiel für die Breite der Praxis ableiten? Drei Erkenntnisse sind besonders übertragbar:
Erstens: Daten-Governance und Team-Autonomie sind keine Gegensätze. Föderierte Governance — klare Regeln, aber dezentrale Ausführung — löst den scheinbaren Widerspruch auf. Zweitens: Self-Service ist kein nice-to-have, sondern eine strukturelle Voraussetzung für Teamautonomie. Solange Teams Datenzugang über Gatekeeper beantragen müssen, sind sie heteronome Akteure — unabhängig davon, wie schön ihre Kanban-Boards aussehen. Drittens: Der Kulturwandel in Datenfragen folgt der Architektur, nicht umgekehrt. ING veränderte zunächst die technischen Strukturen und dann — als Konsequenz — die Verhaltensweisen. Nicht durch Trainings und Mindset-Workshops allein.
Governance, Standards und Qualität: Das föderale Modell in der Praxis
Das föderale Governance-Modell klingt elegant in der Theorie. In der Praxis scheitert es häufig an zwei Extremen: entweder an übermäßiger Zentralisierung, die Teams wieder in Abhängigkeiten treibt, oder an unkontrollierter Dezentralisierung, die in Daten-Chaos mündet. Beides ist real, beides ist vermeidbar — wenn Governance-Design so ernsthaft betrieben wird wie Architektur-Design.
Was ein funktionierendes föderales Daten-Governance-Modell ausmacht, lässt sich anhand von vier Designprinzipien beschreiben:
Prinzip 1: Minimale viable Governance. Zentrale Standards sollten nur dort definiert werden, wo fehlende Standards zu echten Problemen führen — bei Sicherheit, Datenschutz, Interoperabilität zwischen Domänen. Alles andere liegt in der Verantwortung der Daten-Ownership-Teams. Der häufigste Fehler: zentrale Governance-Teams definieren Standards für Probleme, die sie antizipieren, aber die in der Praxis irrelevant sind.
Prinzip 2: Datenqualität als Team-Responsibility. In traditionellen Architekturen ist Datenqualität eine Aufgabe eines zentralen Data-Stewardship-Teams. Im agilen Modell ist Datenqualität — analog zur Code-Qualität — Verantwortung des produzierenden Teams. Das bedeutet: Teams brauchen die Werkzeuge und das Wissen, um Datenqualität zu messen und zu steuern. Ohne Investition in Data Literacy auf Team-Ebene bleibt dieser Anspruch eine leere Forderung.
Prinzip 3: Governance als Platform-Service. Compliance-Anforderungen, Audit-Trails, Datenschutz-by-Design — all das sollte als vorgefertigte Capability auf der Datenplattform verfügbar sein. Teams integrieren diese Capabilities, ohne sie selbst bauen zu müssen. Dieser Ansatz reduziert Governance-Overhead und erhöht gleichzeitig die Compliance-Rate, weil Compliance der Weg des geringsten Widerstands wird.
Prinzip 4: Federated Data Chapter. Analog zu Guilds und Chapters in der Team-Topologies-Welt braucht es domänenübergreifende Community of Practice für Datenpraktiken. Nicht als Entscheidungsgremium, sondern als Lerngemeinschaft: Welche Patterns funktionieren? Wo entstehen Qualitätsprobleme? Was können wir voneinander lernen?
Für Agile Coaches ist hier ein konkreter Interventionspunkt: Wenn du merkst, dass Datenthemen in Sprint Reviews regelmäßig als Blocker auftauchen, ist das ein Signal für fehlende Governance-Infrastruktur — nicht für fehlende Sorgfalt im Team.
Von der Datenarchitektur zur adaptiven Organisation: Synthese und Ausblick
Agile Transformation und Datenarchitektur sind keine parallelen Workstreams, die irgendwann konvergieren. Sie sind von Beginn an verzahnt — und ihre Verzahnung entscheidet über Geschwindigkeit, Nachhaltigkeit und letztlich Tiefe der Transformation. Die in diesem Artikel beschriebenen Strategien — DDD als konzeptuelle Brücke, inkrementelle Migration statt Big Bang, föderale Governance, Data as a Product — sind keine akademischen Konstrukte. Sie sind praxiserprobte Antworten auf reale Transformationsblockaden.
Was bleibt als Synthese?
Erstens: Architektur ist Organisationsstrategie. Wer Teamautonomie will, muss Datenautonomie ermöglichen. Das erfordert Investitionen in technische Infrastruktur, die sich Leadership-Ebene nicht wegdelegieren lassen.
Zweitens: Inkrementalismus ist auch hier das richtige Paradigma. Keine Organisation wird ihre Datenarchitektur in einem Quartal transformieren. Aber jede Organisation kann in einem Quartal identifizieren, welche Datenabhängigkeiten ihre strategisch wichtigsten Teams am stärksten blockieren — und dort mit gezielter Ablösung beginnen.
Drittens: Data Literacy ist eine Führungskompetenz. Agile Führungskräfte, die Datenarchitektur als rein technisches Thema behandeln, werden systematisch in strategischen Entscheidungen fehlgeleitet. Das Verständnis von Datengrenzen, Qualitätsdimensionen und Governance-Modellen gehört zur Führungsgrundlage moderner Organisationen.
Und schließlich: Die adaptivste Organisation ist nicht die, die am schnellsten auf Veränderungen reagiert. Es ist die, die ihre eigene Struktur — technisch wie organisatorisch — so gestaltet hat, dass Veränderung der Standard ist, nicht die Ausnahme. Datenarchitektur, die diesem Anspruch genügt, ist kein Ziel. Sie ist ein fortlaufender Designprozess — genauso wie agile Führung selbst.
Der wichtigste Handlungsimpuls für diese Woche: Setz dich mit dem verantwortlichen Datenarchitekten oder CTO deiner Organisation zusammen — nicht um Anforderungen zu übergeben, sondern um gemeinsam die Frage zu stellen: Welche unserer Teamgrenzen spiegeln sich in unseren Datengrenzen wider? Und wo widersprechen sie sich? Die Antwort auf diese Frage ist der Einstieg in eine Transformation, die wirklich bis in die Struktur geht.
