Wir brauchen weniger Datenarchitektur. Nicht mehr. Jedes Jahr werden in unserer Branche neue Plattformen, Frameworks, Reifegradmodelle und Abkürzungen entwickelt. Dabei ist die Anzahl der Tools, die Zahl der Abhängigkeiten zwischen Datenpipelines oder die Tiefe der technologischen Stacks kein Maß für Professionalität. 

Wir haben Roadmaps, Zielbilder, Operating Models, Data Catalogs, Governance Boards und Architekturprinzipien. Oft wird die einfachste Frage nicht beantwortet. Welches Problem wird dadurch nächste Woche gelöst? 

Die meisten Datenprojekte scheitern nicht an Technologie, sondern an zu viel Komplexität. Wir verlieren uns in Details, die niemand braucht. Die eigentlichen Probleme bleiben ungelöst. Die Lösung liegt nicht in mehr Tools, mehr Abstraktionsschichten oder mehr „Skalierbarkeit“. Sie liegt in radikaler Vereinfachung. 

Nicht ein bisschen. Nicht als Lean-Management Übung. Das ist eine echte Veränderung. Was wäre, wenn wir Datenarchitektur nicht als das verstehen würden, was technisch möglich ist, sondern als Disziplin, in der wir bewusst Grenzen setzen? Es geht nicht darum, wie viele Datenprodukte eine Datenplattform theoretisch halten kann. Es geht darum, ob ein Team mit ihr ein Problem schneller, verlässlicher und billiger lösen kann. 

Es geht nicht darum, dass Kafka, Snowflake, Databricks, Fabric, dbt, OpenLineage oder Airflow schlechte Werkzeuge sind. Das Problem ist die Reihenfolge. Wir sprechen über Skalierung, bevor wir den Nutzen bewiesen haben. Wir reden über Enterprise-Architektur, bevor ein einziger Use Case sauber funktioniert. Wir entwerfen Betriebsmodelle, bevor wir wissen, welche Entscheidung besser werden soll. Wir bauen für Wiederverwendung, ohne zu wissen, was wiederverwendet werden soll. Wir vereinheitlichen Begriffe, die im Geschäft noch niemand stabil verwendet. Wir investieren in Datenqualität, ohne zu fragen, welche Fehler tatsächlich Geld, Zeit, Risiko oder Vertrauen kosten. 

These 1: Hört auf zu bauen, bevor ihr versteht 

Grundlegende Entscheidungen zu Datenarchitekturen entstehen häufig im Vakuum. Die Teams setzen sich zusammen, diskutieren Technologien, wählen zwischen Data Lake, Data Warehouse oder Data Mesh und entscheiden sich für Batch oder Stream – und das alles, bevor sie auch nur ein einziges Gespräch mit den Menschen geführt haben, die die Daten am Ende nutzen sollen. Das Ergebnis sind technisch beeindruckende, aber nutzlose Systeme. 

Die eigentliche Arbeit beginnt nicht mit der Wahl einer Technologie, sondern mit einer einfachen Frage: Welche Probleme haben die Teams aktuell? Mindestens ein Viertel der Projektzeit sollte meiner Meinung nach für Stakeholder-Interviews reserviert werden. Was passiert, wenn Informationen fehlen? Welcher Workaround existiert? Wer exportiert CSV-Dateien? Wer pflegt Excel-Listen? Wer kopiert Zahlen aus E-Mails? Wer gleicht Bestellungen manuell ab? Wer vertraut dem offiziellen Report nicht und erstellt deshalb einen Schattenreport? 

Diese Fragen klingen banal. Gerade deshalb werden sie oft unterschätzt. Manchmal fühlt es sich sogar peinlich an, sie zu stellen. Das ist ein Fehler. Die harten Probleme liegen oft nicht in der Daten-Pipeline, sondern in der Wirklichkeit davor. Dort, wo Menschen Daten eingeben, weil irgendein Prozess sie dazu zwingt. Dort, wo Felder leer bleiben, weil niemand den Zweck versteht. Oder dort, wo zwei Abteilungen denselben KPI verwenden, aber Unterschiedliches meinen. Oder dort, wo Führungskräfte nach „Umsatz” fragen und fünf Systeme fünf Antworten liefern, weil Buchung, Auftrag, Lieferung, Rechnung und Zahlung nie sauber voneinander getrennt wurden. 

