Cloud Architektur Review vorbereiten in 7 Schritten

Ein Architektur-Review scheitert selten an fehlenden Diagrammen. Es scheitert daran, dass Beteiligte über unterschiedliche Probleme sprechen: Das Management erwartet kontrollierbare Kosten, das Produktteam schnellere Releases und der Betrieb weniger Risiken. Wer eine cloud architektur review vorbereiten will, muss diese Erwartungen vor dem Termin in konkrete, überprüfbare Entscheidungen übersetzen. Sonst wird aus einem wichtigen Steuerungsinstrument eine technische Präsentation ohne Folgen.

Für mittelständische Unternehmen ist das besonders relevant. Cloud-Plattformen wachsen oft entlang realer Anforderungen: ein neues Kundenportal, eine API-Integration, zusätzliche Standorte oder steigende Last. Was zunächst pragmatisch funktioniert, kann mit der Zeit zu manuellen Deployments, unklaren Verantwortlichkeiten, unnötigen Kosten und vermeidbaren Ausfallrisiken führen. Ein gut vorbereiteter Review schafft hier keine theoretische Zielarchitektur, sondern einen belastbaren Plan für den produktiven Betrieb.

1. Den Entscheidungsrahmen vor dem Review festlegen

Der erste Schritt ist nicht technisch. Klären Sie, welche Entscheidungen der Review ermöglichen soll. Geht es um die Freigabe einer Migration? Um Risiken vor einem Go-live? Um die Frage, ob Kubernetes für den konkreten Workload sinnvoll ist? Oder um Kosten, die schneller steigen als der Geschäftsnutzen?

Formulieren Sie drei bis fünf überprüfbare Review-Ziele. „Die Architektur bewerten“ ist zu unpräzise. Besser sind Ziele wie: Die Plattform muss einen Ausfall einer Verfügbarkeitszone ohne Datenverlust überstehen. Neue Versionen sollen ohne geplante Downtime ausgerollt werden können. Oder: Die monatlichen Cloud-Kosten müssen je Produkt und Mandant nachvollziehbar sein.

Ebenso wichtig ist der Scope. Ein Review über die gesamte IT-Landschaft bleibt häufig an der Oberfläche. Begrenzen Sie ihn auf eine Plattform, einen kritischen Geschäftsprozess oder eine anstehende Veränderung. Wenn etwa ein E-Commerce-System modernisiert wird, gehören Shop, Zahlungsintegration, Warenwirtschaftsschnittstellen, Datenhaltung und Betriebsprozesse in den Betrachtungsraum. Das interne Wiki oder ein separates HR-System dagegen nur dann, wenn es technische Abhängigkeiten gibt.

2. Die tatsächliche Architektur sichtbar machen

Viele Architekturdiagramme zeigen einen gewünschten Zustand, nicht den produktiven. Für belastbare Entscheidungen zählt jedoch der Ist-Zustand: Welche Komponenten laufen tatsächlich? Wo werden Daten verarbeitet? Welche Zugriffswege existieren? Welche Abhängigkeiten bremsen Releases oder erzeugen Risiken?

Eine brauchbare Darstellung verbindet mehrere Perspektiven. Ein Übersichtsdiagramm zeigt Systeme, Datenflüsse und externe Integrationen. Ergänzend braucht es die Laufzeitansicht: Cloud-Accounts oder Projekte, Netzsegmente, Cluster, Compute-Ressourcen, Datenbanken, Queues und Speicher. Die Deployment-Sicht macht sichtbar, wie Code vom Repository in die Produktion gelangt und an welchen Stellen manuelle Eingriffe nötig sind.

Perfektion ist dabei nicht das Ziel. Ein Diagramm, das zu viele Details aufnimmt, verliert seine Funktion als Entscheidungsgrundlage. Entscheidend ist, dass kritische Annahmen und Grenzen klar markiert sind: öffentlich erreichbare Dienste, Single Points of Failure, besonders schützenswerte Daten, Abhängigkeiten zu Dritten und Komponenten ohne eindeutige Verantwortlichkeit.

3. Cloud Architektur Review vorbereiten: Belege statt Annahmen sammeln

