In Projekten sehen wir immer wieder, dass Unternehmen Migration und Redesign gleichsetzen. Das ist ein Trugschluss. Wer ein monolithisches Datenmodell unverändert in die Cloud überführt, verschiebt Engpässe – er löst sie nicht. Architekturentscheidungen müssen vor der Migration getroffen werden. Andernfalls bleibt die Cloud lediglich ein neuer Betriebsort für alte Strukturen.
Das Problem klassischer Anwendungsarchitekturen
In vielen gewachsenen Systemen übernimmt die relationale Datenbank mehrere Rollen gleichzeitig:
- Transaktionssystem
- Integrationsdrehscheibe
- Reporting-Grundlage
- Speicher für große Binärdaten
- fast immer Träger von Geschäftslogik
Diese Konzentration schafft Abhängigkeiten. Jede Änderung berührt das zentrale System. Jede Skalierungsanforderung wirkt sich auf alle Workloads aus.
Das Resultat:
- Skalierung erfolgt primär vertikal
- Wartungsfenster betreffen das Gesamtsystem
- Performance-Tuning wird komplex
- Innovationsgeschwindigkeit sinkt
Die Datenbank wird vom stabilisierenden Kern zum strukturellen Risiko.
Moderne Architektur: Daten nach Zugriffsmustern denken
Moderne Cloud-Architekturen trennen nicht nur Services – sie trennen Daten nach ihrem Charakter.
Entscheidend ist nicht allein das relationale Modell, sondern das Zugriffsmuster.
Nicht jede Information muss gleich behandelt werden.
Hot Data
Daten mit extrem niedriger Latenzanforderung und hoher Zugriffshäufigkeit, etwa Session-Informationen oder kurzfristige Statusdaten.
Hier bieten sich Key-Value-Modelle oder Cache-Cluster an, um Kernsysteme zu entlasten und Antwortzeiten konsistent niedrig zu halten.
Warm Data
Operativ relevante Daten mit klar definierten Zugriffsmustern, die jedoch nicht zwingend relationale Strukturen benötigen – beispielsweise Ereignis- oder Zeitreihendaten, Graph-Beziehungen oder hochskalierende Key-Value-Strukturen.
Spezialisierte Datenbanksysteme können hier horizontale Skalierung und spezifische Abfragemuster effizienter unterstützen als ein zentrales relationales Modell.
Cold Data
Historische oder analytische Daten mit geringerer Zugriffshäufigkeit, aber hohem Volumen.
Hier stehen Effizienz, Kostenstruktur und analytische Auswertbarkeit im Vordergrund – etwa durch relationale Plattformen, Data-Warehouse-Ansätze oder Data-Lake-Modelle.
Komplexität bewusst gestalten – nicht erhöhen
Die Aufteilung in mehrere spezialisierte Datenmodelle bedeutet jedoch nicht automatisch weniger Komplexität. Im Gegenteil: Mehr Systeme erhöhen zunächst die Anzahl technischer Komponenten.
Entscheidend ist daher nicht die Anzahl der Datenbanken, sondern die Klarheit ihrer Rollen.
Eine moderne Datenarchitektur funktioniert nur dann, wenn:
- Verantwortlichkeiten eindeutig definiert sind
- Datenflüsse transparent dokumentiert werden
- Sicherheits- und Governance-Modelle konsistent umgesetzt werden
- Monitoring und Observability systematisch aufgebaut sind
Redesign heißt nicht, Systeme zu vervielfachen.
Redesign heißt, Workloads gezielt zu entkoppeln und Komplexität strukturiert zu verteilen, statt sie zentral zu konzentrieren.
Architektur wird damit nicht einfacher – aber beherrschbarer.
Ziel-Schema statt 1:1-Übernahme
Ein Architektur-Redesign beginnt nicht mit einem Tool, sondern mit Modellierungsentscheidungen.
Zentrale Fragen sind:
- Welche Daten benötigen starke Transaktionskonsistenz?
- Welche Workloads lassen sich entkoppeln?
- Welche Daten müssen hochverfügbar sein – und welche nicht?
- Wo entstehen Engpässe durch zentrale Speicherung?
Das Ziel ist keine Fragmentierung um der Fragmentierung willen.
Es geht um eine bewusst strukturierte Datenlandschaft, in der jedes System eine klar definierte Rolle übernimmt.
Erst wenn diese Zielarchitektur definiert ist, ergibt sich der nächste Schritt: die Migration.
Architektur folgt nicht nur Technik, sondern Organisation
Nicht jede Organisation benötigt sofort eine hochgradig differenzierte Multi-Database-Architektur. Die Zielstruktur muss zur fachlichen Komplexität, zum Datenvolumen und zur organisatorischen Reife passen.
Eine differenzierte Datenlandschaft erfordert:
- klare Ownership-Modelle
- definierte Betriebsprozesse
- fundiertes Datenbank- und Plattform-Know-how
Redesign bedeutet daher nicht maximale Diversifikation, sondern angemessene Strukturierung. In manchen Szenarien genügt eine sauber skalierende relationale Plattform. In anderen Fällen ist die Trennung von Workloads zwingend notwendig.
Architekturentscheidungen sind keine Technologie-Demonstration.
Sie sind eine bewusste Abwägung zwischen fachlichem Bedarf, organisatorischer Leistungsfähigkeit und wirtschaftlichem Rahmen.
Architekturarbeit vor Migrationsprojekt
Eine Migration ohne vorheriges Redesign überführt bestehende Engpässe lediglich in eine neue Umgebung. Erst wenn Architektur, Datenmodelle und Workload-Verteilung bewusst definiert sind, kann eine Migration ihr Potenzial entfalten.
Bei PROTOS verstehen wir diesen Schritt als strategische Architekturarbeit. Technologie folgt dem Design – nicht umgekehrt. Die operative Überführung gewachsener Datenbank-Monolithen in diese Zielarchitektur ist der nächste logische Schritt.
