DWX hakt nach: Warum muss die Architektur schon die Daten berücksichtigen?

Daten sind ein elementarer Bestandteil jeder Software. Doch kommen Sie in der Architektur oft nicht vor. „Ein Fehler“, sagt Matthias Niehoff und gibt Einblicke, warum die analytische Nutzung von Daten unbedingt in den Architekturprozess gehört. Matthias unterstützt als Head of Data & AI der codecentric Kunden bei Design und Umsetzung von Datenarchitekturen. Dabei liegt sein Fokus auf der notwendigen Infrastruktur & Organisation, um Daten & KI Projekten zum Erfolg zu verhelfen.

Matthias Niehoff: Schauen wir erstmal, was passiert, wenn man es nicht macht: Die Anforderungen an die Anwendung sind vermeintlich klar. Das Entwicklerteam legt los und baut Backend und Frontend. Irgendwann geht das ganze in die Produktion und dann kommt die Anforderung: Wir würden die Daten, die wir in der Anwendung sammeln, gerne auch analysieren. Welche Kunden haben wir und was kaufen sie? Wo haben wir Probleme bei der Auslastung unserer Fertigungsmaschinen? Welche Features werden gar nicht genutzt? Was dann folgt: Man baut Krücken, um die Daten bereitzustellen: regelmäßige Abzüge von der Datenbank bereitgestellt als CSV-Datei auf einem FTP-Server. Und das Entwicklerteam betrachtet es nur als notwendiges Übel und übernimmt gegebenenfalls auch keine Verantwortung für die Qualität.

Wenn ich jedoch frühzeitig über die analytische Nutzung der Daten nachdenke, kann ich passende Strategien von Anfang und ganz natürlich in die Entwicklung einfließen lassen. Und möglicherweise die Daten auch schon viel früher nutzen, zum Beispiel wenn es darum geht, die Entwicklung von Features der Anwendung zu priorisieren.

Matthias: Erstmal braucht es einige Grundlagen, die erfüllt sein müssen: Teams sollten als Domänen- oder Value-Stream-Teams aufgestellt sein. Und es braucht natürlich auch Daten-Features in den Produkten: Recommender, Forecasting oder Self Service Reporting zum Beispiel.  Wichtig ist es, in den Software-Teams Datenkompetenz aufzubauen. Sowohl methodisch (Was kann mit Daten aus analytischer Sicht gemacht werden?) aber auch technisch, da häufig andere Technologien mit ins Spiel kommen, die für Softwareentwickler manchmal etwas fremd sein können. Das Parquet-Format fällt mir da zum Beispiel ein.

Der Shift-Left, also das frühzeitige Mitdenken von Daten, das in der ersten Frage schon genannt wurde, ist sicher ein wichtiger organisatorischer Ansatz. Wichtig ist aber auch das Entwickler-Team zu befähigen. Sowohl mit Datenkompetenz, aber auch mit Tooling, das es einfach macht, Daten bereitzustellen. Da kommen dann Platform Teams und auch Ideen des Platform Engineering ins Spiel. Und wenn man dann über das Zusammenspiel von Domänen- und Plattformteams nachdenkt, kommt man um die Ideen und Konzepte der Team Topologies kaum herum als Ansatz für den Aufbau der Organisation.

Matthias: Die eine Technologie, die alles einfacher macht, gibt es natürlich nicht. Grundsätzlich gibt es zwei Teilbereiche, die man unterscheiden kann: zum einen, was zur Implementierung innerhalb einer Anwendung selbst genutzt wird, zum anderen, die Verbindung von Anwendungen untereinander.

In der Anwendung geht es auch um das Speichern von Daten. duckdb ist eine der aktuell sehr populären Technologien, mit der sich Analysen auch sehr gut in Anwendungen realisieren lassen, sodass der Gap in Richtung Analyse gegebenenfalls kleiner ausfällt. Für die Beschreibung der Schnittstellen, wenn Daten zwischen Anwendungen ausgetauscht werden, sind Data Contracts gut geeignet. Vergleichbar mit OpenAPI-Spezifikationen, allerdings für Daten. Und auch nicht nur auf das Schema beschränkt, sondern auch mit SLAs zum Beispiel zur Qualität versehen.

Wer mehr erfahren will, sollte die DWX Developer Week besuchen und dem Vortrag von Matthias am 3. Juli 2025 um 11.30 Uhr im m:con Congress Center Rosengarten in Mannheim beiwohnen. Alle Informationen zur DWX Developer Week gibt es auf www.developer-week.de.