These 2: Verbannt den Jargon 

Wir lieben Abkürzungen und Fachbegriffe: ETL-Pipelines, OLAP-Cubes, Dimensionstabellen, Faktentabellen und langsam veränderte Dimensionen. Unter uns Experten ist das eine legitime Kurzschrift. Zum Problem wird der Jargon jedoch, wenn er gegenüber den Fachbereichen den Blick verstellt. Beispielsweise lenkt er den Fokus auf die Technik statt auf das Problem. Eine gute Datenarchitektur ist nicht die technisch perfekte, sondern die, die jeder Beteiligte versteht. 

Probieren es aus! Erstellt eine Daten-Landkarte in Form einer einfachen Kreuztabelle. Auf der einen Achse stehen die KPIs, auf der anderen die Datenprodukte, die sie beeinflussen.  Es geht weder um Plattformnamen noch um Schichtenmodelle, sondern nur um die Frage, welche Kennzahl welches Datenobjekt für welchen Zweck benötigt. Wenn ein Stakeholder diese Tabelle nicht innerhalb von zwei Minuten versteht, ist sie zu komplex. Und wenn sie zu komplex ist, ist sie nutzlos. 

Erst wenn vollständig klar ist, welche Daten für welchen Use Case benötigt werden, sollten die nächsten Fragen gestellt werden. Woher kommen diese Daten? Wie gut sind sie? Wer tippt sie manuell ein? Die Antworten sind oft ernüchternd. So stammen beispielsweise Daten, die als „kritisch” gelten, aus veralteten Systemen, in denen sie nie aktualisiert werden. Daten, die als „hochqualitativ” gelten, sind voller Fehler, weil sie niemand prüft. Daten, die als „automatisiert” gelten, werden in Wahrheit jeden Monat von einer Person in ein Excel-Sheet eingetippt, das dann in das „moderne” System hochgeladen wird. Alles schon erlebt. 

Meiner Meinung nach sind die meisten Datenprobleme keine technologischen Probleme. Es sind organisatorische Probleme. Und diese lassen sich nicht mit mehr Technologie lösen. Genau deshalb ist eine Daten-Landkarte so wirkungsvoll: Sie zwingt die Organisation, Farbe zu bekennen und Stellung zu beziehen. 

These 3: Baut einen echten MVP statt zehn halbfertiger Lösungen 

In der Theorie klingt es logisch: Zunächst wird ein kleiner Prototyp gebaut, getestet und die Ergebnisse ausgewertet. Anschließend wird das Modell skaliert. In der Praxis sieht es jedoch oft anders aus. Es werden zehn Datenprodukte gleichzeitig entwickelt, von denen jedes einen Use Case zu 50 Prozent abdeckt. Keines ist fertig und keines funktioniert zuverlässig. Am Ende hat man ein so komplexes System, dass niemand mehr weiß, wie es funktioniert, geschweige denn, wie man es repariert. 

Meistens erzeugt ein halb gelöster Use Case keine halbe Wirkung. Oft erzeugt er gar keine. Zeigt ein Forecast-Dashboard schöne Trends, aber die kritische Produktgruppe fehlt, bleibt der alte Excel-Prozess bestehen. Wenn eine Kundenansicht Stammdaten zusammenführt, Vertragsstatus und offene Reklamationen aber fehlen, nutzt der Service sie nicht. Wenn eine Bestandsanalyse die Lagerbestände anzeigt, aber die Reservierungen und Lieferzeiten nicht sauber abbildet, trifft Operations weiterhin eigene Annahmen. 

Das Management liebt das Portfolio-Denken, weil es ausgewogen wirkt. Zehn Use Cases, zehn Sponsoren, zehn Streams, zehn Fortschrittsbalken. So fühlt sich jeder berücksichtigt und niemand ist beleidigt. Das Problem ist nur: Kunden, Mitarbeiter und die P&L interessieren sich nicht dafür, dass alle ein bisschen bekommen haben. Sie interessieren sich dafür, ob etwas funktioniert. 