„Die Anwendung ist stabil“ oder „die Kosten sind im Rahmen“ sind keine Review-Ergebnisse. Diese Aussagen brauchen Daten. Sammeln Sie Informationen aus Betrieb, Entwicklung und Fachbereich frühzeitig, damit der Termin nicht zur Rechercheveranstaltung wird.

Für die Vorbereitung haben sich insbesondere diese Unterlagen bewährt:

• aktuelle Architektur- und Datenflussdiagramme mit Eigentümern je Komponente
• Verfügbarkeits-, Latenz- und Fehlerraten aus Monitoring und Logging
• Deployment-Historie, Lead Time und dokumentierte Rollback-Fälle
• Cloud-Kosten der vergangenen Monate, aufgeschlüsselt nach Umgebung, Produkt und Kostenart
• Sicherheitsbefunde, offene Patches, Berechtigungskonzepte und Ergebnisse aus Tests oder Audits

Diese Daten müssen nicht lückenlos sein. Gerade Lücken liefern wertvolle Hinweise. Wenn niemand sagen kann, welches Team eine Datenbank verantwortet, wie lange eine Wiederherstellung dauert oder welchen Umsatz ein Ausfall kostet, ist das bereits ein Befund. Er sollte als Risiko dokumentiert und mit einer konkreten Maßnahme versehen werden.

Besonders aufschlussreich sind reale Betriebsereignisse. Ein Incident aus den vergangenen sechs Monaten zeigt meist deutlicher als jede Folie, ob Alarmierung, Eskalation, Observability und Wiederanlauf funktionieren. Prüfen Sie nicht nur die technische Ursache, sondern auch die Zeit bis zur Erkennung, die Qualität der Informationen im Störungsfall und die Nachhaltigkeit der Korrektur.

4. Sicherheit und Compliance in den Betriebsalltag einordnen

Sicherheit ist kein separater Prüfpunkt am Ende einer Architekturentscheidung. Sie betrifft Identitäten, Netzwerke, Geheimnisse, Images, Daten und den täglichen Betrieb. Ein Review sollte daher klären, ob Schutzmaßnahmen nachvollziehbar umgesetzt und wiederholbar sind.

Beginnen Sie bei den Identitäten. Haben Mitarbeitende, CI/CD-Pipelines und Services nur die Berechtigungen, die sie tatsächlich benötigen? Werden privilegierte Zugriffe protokolliert und regelmäßig überprüft? Lange bestehende Administratorrechte sind in gewachsenen Cloud-Umgebungen ein häufiger Risikofaktor.

Danach folgt der Datenfluss. Sensible Daten sollten hinsichtlich Klassifizierung, Verschlüsselung, Aufbewahrung und Löschung bewertet werden. Dabei gilt: Die passende Lösung hängt vom Schutzbedarf ab. Nicht jede Anwendung benötigt dieselben Kontrollen. Bei personenbezogenen Kundendaten oder geschäftskritischen Transaktionen müssen Verantwortlichkeiten, Zugriffe und Wiederherstellbarkeit aber deutlich strenger nachweisbar sein als bei einer internen Testumgebung.

Auch die Lieferkette gehört auf die Agenda. Werden Abhängigkeiten geprüft? Sind Container-Images nachvollziehbar gebaut und gescannt? Können Secrets versehentlich in Quellcode, Build-Logs oder Konfigurationen geraten? DevSecOps wirkt dann, wenn diese Kontrollen automatisiert in den Delivery-Prozess eingebaut sind und Teams nicht für jede Prüfung auf manuelle Freigaben warten müssen.

5. Betriebsfähigkeit unter realen Bedingungen prüfen

Eine Architektur ist erst dann produktionsreif, wenn sie betrieben werden kann. Das klingt selbstverständlich, wird aber bei Zeitdruck oft verdrängt. Prüfen Sie deshalb gezielt, wie das System auf Last, Teilfehler, fehlerhafte Deployments und Ausfälle externer Dienste reagiert.

Dazu gehören klare Serviceziele. Welche Verfügbarkeit wird benötigt? Welche Antwortzeit ist für Kunden akzeptabel? Wie viel Datenverlust ist vertretbar, und wie schnell muss ein Service nach einem schweren Fehler wiederhergestellt sein? Begriffe wie RTO und RPO sind nur dann nützlich, wenn sie mit fachlichen Auswirkungen verbunden werden. Eine Wiederherstellung binnen vier Stunden kann für ein internes Reporting akzeptabel sein, für eine Bestellplattform aber erhebliche Umsatz- und Reputationsschäden verursachen.

