Zum Hauptinhalt springen

The Data Economist Blog (DE) | Etablierung einer Data Inspired & Digital Culture

Architektur im Blindflug: Warum IT der Datenlogik folgen muss – und nicht umgekehrt

Wie ein fundamentales Missverständnis zwischen Daten- und Solution-Architektur digitale Transformation blockiert

Wer glaubt, Datenarchitektur sei lediglich ein Teilbereich der Solution-Architektur, verkennt die wahre Dynamik dateninspirierter Unternehmensführung. Die Technik darf nicht der Maßstab für die Organisation von Prozessen und Daten sein – sondern muss sich ihnen unterordnen. Nur wenn die Datenflüsse und Kernprozesse eines Unternehmens klar definiert sind, kann eine technische Infrastruktur entstehen, die echte Transformation ermöglicht. Das Dogma „Daten folgen der Technik“ hat mehr Digitalisierungs-, KI- und Dateninitiativen scheitern lassen als jede veraltete Software. Wer erfolgreich sein will, muss endlich umdenken: Nicht die Datenarchitektur folgt der IT-Strategie, sondern die IT-Strategie muss sich an der Datenstrategie orientieren – strategisch, strukturell und architektonisch.

Wie Unternehmen heute denken – und woran sie scheitern

In der unternehmerischen Praxis wird die Solution-Architektur häufig als die „übergeordnete“ Disziplin verstanden. Die Datenarchitektur gilt bestenfalls als zuarbeitender Unterbau – zuständig für Datenmodelle, Speicherorte und Zugriffspfade, nicht aber für die strategische Gestaltung von Geschäftsmodellen. In klassischen IT-Projekten bedeutet das: Es wird eine technische Infrastruktur geplant, bestehend aus Anwendungen, Integrationen, Systemlandschaften – und erst im Anschluss versucht man, passende Datenflüsse hineinzupressen. Geschäftsprozesse werden entlang technischer Möglichkeiten „optimiert“, nicht entlang logischer Notwendigkeiten. Die Datenarchitektur hat dabei nur die Rolle eines Anpassungsmechanismus.

Dieses Paradigma ist tief verankert – sowohl in den Köpfen von Architekten als auch in den Entscheidungsstrukturen von Unternehmen. IT-Abteilungen dominieren den Architekturprozess, während Fachbereiche oft nur Inputgeber für Anforderungen sind. Daten werden dabei vor allem als Nebenprodukt behandelt – etwas, das man nachträglich „bereitstellt“. Das Resultat sind zahllose isolierte Tools zur Unterstützung einzelner Kernprozesse, fragmentierte Datenhaltung, widersprüchliche Definitionen und kaum nutzbare End-to-End-Datenketten. Auch moderne Initiativen wie KI-Projekte, Automatisierung oder Advanced Analytics scheitern regelmäßig an genau diesem Punkt: Es fehlt nicht an Technologie, sondern an einer kohärenten, durchgängigen Datenstruktur, die sich aus dem Prozess ableitet.

Datenfluss ist Prozessfluss: Der eigentliche Systemfehler

Der Denkfehler beginnt auf strategischer Ebene: Technische Architektur wird behandelt, als könne sie unabhängig vom Datenfluss gedacht werden. Doch wer dateninspirierte Transformation ernst nimmt, muss erkennen, dass Prozesse im Kern aus Daten bestehen. Wo kein durchgängiger Informationsfluss existiert, kann es auch keine belastbaren, automatisierbaren oder skalierbaren Prozesse geben. Datenfluss ist Prozessfluss – und umgekehrt.

Diese Erkenntnis hat tiefgreifende Folgen für das Architekturverständnis. Eine technische Infrastruktur, die sich nicht am Datenfluss orientiert, produziert zwangsläufig Reibungsverluste, Medienbrüche und Inkonsistenzen. Sie zwingt Unternehmen zu Workarounds, die zwar kurzfristig funktionieren, langfristig jedoch zu technischen Schulden führen – und damit zu strategischen Blockaden.

Dass viele Digitalisierungs- und datenzentrierte Projekte scheitern, liegt also nicht an Technologie oder mangelnder Innovationskraft, sondern an einer falschen Reihenfolge im Architekturdenken. Daten werden nachträglich angepasst, statt als Ausgangspunkt betrachtet zu werden. IT-Systeme werden nach Effizienzkriterien ausgewählt, nicht nach ihrer Fähigkeit, unternehmensweite Datenflüsse zu ermöglichen. Und Unternehmensstrategien ignorieren allzu oft die Notwendigkeit einer starken Datenstrategie – mit der Folge, dass digitale Ambitionen an realitätsfernen Architekturen zerschellen.

Ein weiteres Problem liegt in der Organisation selbst: In vielen Unternehmen gibt es keine zentrale Verantwortlichkeit für durchgängige Datenströme. Anreize für Datenqualität oder Datenaustausch fehlen. Datenproduzenten und -konsumenten haben unterschiedliche Interessen, was zu mangelnder Datenpflege führt. Data Governance wird auf Policies reduziert, statt als aktiver Orchestrator der Informationsflüsse verstanden zu werden. Kurzum: Die strukturellen Voraussetzungen, um Daten als strategisches Asset zu behandeln, fehlen.

