Die Datenarchitektur prägt das Unternehmen maßgeblich
Datenarchitektur entscheidet — bevor die erste Technologieentscheidung fällt
Wer eine neue Anwendungsarchitektur entwirft, steht früh vor der Frage: Data Warehouse, Data Lake oder Data Mesh? Monolith oder Service-orientierte Architektur? Diese Entscheidungen werden oft geführt, als wären sie primär eine Frage des Architekturstils oder der technologischen Präferenz. Sie sind es nicht.
Sie sind eine Konsequenz — und was sie voraussetzt, wird systematisch unterschätzt: ein explizites, detailliertes Verständnis der Daten selbst.
Die Fragen, die zuerst gestellt werden müssen
Daten sind nicht gleich Daten. Bevor eine Architekturentscheidung sinnvoll getroffen werden kann, braucht es Antworten auf Fragen, die im Projektalltag erstaunlich selten früh genug gestellt werden:
- Beruhen die Daten auf einzelnen Bewegungen — Transaktionen — oder sind sie unveränderbar, weil sie aus externen Quellen so geliefert werden?
- Müssen Transaktionen zu einem Bestand aggregiert werden, etwa einem Kontenstand? Und welche Geschäftslogik arbeitet auf dem Bestand, welche auf den einzelnen Transaktionen?
- Entwickelt sich der Datenbestand historisch entlang der Zeitachse, oder arbeitet die Verarbeitung primär mit Stichtagen?
- Müssen Stichtagsbestände und alle Verarbeitungsergebnisse nachvollziehbar und reproduzierbar sein?
- Welche Transformationswege gibt es — und wie verändert sich der Zustand der Daten durch jede Transformation?
- Welche Stufen der Datenveredelung gibt es, und wo sind Qualitätssicherungsmechanismen erforderlich, deren Ergebnisse später wieder nachvollzogen werden müssen?
- Sind Daten primär und voluminös, oder handelt es sich um Hilfsdaten, Konfigurationsparameter, Referenzdaten?
- Werden auf diesen Daten Simulationen durchgeführt — was bei Stichtagen zu einer erheblichen Vervielfältigung des Datenvolumens führen kann?
Diese Fragen klingen technisch. Ihre Auswirkungen sind es nicht allein — sie sind architektonisch, organisatorisch und ökonomisch.
Warum das so selten früh passiert
Es gibt einen strukturellen Grund, warum Dateneigenschaften zu spät in den Fokus geraten: Architekturentscheidungen werden oft von Technologiepräferenzen getrieben, nicht von Datenanforderungen.
Mitarbeiter haben in ihrem Berufsleben gelernt, bestimmte Ansätze zu favorisieren und zu vertreten. Ein erfahrener Data-Warehouse-Architekt sieht in vielen Problemen ein Data-Warehouse-Problem. Wer mit Microservices aufgewachsen ist, neigt dazu, Domänenmodelle serviceorientiert zu denken — unabhängig davon, ob die Dateneigenschaften das nahelegen.
Das ist kein Vorwurf. Es ist eine menschliche Tendenz, die ohne explizites Gegengewicht architektonische Entscheidungen prägt, bevor die eigentlich relevanten Fragen gestellt wurden.
Das explizite Verständnis der Dateneigenschaften ist dieses Gegengewicht. Es schafft eine gemeinsame sachliche Grundlage — und damit die Voraussetzung dafür, dass Architekturentscheidungen diskutiert statt behauptet werden können.
Was das konkret bedeutet
Sind die Eigenschaften der Daten in allen Dimensionen verstanden, leiten sich daraus Architekturkomponenten fast zwangsläufig ab. Die Wahl des Technologie-Mix für Haltung und Transport wird zur nachvollziehbaren Konsequenz statt zur Glaubensfrage.
Das hat einen unmittelbaren ökonomischen Effekt: Die teuersten Fehler in Transformationsprojekten entstehen nicht in der Implementierung. Sie entstehen, wenn Daten mit den falschen Eigenschaften in die falsche Architekturkomponente laufen — und das erst spät bemerkt wird. Je weiter sich die Prozesskette vom Ursprung der Daten entfernt, desto drastischer werden die notwendigen Qualitäts- und Korrekturmaßnahmen. Und desto teurer.
Umgekehrt gilt: Ein Datenfluss, in dem Daten entsprechend ihrer Eigenschaften mit geeigneten Technologien verarbeitet werden, ist keine Idealvorstellung. Es ist das, was jede gut gestaltete Architektur anstrebt — und was mit der richtigen Vorarbeit auch erreichbar ist.
Einordnung
Datenarchitektur, Datenmanagement und Datenfluss sind keine separaten Disziplinen, die nacheinander bearbeitet werden. Sie sind miteinander verwoben — und sie prägen die Anwendungsarchitektur, bevor die erste Zeile Code geschrieben wird.
Wer die Anwendungsarchitektur gestalten will, muss die Datenarchitektur verstehen. Und wer die Datenarchitektur verstehen will, muss mit den richtigen Fragen beginnen.