Ein einziger Use Case, der innerhalb von vier Wochen spürbar verbessert wird, stärkt die Glaubwürdigkeit eines Datenprogramms mehr als eine Roadmap mit zwanzig Initiativen. Das liegt nicht daran, dass kleine Schritte romantisch wären, sondern daran, dass sie Lernzyklen verkürzen. Sie zeigen, welche Daten wirklich fehlen, welche Schnittstelle wirklich blockiert ist, welcher KPI wirklich umstritten ist und welches Team wirklich Verantwortung übernimmt. 

Ein echter MVP ist kein technisches Spielzeug, das es der IT leichter macht. Er ist eine Lösung, die ein Problem zu 80 Prozent in weniger als vier Wochen löst. Warum nur 80 Prozent? Weil Perfektion der Feind des Fortschritts ist. Oft verschlingen die letzten 20 Prozent 80 Prozent des Aufwands. Und weil eine unperfekte, aber funktionierende Lösung mehr wert ist als eine perfekte, die nie fertig wird. 

Und warum ausgerechnet vier Wochen? Gut, es könnten auch sechs sein, denn die konkrete Zahl ist nicht entscheidend. Der Punkt ist: Wenn man zu viel Zeit hat, besteht die Gefahr, dass man sich in Details verliert. Dass man über Skalierung nachdenkt, bevor man bewiesen hat, dass die Lösung funktioniert. Oder dass man über Technologie diskutiert, bevor man die echten Probleme verstanden hat. Eine bewusst kurze Frist ist kein Selbstzweck, sondern ein Disziplinierungswerkzeug gegen die eigene Neigung zur Überkomplexität. 

Der Skalierbarkeits-Mythos 

Eine der größten Lügen der Datenwelt lautet: „Wir müssen von Anfang an skalierbar bauen.“ Skalierbarkeit ist jedoch kein Selbstzweck. Sie ist ein Mittel zum Zweck – und dieser Zweck ist der Nutzen. Doch zu oft dient Skalierbarkeit als Alibi für Komplexität: „Das können wir jetzt nicht einfach umsetzen, weil es später nicht skaliert.“ „Wir brauchen Microservices, sonst haben wir in zwei Jahren Probleme.“ „Wir müssen alle Daten in einen Data Lake laden, auch wenn wir heute nur zehn Prozent davon nutzen.“ 

Die Wahrheit ist: Die meisten Datenprojekte scheitern nicht aufgrund mangelnder Skalierbarkeit. Sie scheitern, weil sie keinen Nutzen stiften. Weil sie zu lange brauchen, um Ergebnisse zu liefern. Oder weil sie die falschen Probleme lösen. Skalierbarkeit ist wichtig, aber zweitrangig. An erster Stelle steht die Frage: Löst das hier ein echtes Problem? Wenn die Antwort „nein” lautet, ist es egal, wie skalierbar die Lösung ist. 

„Skalieren wir später” ist heute selten teure technische Schuld 

Der klassische Einwand gegen den MVP-Ansatz lautet: „Wenn wir klein anfangen, bauen wir uns technische Schulden auf, die uns später einholen.“ Vor zehn Jahren war da etwas dran, denn monolithische On-Premise-Systeme ließen sich kaum nachträglich erweitern. Bei modernen Plattformen ist der spätere Sprung von „klein” auf „groß” jedoch vergleichsweise günstig, sofern von Anfang an drei Grundprinzipien beachtet werden. Nicht, weil man dann groß baut, sondern weil man klein baut, ohne sich Türen zuzumauern. 

• Die Trennung von Speicher- und Rechenleistung ist ein wichtiger Aspekt. In modernen Plattformen wie Snowflake, BigQuery, Databricks, Fabric usw. sind Storage und Compute entkoppelt. Man startet mit dem kleinsten Warehouse und skaliert die Rechenleistung per Konfiguration, wenn die Last kommt. Das alles ohne die Architektur neu zu entwerfen. Skalierung wird so zur Betriebs- und nicht zur Bauentscheidung. 

• Offene Tabellenformate. Wer seine Daten in einem offenen Format, wie Apache Iceberg, entkoppelt sie von der verarbeitenden Engine. Das verhindert Lock-in und erlaubt es, später eine andere oder zusätzliche Engine hinzuzufügen, ohne die Daten zu migrieren. Ein wirklich teuerer Teil einer Skalierung, das Umziehen der Daten, entfällt somit. 