Vom Irrweg zur Neuausrichtung: Vier Schritte zur Umkehr

Wer sich davon lösen will, muss seine Architekturprinzipien radikal umkehren – und zwar auf vier Ebenen:

  1. Strategische Verankerung: Die Entwicklung technischer Lösungen darf nicht losgelöst von der Unternehmensstrategie erfolgen. Der erste Schritt muss stets sein, die langfristigen Unternehmensziele zu klären. Welche Ergebnisse sollen erzielt werden? Welche Bedarfe, in welchen Märkten oder bei welchen Kundengruppen sind relevant? Daraus ergeben sich die relevanten Prozesse – und im nächsten Schritt: die dafür nötigen Daten.

  2. Prozessorientierung und Datenflüsse definieren: Ausgehend von den strategischen Zielen werden die Kernprozesse identifiziert, die diese Ziele operativ stützen. Dabei steht nicht die formale Prozessmodellierung im Vordergrund, sondern die Logik der Datenbewegung: Welche Informationen fließen wann, wo, warum und zwischen welchen Akteuren? Erst wenn diese Flüsse klar sind, kann man beurteilen, welche Systemunterstützung tatsächlich erforderlich ist.

  3. Datenarchitektur als strategischer Gleichwert zur Solution Architektur etablieren: Die Datenarchitektur darf nicht länger als „nachgelagerte“ Disziplin behandelt werden. Sie ist gleichwertig – und in vielen Fällen richtungsweisend. Wer IT-Entscheidungen trifft, ohne die Datenflüsse zu verstehen, betreibt bestenfalls Systemintegration – aber keine Unternehmensarchitektur. Daher braucht es eine stärkere institutionelle Rolle für Data Architects, Chief Data Officers und funktionsübergreifende Gremien mit echter Entscheidungskompetenz.

  4. IT-Strategie an der Datenstrategie ausrichten: Der eigentliche Paradigmenwechsel liegt darin, die IT-Strategie nicht mehr isoliert zu entwickeln. Sie muss aus der Datenstrategie abgeleitet werden – das bedeutet konkret: Nicht fragen „Was ist technologisch machbar?“, sondern „Was ist datenlogisch notwendig?“ Erst dann können technologische Entscheidungen (z.B. Plattformen, Integrationstechnologien, Speicherarchitekturen) sinnvoll getroffen werden.

Kurz gesagt: Die Reihenfolge muss lauten – (1) Strategische Ziele, (2) Prozesse, (3) Datenbedarf und -qualität, (4) IT-Systeme. Wer sie umkehrt, verschiebt Probleme nur ins nächste Projektjahr.

Architektur neu denken heißt: Prozesse zuerst

Es ist Zeit für ein neues Architekturdenken. Nicht die Technik formt die Prozesse – sondern die Prozesse, verstanden als strukturierte Datenflüsse, definieren die Anforderungen an die Technik. Solution-Architektur und Datenarchitektur sind keine Hierarchien, sondern zwei Perspektiven auf ein gemeinsames Ziel: eine durchgängige, wertschöpfende Unternehmensarchitektur. Nur wenn sie gleichberechtigt zusammenwirken – mit klarer Priorität für Prozess- und Datenlogik –, kann echte Transformation gelingen.

Wer diese Perspektive ernst nimmt, erkennt: Es reicht nicht, ein paar neue Tools einzuführen oder ein Data Mesh zu etablieren. Es braucht Mut zur Umkehr – weg von technologiegetriebenem Aktionismus hin zu datenbasierter, prozessorientierter Unternehmensgestaltung. Nicht mehr die Frage „Wie setzen wir KI ein?“, sondern „Wie fließen unsere Daten – und was brauchen wir, damit daraus Wirkung entsteht?“ bestimmt die Zukunft.

Neue Impulse: Wie Startups Architektur endlich richtig denken

Spannend ist, dass wir derzeit – getrieben durch neue KI-Möglichkeiten – erste Startups sehen, die dieses Paradigma von Beginn an richtig denken. Sie entwickeln IT-Lösungen, die sich an den realen Geschäftsprozessen und Zielen orientieren, nicht umgekehrt. Ein Beispiel aus dem Logistikbereich ist das mir aus früheren beruflichen Kontexten bekannte Startup pyck, das Lager- und Kommissioniersoftware von den realen Abläufen her denkt und entwickelt. Erste Ansätze konnte ich damals bereits mitverfolgen – und sie zeigen eindrücklich, welches Potenzial in einer datenorientierten, prozessgetriebenen Architektur liegt.

Digital & Data Inspired Life Cycle
Bild: Die Datenstrategie muss die IT-Strategie maßgeblich beeinflussen.
Weitere interessante Artikel:

Datenlogistik, Datenmanagement, Datenstrategie, Data Strategy, Data Management Strategy, Data Management, Data & AI Strategy, Data Flow

  • Geändert am .
  • Aufrufe: 62