Observability liefert die Grundlage für diese Bewertung. Metriken allein reichen nicht. Teams benötigen nachvollziehbare Logs, Traces über kritische Servicegrenzen hinweg und Alarmierungen, die handlungsfähig machen statt Dauerrauschen zu erzeugen. Ebenso wichtig sind Runbooks: Wer reagiert wann, welche Schritte sind sicher, und wie wird kommuniziert? Wissen, das nur bei einzelnen Personen liegt, ist ein Betriebsrisiko.

6. Kosten als Architekturentscheidung behandeln

Cloud-Kosten entstehen nicht nur durch Rechenleistung. Datenübertragungen, verwaltete Datenbanken, Backups, Logging, ungenutzte Ressourcen und falsch dimensionierte Umgebungen können den größten Anteil ausmachen. Ein Review sollte deshalb Kosten nicht isoliert in einer Rechnung betrachten, sondern mit Lastprofil, Verfügbarkeit und Lieferfähigkeit verbinden.

Fragen Sie konkret: Ist die Kapazität an reale Nutzung gekoppelt? Sind Entwicklungs- und Testumgebungen zeitgesteuert? Lassen sich Kosten einzelnen Produkten, Teams oder Mandanten zuordnen? Werden Reserved Capacity oder Savings-Modelle erst dann eingesetzt, wenn die Grundlast belastbar bekannt ist?

Sparmaßnahmen haben immer Nebenwirkungen. Aggressives Rightsizing kann bei Lastspitzen zu schlechter Performance führen. Kürzere Log-Aufbewahrung reduziert Kosten, kann aber Fehleranalysen und Compliance erschweren. Die richtige Entscheidung entsteht aus Transparenz und klaren Prioritäten, nicht aus einer pauschalen Vorgabe zur Kostensenkung.

7. Den Review als Entscheidungsformat durchführen

Ein effektiver Review braucht die richtigen Rollen am Tisch: Produktverantwortung für Geschäftsauswirkungen, Entwicklung für Änderbarkeit, Betrieb für Verfügbarkeit und Wiederherstellung sowie Security und Datenschutz, wenn Schutzbedarf oder regulatorische Anforderungen dies erfordern. Entscheider sollten nicht erst nachträglich mit einem Maßnahmenpaket überrascht werden.

Strukturieren Sie den Termin entlang der wichtigsten Risiken und Entscheidungen, nicht entlang einzelner Cloud-Services. Für jeden Befund sollten vier Punkte festgehalten werden: Auswirkung, Ursache, verantwortliche Person und Termin für die Umsetzung. Priorisieren Sie nach Geschäftsschaden und Eintrittswahrscheinlichkeit. Ein fehlendes Backup für produktive Kundendaten gehört vor eine kosmetische Optimierung im Deployment-Prozess.

Nicht jede Abweichung muss sofort beseitigt werden. Manche technische Schulden sind bewusst vertretbar, wenn sie dokumentiert, befristet und mit einem klaren Risiko akzeptiert werden. Problematisch wird es, wenn Kompromisse unsichtbar bleiben oder niemand ihre Folgen verantwortet.

Der eigentliche Wert entsteht nach dem Termin. Verankern Sie Maßnahmen im Backlog, planen Sie Investitionen und prüfen Sie deren Wirkung anhand messbarer Kriterien. devRocks begleitet solche Reviews nicht als Folienübung, sondern mit Blick auf die Umsetzung: Infrastruktur automatisieren, Delivery-Pipelines verbessern, Monitoring nachziehen, Sicherheitskontrollen integrieren und den Betrieb dauerhaft stabilisieren.

Eine gute Architektur-Review schafft keine perfekte Cloud-Landschaft. Sie schafft Klarheit darüber, welche Entscheidung jetzt den größten Unterschied für Verfügbarkeit, Liefergeschwindigkeit, Sicherheit und Kostenkontrolle macht - und sorgt dafür, dass diese Entscheidung auch im produktiven Betrieb ankommt.