• Man kann Dinge deklarativ, modular und mit Infrastructure-as-Code verändern. Wenn man Transformationen mit dbt modelliert und Infrastruktur mit Terraform als Code versioniert, beschreibt man das Ergebnis und nicht die Schritte, die man dafür machen muss. Das ermöglicht Skalierung. Um ein „S“ in ein „XL“ zu ändern, muss eine Zeile im Terraform-Code geändert und ein Merge-Request eingereicht werden. Wenn die Anzahl der Tabellen von 10 auf 500 steigt, müssen nur Modelle hinzugefügt werden. Die Pipeline bleibt. Es wird eine neue Logik hinzugefügt, die bestehende bleibt gleich. Refactoring bleibt einfach, weil vor jeder Veröffentlichung automatisierte Tests durchgeführt werden. Nicht-Null-Werte oder referenzielle Integrität greifen in der CI-Pipeline, bevor eine Änderung die Produktion erreicht. Man traut sich umzubauen, weil ein Fehler auffällt, bevor er Monate später zu falschen Daten im Report führt. 

Die Botschaft lautet nicht: „Skalierbarkeit ist egal”, sondern: Ein paar kluge Grundentscheidungen halten die Tür zur Skalierung offen, ohne dass man die gesamte Komplexität von morgen bereits heute umsetzen muss. Man kauft sich somit Optionalität, ohne dafür mit Geschwindigkeit zu bezahlen. 

Der Gegeneinwand klingt vernünftig und in Teilen hat er recht: Große Unternehmen brauchen Skalierung. Sie benötigen Governance, Sicherheitskonzepte, Datenschutz, Rollenmodelle, Datenkataloge, Standards und belastbare Plattformen. Niemand möchte, dass jedes Team seine eigene Datenwelt aufbaut. Niemand will wilde Schatten-IT, unkontrollierte Exporte, falsche Kennzahlen oder regulatorische Risiken. Diese Einwände sind berechtigt. Aber sie sind nur die halbe Wahrheit. 

Selbstverständlich gibt es Bereiche, in denen Komplexität erforderlich ist. Banken, Versicherungen, Pharmaunternehmen, Energieversorger und öffentliche Institutionen können mit Daten nicht wie ein Start-up im Nebenraum umgehen. Datenschutz, Informationssicherheit, Nachvollziehbarkeit und Regulatorik sind echte Anforderungen. Wenn die Datenarchitektur diese Anforderungen ignoriert, ist sie fahrlässig. 

Gerade regulierte Unternehmen dürfen jedoch Vereinfachung nicht mit Naivität verwechseln. Eine einfache Architektur kann sicherer sein als eine komplizierte, da sie weniger versteckte Abhängigkeiten, unklare Datenflüsse und Schattenprozesse erzeugt. Wenn jedoch niemand mehr nachvollziehen kann, wie eine Kennzahl entsteht, wie sie transformiert wird, wer sie freigibt und welche manuellen Korrekturen eingeflossen sind, hilft auch das schönste Governance-Framework nicht. 

Deshalb sollten sich viele CIOs und CTOs eine unangenehme Frage stellen: Für wen bauen wir eigentlich? Für Auditoren? Für Architekturboards? Für die nächste Strategiepräsentation? Oder für die Menschen, die jeden Tag Entscheidungen unter Unsicherheit treffen müssen? Eine Datenarchitektur, die im Zielbild überzeugt, den Alltag aber nicht verbessert, ist keine gute Infrastruktur. 

Und was ist mit KI? 

Ausgerechnet der aktuelle Hype um GenAI ist das stärkste Argument für diese Haltung. Große Sprachmodelle versprechen, Fragen an Daten in natürlicher Sprache zu beantworten, Pipelines zu generieren und Dokumentationen zu erstellen. Genau deshalb wird die Versuchung, „einfach noch schnell einen KI-Layer obendrauf” zu bauen, in den nächsten Jahren sehr groß sein. Und genau deshalb wird die Disziplin der Vereinfachung nicht überflüssig, sondern wichtiger. 

