Gall's Law: Warum komplexe Datenplattformen nie am Reißbrett entstehen
85 % der Big-Data-Projekte scheitern – nicht trotz ambitionierter Planung, sondern wegen ihr. Was Gall's Law und Lehman's Laws Datenverantwortlichen über den einzigen Weg zu einer funktionierenden Datenplattform sagen.
Gall’s Law: Warum komplexe Datenplattformen nie am Reißbrett entstehen
Jedes komplexe System, das funktioniert, hat sich aus einem einfachen System entwickelt, das funktioniert hat. Ein von Grund auf als komplex entworfenes System funktioniert nie. Diese Erkenntnis, formuliert 1975 vom Systemtheoretiker John Gall, ist das stärkste Argument gegen Big-Bang-Datenplattform-Migrationen — und die Zahlen geben ihr recht: 85 % der Big-Data-Projekte scheitern (Gartner), 70 % der digitalen Transformationen verfehlen ihre Ziele (McKinsey), und 83 % der Datenmigrationen sprengen ihr Budget oder werden abgebrochen (Gartner). Diese Misserfolge sind kein Zufall. Sie folgen einem Muster, das zwei Systemtheoretiker vor Jahrzehnten beschrieben haben.
Das Gesetz, das Milliarden hätte sparen können
John Gall war Kinderarzt an der University of Michigan — kein Informatiker, kein Enterprise-Architekt. Sein Buch General Systemantics wurde von 30 Verlagen abgelehnt, bevor er es 1975 selbst veröffentlichte. Die Kernaussage, heute als Gall’s Law bekannt: Ein komplexes System, das funktioniert, ist ausnahmslos aus einem einfachen System hervorgegangen, das funktioniert hat. Ein von Grund auf komplex entworfenes System funktioniert nie — und es lässt sich auch nicht reparieren. Man muss mit einem funktionierenden einfachen System von vorne anfangen.
Was diese Beobachtung für CTOs und CDOs so relevant macht: Sie beschreibt exakt das Scheiternsmuster, das in der Datenarchitektur seit zwei Jahrzehnten immer wieder auftritt. Das Anti-Pattern lautet: Zuerst Tools kaufen, dann eine komplexe Zielarchitektur entwerfen, dann Datensilos migrieren. Dataiku bringt es auf den Punkt: Wer Technologie-Entscheidungen nicht auf tatsächlichen aktuellen Bedürfnissen gründet, endet mit teuren Tools, die niemand praktisch nutzen kann.
Das World Wide Web ist das Paradebeispiel für Gall’s Law: Es begann als simples Hypertext-System am CERN und evolvierte zur komplexesten Plattform der Menschheitsgeschichte. Das Gegenbeispiel ist CORBA — eine ambitionierte Spezifikation, die von Anfang an Plattformportabilität über Aerospace, Banking und Telekommunikation hinweg abbilden sollte. CORBA scheiterte an seiner eigenen Komplexität, bevor es je breit adoptiert wurde.
Der Friedhof der Big-Bang-Migrationen
Die empirische Evidenz ist erdrückend. McKinsey beziffert die Verluste gescheiterter digitaler Transformationen allein 2018 auf 900 Milliarden Dollar von 1,3 Billionen investierten. Brian Harkins Forschung von 2024 schätzt die globale Summe verschwendeter Mittel auf 2,3 Billionen Dollar.
Das instruktivste Beispiel für den deutschsprachigen Raum ist Lidl. Zwischen 2011 und 2018 versuchte der Discounter, sein gewachsenes Warenwirtschaftssystem durch SAP for Retail auf HANA zu ersetzen. Das Projekt beschäftigte rund 1.000 Mitarbeiter und Hunderte Berater über sieben Jahre, verschlang 500 Millionen Euro — und wurde im Juli 2018 komplett eingestellt. Lidl kehrte zu seinem Altsystem zurück. Der zentrale Fehler: Statt die eigenen Prozesse evolutionär anzupassen, verlangte Lidl massive Customizations am SAP-Standard — ein klassischer Verstoß gegen Gall’s Law. Nur 15 Monate vor dem Projektabbruch hatte SAP Lidl noch als einen seiner besten Kunden ausgezeichnet.
Lidl ist kein Einzelfall. Revlon verlor durch eine misslungene SAP-S/4HANA-Migration 64 Millionen Dollar an nicht ausgelieferten Bestellungen und wurde von den eigenen Aktionären verklagt. Haribo erlitt durch eine SAP-Umstellung über 16 Fabriken in 10 Ländern einen Umsatzrückgang von 25 % bei den Goldbären. Hershey’s komprimierte eine 48-Monats-ERP-Einführung auf 30 Monate und konnte daraufhin Halloween-Bestellungen im Wert von 100 Millionen Dollar nicht erfüllen. General Electric verbrannte über 7 Milliarden Dollar mit dem Versuch, eine allumfassende Industrial-IoT-Datenplattform (Predix) von Grund auf zu bauen.
Das Muster ist immer dasselbe: Zu viel Scope, zu wenig Evolution, zu viel Vertrauen in die Planbarkeit komplexer Systeme.
Der richtige Weg: Klein starten, evolutionär wachsen
Die Unternehmen mit den ausgereiftesten Datenplattformen haben sie nicht in einem Big-Bang-Projekt gebaut, sondern Schritt für Schritt evolviert.
Spotify ist das überzeugendste Beispiel. Die Datenplattform entwickelte sich über ein Jahrzehnt: von selbstgebauten Orchestrierungstools (Luigi) in den frühen 2010ern, über eine schrittweise Migration von Hadoop zu Google Cloud Platform ab 2016 — Komponente für Komponente, nicht alles auf einmal. Heute verarbeitet sie über 500 Milliarden Events täglich, betrieben von über 300 Teams mit 20.000 Batch-Pipelines. Das war nie eine einzelne Migrationsentscheidung. Es war eine kontinuierliche Evolution, bei der jede Änderung auf dem aufbaute, was bereits funktionierte.
Netflix baute seine interne Datenplattform ebenfalls inkrementell: erst ein System für Datenbewegung zwischen Systemen, dann eine Control Plane, dann eine Data Plane mit Kafka und Flink, dann automatisierte Schema-Evolution — jede Fähigkeit als Schicht auf einem funktionierenden Fundament. Airbnb entwickelte Apache Airflow intern, um ein konkretes Orchestrierungsproblem zu lösen, und baute darauf auf.
Zhamak Dehghanis Data-Mesh-Framework verkörpert Gall’s Law explizit. Ihr O’Reilly-Buch enthält ein Kapitel mit dem Titel „Begin with the Simplest Foundation, Then Harvest to Evolve.” Monte Carlo Data fasst die praktische Weisheit zusammen: Man solle Data Mesh implementieren wie eine Renovierung bei laufendem Bewohnen — Raum für Raum, nicht durch Abriss und Neubau.
Die gesamte Geschichte der Datenarchitektur illustriert den Punkt: Einfache Data Warehouses in den 1990ern evolvierten zu Data Lakes in den 2000ern, dann zu Lakehouses in den 2020ern, und heute zu föderierten Architekturen. Jede Generation entstand aus der vorherigen. Niemand hat die heutige Lakehouse-Architektur 1995 am Reißbrett entworfen.
Lehman’s Laws: Warum „bauen und vergessen” immer scheitert
Gall’s Law erklärt, warum Datenplattformen klein starten müssen. Aber was passiert nach dem Go-Live? Hier greift eine zweite, weniger bekannte Gesetzmäßigkeit.
Meir „Manny” Lehman formulierte zwischen 1974 und 1996 am Imperial College London acht Gesetze der Software-Evolution, basierend auf empirischen Studien an IBMs OS/360. Zwei davon sind für Datenplattform-Verantwortliche besonders relevant.
Das Gesetz der kontinuierlichen Veränderung: Ein System, das in realen Geschäftsprozessen eingebettet ist, muss kontinuierlich angepasst werden — oder es wird zunehmend weniger nützlich. Lehman formulierte es pointiert: In dem Moment, in dem man ein Programm installiert, verändert sich die Umgebung. Datenplattformen sind der Prototyp eines solchen Systems. Datenquellen ändern ständig Formate, Schemata und APIs. Geschäftsanforderungen verschieben sich. Regulatorische Rahmenbedingungen wandeln sich. Und die Plattform selbst verändert das Verhalten der Organisation, was wiederum neue Datenanforderungen erzeugt — eine endlose Feedbackschleife.
Das Gesetz der zunehmenden Komplexität: Wenn ein System evolviert, wächst seine Komplexität — es sei denn, es wird aktiv daran gearbeitet, sie zu reduzieren. Ohne explizite Investition in Refactoring, architektonische Reviews und den Abbau technischer Schulden werden Datenplattformen unbeherrschbar. McKinseys Global Data Engineering Report von 2024 bestätigt das: 64 % der Data-Leader sagen, dass technische Schulden die Fähigkeit ihres Teams, Business-Ziele zu erreichen, signifikant einschränken. Die durchschnittliche Organisation verwendet 20–40 % ihres Technologie-Budgets allein für die Verwaltung dieser Last.
Diese Gesetze lassen sich direkt auf das Day-0/Day-1/Day-2-Framework übertragen. Day 0 ist Design, Day 1 ist Launch, Day 2 ist die unbestimmte Zukunft des stabilen Betriebs — und genau dort scheitern die meisten Organisationen. Ein Infrastruktur-Verantwortlicher brachte es so auf den Punkt: Man habe sechs Monate für die Migration gebraucht und anschließend zwei Jahre, um zu lernen, das System in der Produktion stabil zu betreiben. Gartner prognostiziert, dass 80 % der Unternehmen bis 2026 daran scheitern werden, Cloud-Governance und -Observability zu operationalisieren — nicht aus Mangel an Engineers, sondern weil Day-2-Planung von Anfang an vergessen wurde.
Datenplattformen brauchen permanente Teams, keine Projektbudgets
Die kombinierte Implikation von Gall’s Law und Lehman’s Laws führt zu einer klaren organisatorischen Konsequenz: Datenplattformen erfordern dedizierte Vollzeit-Teams — keine projektbasierte Implementierung mit anschließender Übergabe an den IT-Betrieb.
Das bedeutet konkret: Menschen, die das System in seiner gewachsenen Komplexität verstehen, die den Kontext der Fachbereiche kennen, die technische Schulden identifizieren und abbauen, und die das System kontinuierlich an veränderte Anforderungen anpassen. Nicht als Nebenprojekt. Nicht als temporäre Rolle. Fulltime.
Gartner prognostiziert, dass bis 2026 80 % der großen Software-Engineering-Organisationen dedizierte Platform-Engineering-Teams etablieren werden — gegenüber 45 % im Jahr 2022. McKinsey bezeichnet den Aufbau interner Teams aus Data Scientists, Data Engineers und Product Owners als „nicht verhandelbar”. Apple unterhält ein eigenes Data Platform SRE-Team, das Exabytes an Daten über alle globalen Produkte hinweg verwaltet.
Eine Warnung aus der Praxis liefert ein dokumentierter Fall, in dem eine halbe Million Dollar über drei Jahre in Analytics investiert wurde — ohne messbaren Wert. Die Fehleranalyse identifizierte drei Ursachen: keinen Prozess für kontinuierliches Feedback und Verbesserung, fehlende Ownership der BI-Strategie, und eine Haltung des Stillstands nach dem initialen Launch. ThoughtWorks berichtet von einer ähnlichen Erfahrung mit ihrer internen Datenplattform: Nach dem Aufbau einer technisch exzellenten Lösung passierten Early Adopters, die Euphorie verflog — und neue Geschäftsbereiche konnten nicht angebunden werden, weil das Team aufgehört hatte, an die sich verändernden Bedürfnisse der Nutzer zu denken.
Die strategische Quintessenz
Gall’s Law und Lehman’s Laws zusammen ergeben ein klares Handlungsframework für Datenverantwortliche.
Erstens: Mit einem konkreten Use Case starten, nicht mit einer Plattform. Das einfachste System bauen, das messbaren Geschäftswert liefert. Dann iterieren. Die „Crawl, Walk, Run”-Progression — grundlegende Datenerfassung und initiale KPIs, dann erweiterte Quellen und Cross-Channel-Optimierung, dann Advanced Analytics und KI — spiegelt exakt wider, was Gall 1975 beschrieben hat.
Zweitens: Von Anfang an für Day 2 budgetieren. Laut IBMs CDO-Studie 2025 allokieren führende Organisationen inzwischen 13 % ihres IT-Budgets für Datenstrategie — gegenüber 4 % im Jahr 2023. Wer die laufenden Betriebskosten nicht von Beginn an einplant, baut ein System, das am Tag nach dem Launch zu verfallen beginnt.
Drittens: Permanente Teams aufbauen, nicht Projekte staffieren. Eine Datenplattform ist ein Produkt, kein Projekt. Sie braucht Product Owner, die den Geschäftskontext verstehen, Engineers, die die gewachsene Komplexität beherrschen, und eine Kultur der kontinuierlichen Verbesserung.
Gartner VP Analyst Adam Ronthal formuliert die Handlungsaufforderung für Entscheider treffend: Die Details einer perfekten Strategie sollten niemanden davon abhalten, eine gute Strategie umzusetzen. Oder in Gall’s Worten: Fangen Sie einfach an. Aber fangen Sie klein an.