Denn KI übernimmt jede Unklarheit der Organisation und verstärkt sie. Ein Sprachmodell, das nicht weiß, ob „Umsatz” die Buchung, den Auftrag oder die Rechnung meint, halluziniert eine plausible Antwort und gibt sie mit voller Überzeugung von sich. Garbage in, confident nonsense out. Eine saubere Datenlandkarte, eindeutige Definitionen und ein schlanker semantischer Layer sind also keine Gegensätze zur KI-Reife, sondern ihre Voraussetzung. Wer zuerst versteht und klar definiert, legt genau das Fundament, auf dem GenAI verlässlich funktioniert. 

Gleichzeitig senkt KI die Kosten des Verstehens – also der Tätigkeit, für die ich in diesem Text plädiere. Modelle helfen dabei, Interviews zusammenzufassen, Datenlandschaften zu dokumentieren, widersprüchliche Definitionen aufzudecken und Legacy-Logik zu entschlüsseln. Bei richtiger Anwendung verkürzt KI nicht nur die „Build“-Phase, sondern auch die Phase des Verstehens am Beginn. Bei falschem Einsatz wird sie jedoch zur nächsten Abstraktionsschicht, die niemand mehr durchschaut. Ob der richtige oder der falsche Fall eintritt, hängt nicht von der Technologie, sondern von der Klarheit dahinter ab. 

Die unterschätzteste Architekturentscheidung fängt wirklich klein an.

Die Alternative zur Komplexitätsfalle ist unbequem einfach: Fang klein an. Löse ein Problem. Beweise, dass es funktioniert. Dann mach weiter. 

Das bedeutet jedoch nicht, dass man keine langfristige Vision haben sollte. Es bedeutet lediglich, dass diese Vision nicht im Weg stehen darf. Es bedeutet, keine Monate damit zu verbringen, eine perfekte Architektur zu entwerfen, während die Nutzer weiterhin mit Excel und Workarounds arbeiten. Und es bedeutet, zu akzeptieren, dass die erste Lösung nicht perfekt sein wird.

Das klingt zwar hart, aber viele Datenorganisationen haben über Jahre hinweg gelernt, ihre Existenz über die Breite zu legitimieren: mehr Domains, mehr Datenprodukte, mehr Dashboards, mehr Pipelines, mehr Nutzer, mehr Plattformfunktionen. Doch Nutzen entsteht nicht durch Menge, sondern durch Passung. Ein Datenprodukt, das potenziell jeden interessieren könnte, hilft oft niemandem. Ein Datenprodukt, das ein teures, häufiges und klar beschriebenes Problem löst, wird hingegen genutzt. Nutzung ist nicht alles, aber ohne Nutzung ist nichts davon relevant.

Ein radikal einfacher Datenansatz wertet Excel deshalb nicht als schlechte Lösung ab. Excel ist da, weil es nah am Problem ist. Weil es schnell ist. Zentrale Datenlösungen sind oft zu langsam, zu allgemein und zu weit weg. Die Antwort kann jedoch nicht darin bestehen, jede Excel-Datei in ein Enterprise-Tool zu überführen. Die Antwort muss darin bestehen, die Stärken von Excel – Geschwindigkeit, Verständlichkeit und Zweckbindung – ernst zu nehmen und nur dort zu industrialisieren, wo Risiko und Nutzen es rechtfertigen.

Das bedeutet auch: Nicht jeder Use Case erfordert ein Datenprodukt. Manche Probleme erfordern eine Prozessänderung. Manche erfordern eine bessere Stammdatenpflege. Manche benötigen ein Pflichtfeld weniger statt eines mehr. Manche benötigen lediglich eine klare Definition. Und manche benötigen gar keine neue Plattform, sondern lediglich die Abschaltung eines alten Reports.

„Nichts bauen” ist auch eine Option 

„Nichts bauen“ bedeutet mehr, als auf ein neues Dashboard zu verzichten. Es kann auch die bewusste Entscheidung sein, ein funktionierendes System nicht anzufassen. Ein Beispiel, das ich oft sehe, ist die Idee einer vollständigen Migration einer bewährten Oracle-Datenbank in ein Cloud-Data-Lakehouse. 

Die Migration wird oft als selbstverständlicher Fortschritt dargestellt. Die ehrliche Frage sollte jedoch nicht lauten: „Ist das Lakehouse moderner?”, sondern: „Löst das Lakehouse ein konkretes Problem besser als die Oracle-Datenbank?” Wenn das bestehende System die relevanten Use Cases bereits zuverlässig, performant und zu vertretbaren Kosten bedient, dann ist eine Vollmigration keine Verbesserung, sondern ein millionenschweres Projekt mit hohem Risiko und ungewissem Nutzen. Dabei wird eine funktionierende und verstandene Umgebung gegen eine neue ausgetauscht, in der Datenflüsse, Berechtigungen, Performance-Eigenschaften und Betriebswissen erst mühsam neu aufgebaut werden müssen. 

Die reifere Entscheidung ist oft die hybride: Das Oracle-System bleibt dort, wo es bereits stark ist, und das Lakehouse wird gezielt dort ergänzt, wo es echten Mehrwert bringt – etwa bei großvolumigen Analysen, semistrukturierten Daten oder ML-Workloads. Ein einheitlicher Zugriffslayer kann die verschiedenen Systeme dann zusammenfassen. 

In einer reifen Organisation ist die Entscheidung, nichts zu bauen und nichts zu migrieren, was funktioniert, eine völlig legitime Architekturentscheidung. Vielleicht sogar die am meisten unterschätzte. Sie erfordert mehr Souveränität als jedes Neubauprojekt, da sie dem Reflex entgegenwirkt, Aktivität mit Fortschritt zu verwechseln. 

Nicht mehr Technologie – weniger Komplexität 

Die Datenwelt braucht eine Haltung, die Komplexität nicht als Zeichen von Professionalität begreift, sondern als etwas, das gemanagt und wo immer möglich reduziert werden muss. Eine Haltung, die nicht zuerst fragt: „Wie können wir das technisch umsetzen?”, sondern: „Brauchen wir das überhaupt?” 

Radikale Vereinfachung bedeutet nicht, die Datenarchitektur abzuschaffen. Sie bedeutet, diese vom Nutzen her neu zu legitimieren. Eine Architekturkomponente verdient ihren Platz nicht dadurch, dass sie modern ist, sondern dadurch, dass sie ein wiederkehrendes Problem zuverlässiger löst als eine einfachere Alternative. Ein Datenprodukt verdient seinen Namen nicht, weil es in einem Katalog steht, sondern weil Menschen damit anders arbeiten können. Autorität in der Governance entsteht nicht durch das Erlassen von Regeln, sondern durch die Fähigkeit, bessere Entscheidungen zu ermöglichen und Risiken zu senken, ohne jede Bewegung zu ersticken. 

Seit Jahren beschreibt McKinsey, dass viele Transformationen scheitern oder ihre Wirkung nicht voll entfalten. In einer Analyse aus dem Jahr 2021 heißt es, dass weniger als ein Drittel der befragten Unternehmen Transformationen so umgesetzt habe, dass die Leistung verbessert wurde und diese Verbesserung auch erhalten blieb. Selbst erfolgreiche Transformationen realisierten im Durchschnitt nur 67 Prozent des maximal möglichen finanziellen Nutzens (Quelle: McKinsey, Losing from day one: Why even successful transformations fall short Dezember 2021) . Solche Zahlen müssen nicht eins zu eins auf jedes Datenprogramm übertragen werden. Sie stützen jedoch meine Beobachtung: Große Veränderungsprogramme verlieren an Wert, wenn sie zu viel versprechen, zu langsam lernen und zu spät Nutzen stiften. 

Der erste Schritt ist einfach: Hört auf zu bauen! Fangt an zu verstehen. Fragt die Nutzer nach ihren Problemen. Erstellt eine Tabelle, die jeder versteht. Baut eine Lösung, die ein Problem zu 80 Prozent in vier Wochen löst. Und erst, wenn das funktioniert, denkt über Skalierung nach. 

Am Ende kommt es nicht darauf an, die beste Technologie zu haben, sondern die besten Ergebnisse zu liefern. Und diese Ergebnisse entstehen nicht durch mehr Komplexität, sondern durch weniger.