Enterprise Architektur

Architektur-Review: So bewerten Sie Ihre Systemlandschaft objektiv

Systematische Architektur-Bewertung für IT-Entscheider – mit erprobter Methodik, Checklisten und Risikomatrix zur objektiven Analyse Ihrer Systemlandschaft und Ableitung konkreter Modernisierungs-Maßnahmen.

📖 17 Min. Lesezeit
Architektur-Review Enterprise Architecture Technical Debt System-Bewertung Modernisierung Risikomatrix IT-Due-Diligence .NET

"Ist unsere Architektur zukunftsfähig?" Diese Frage stellen mir CTOs und IT-Leiter regelmäßig – und erwarten eine klare Antwort. Die Antwort ist nie simpel, aber sie lässt sich strukturiert herleiten.

Für wen dieser Artikel relevant ist: CTOs, IT-Leiter und Enterprise-Architekten im Mittelstand, die vor einem Architektur-Review stehen – entweder als Vorbereitung auf strategische Investitionen, nach einem Führungswechsel oder als Reaktion auf spürbare Probleme (sinkende Velocity, steigende Incidents, M&A).

In den meisten Organisationen fehlt eine systematische Bewertung der eigenen Systemlandschaft. Stattdessen regieren Bauchgefühl und die gefährliche Illusion, ein laufendes System sei ein gutes System. "Es läuft" ist kein Qualitätskriterium, sondern das Minimum. Die entscheidenden Fragen: Wie schnell liefern wir neue Features? Wie verhalten sich Betriebskosten zum Geschäftswert? Wie resilient ist das System unter Last und bei Ausfällen? Sind wir in zwei Jahren noch wettbewerbsfähig?

Dieser Leitfaden liefert ein erprobtes Framework für Architektur-Reviews. Er basiert auf Reviews aus über 15 Jahren Projekt- und Führungspraxis, in Organisationen von 20 bis 500 Entwicklern – von Finanzdienstleistungen über E-Commerce bis Industrie. Methodik praxiserprobt, Ergebnisse messbar, Maßnahmen für Entscheider verständlich.

Wann ein Architektur-Review sinnvoll ist: Die Warnsignale

Frühwarnsignale, die auf strukturelle Probleme hindeuten

Viele Organisationen warten, bis die Probleme unübersehbar sind. Dabei gibt es klare Indikatoren, die früh auf strukturelle Schwächen hinweisen:

Verlangsamte Feature-Entwicklung: Das zuverlässigste Warnsignal. Wenn Features, die früher in zwei Wochen umgesetzt wurden, jetzt sechs bis acht Wochen benötigen – ohne dass die fachliche Komplexität gestiegen ist – liegt das Problem fast immer in der Architektur. Die Codebase ist so stark verwoben, dass jede Änderung Seiteneffekte in unerwarteten Bereichen auslöst.

Explodierende Betriebskosten: Die monatlichen Cloud-Kosten steigen stärker als die Nutzerzahlen. Oder die Wartungskosten für Legacy-Systeme verschlingen 70-80% des IT-Budgets. Beides sind Symptome architektonischer Probleme, die sich nicht durch Optimierung einzelner Komponenten lösen lassen.

Rekrutierungsprobleme: Wenn qualifizierte Entwickler im Bewerbungsprozess abspringen, nachdem sie den Tech-Stack gesehen haben, ist das ein starkes Signal. Moderne Engineers wollen mit modernen Technologien arbeiten. Ein veralteter Stack wird zum Wettbewerbsnachteil im Recruiting-Markt.

Häufige Incidents und lange Recovery-Zeiten: Wenn Production-Incidents wöchentlich auftreten und die Mean Time to Recovery (MTTR) Stunden statt Minuten beträgt, ist die Architektur nicht resilient genug. Das Problem liegt selten an den Ops-Teams, sondern an fehlender Fehlertoleranz im System-Design.

Strategische Anlässe

Neben Warnsignalen gibt es strategische Anlässe, die einen Architektur-Review erfordern:

  • Wachstumspläne: Vor einer geplanten Verdopplung der Nutzerbasis oder Expansion in neue Märkte sollten Sie wissen, ob Ihre Architektur das trägt.
  • M&A-Aktivitäten: Bei Übernahmen oder Fusionen müssen Systemlandschaften zusammengeführt werden. Ein Review beider Seiten ist essenziell.
  • Compliance-Anforderungen: Neue Regulierungen wie NIS2, DORA oder branchenspezifische Standards erfordern oft architektonische Anpassungen.
  • Technologie-Wechsel: Wenn ein zentrales Framework oder eine Plattform End-of-Life erreicht, ist ein Review der richtige Zeitpunkt für eine strategische Neuausrichtung.
  • Neuer CTO oder IT-Leiter: Ein frischer Blick auf die bestehende Landschaft ist einer der wertvollsten ersten Schritte in einer neuen Führungsrolle.

Die sechs Bewertungsdimensionen

Ein strukturierter Architektur-Review bewertet die Systemlandschaft entlang sechs zentraler Dimensionen. Jede Dimension hat eigene Metriken, Bewertungskriterien und typische Schwachstellen.

1. Skalierbarkeit

Kernfrage: Kann das System mit wachsender Last umgehen, ohne dass Performance oder Stabilität leiden?

Bewertungskriterien:

  • Horizontale Skalierbarkeit: Können Komponenten unabhängig skaliert werden?
  • Elastizität: Passt sich das System automatisch an Lastschwankungen an?
  • Bottleneck-Analyse: Wo sind die engsten Stellen (Datenbank, API-Gateway, Message-Queue)?
  • Datenbank-Skalierung: Ist die Datenschicht skalierbar (Read-Replicas, Sharding, Caching)?

Typische Findings:

  • Monolithische Datenbank als Single Point of Failure und Performance-Bottleneck
  • Synchrone Kommunikation zwischen Services, die Kaskaden-Ausfälle verursacht
  • Fehlende Caching-Strategie, die zu redundanten Datenbankzugriffen führt
  • Session-Affinität, die horizontale Skalierung verhindert

Bewertungsskala (1-5): 1 = Keine Skalierbarkeit, vertikale Skalierung ausgereizt 2 = Begrenzte Skalierbarkeit mit manuellen Eingriffen 3 = Moderate Skalierbarkeit, einige Bottlenecks identifiziert 4 = Gute Skalierbarkeit, automatisierte Skalierung für Kernkomponenten 5 = Exzellente Skalierbarkeit, vollständig elastisch und resilient

2. Wartbarkeit

Kernfrage: Wie aufwändig ist es, das System zu verstehen, zu ändern und zu erweitern?

Bewertungskriterien:

  • Code-Qualität: Lesbarkeit, Konsistenz, Testabdeckung
  • Modularität: Klare Modul-Grenzen, lose Kopplung, hohe Kohäsion
  • Dokumentation: Architektur-Entscheidungen (ADRs), API-Dokumentation, Onboarding-Guides
  • Deployment-Komplexität: Wie einfach ist ein Release? Automatisiert oder manuell?
  • Onboarding-Zeit: Wie lange braucht ein neuer Entwickler, um produktiv zu werden?

Benchmark: In gut wartbaren Systemen benötigt ein neuer Senior-Entwickler 2-4 Wochen bis zur ersten produktiven Contribution. In schlecht wartbaren Systemen sind es 3-6 Monate.

3. Sicherheit

Kernfrage: Wie gut ist das System gegen Angriffe geschützt, und werden regulatorische Anforderungen erfüllt?

Bewertungskriterien:

  • Authentication und Authorization: Moderne Standards (OAuth2, OIDC), Least-Privilege-Prinzip
  • Datenverschlüsselung: At-Rest und In-Transit
  • Vulnerability-Management: Regelmäßige Dependency-Scans, Patch-Zyklen
  • Security-by-Design: Ist Sicherheit in der Architektur verankert oder nachträglich aufgesetzt?
  • Compliance: DSGVO, branchenspezifische Standards, Audit-Fähigkeit

Warnsignal: Wenn die Antwort auf "Wann war der letzte Penetration-Test?" lautet "Nie" oder "Vor drei Jahren", besteht dringender Handlungsbedarf.

4. Performance

Kernfrage: Erfüllt das System die Anforderungen an Antwortzeiten und Durchsatz – auch unter Last?

Bewertungskriterien:

  • Response-Zeiten: P50, P95, P99 Latenz für kritische Endpunkte
  • Durchsatz: Requests pro Sekunde unter normaler und erhöhter Last
  • Ressourcen-Effizienz: CPU/Memory-Auslastung im Verhältnis zur Last
  • Monitoring und Observability: Können Performance-Probleme proaktiv erkannt werden?

Praxistipp: Viele Organisationen messen nur Durchschnitts-Latenzen. Das ist gefährlich. Ein System mit 200ms Durchschnitts-Latenz klingt gut – aber wenn die P99-Latenz bei 8 Sekunden liegt, haben 1% der Nutzer eine katastrophale Erfahrung. Messen Sie immer Percentile.

5. Betriebskosten

Kernfrage: Stehen die Kosten für Betrieb und Wartung in einem gesunden Verhältnis zum Geschäftswert?

Bewertungskriterien:

  • Total Cost of Ownership (TCO): Infrastruktur, Lizenzen, Personal, externe Dienstleister
  • Kosten pro Transaktion: Was kostet eine einzelne Geschäftstransaktion in der Infrastruktur?
  • Wartungskosten-Ratio: Wie viel Prozent des IT-Budgets fließen in Wartung vs. Innovation?
  • Vendor-Lock-in: Wie abhängig sind Sie von einzelnen Anbietern oder Dienstleistern?

Benchmark: In gesunden Organisationen liegt das Verhältnis von Wartung zu Innovation bei 40:60 bis 50:50. Wenn mehr als 70% des Budgets in "Keeping the lights on" fließen, ist das ein klares Warnsignal.

6. Technical Debt

Kernfrage: Wie hoch ist die angesammelte technische Schuld, und wie stark bremst sie die Entwicklungsgeschwindigkeit?

Bewertungskriterien:

  • Code-Alter: Anteil der Codebase, der älter als 5 Jahre ist und nie refactored wurde
  • Dependency-Alter: Anteil veralteter oder nicht mehr gepflegter Abhängigkeiten
  • Architektonische Schuld: Fundamentale Design-Entscheidungen, die sich als falsch herausgestellt haben
  • Prozess-Schuld: Fehlende Tests, fehlende CI/CD, manuelle Deployment-Prozesse
  • Bekannte Workarounds: Dokumentierte oder undokumentierte Hacks, die "irgendwann" gefixt werden sollen

Quantifizierung: Ich nutze die "Debt-to-Development-Ratio" als zentrale Metrik: Wie viel Prozent der Entwicklungszeit wird durch Technical Debt verlangsamt? Alles über 25% erfordert sofortige Aufmerksamkeit.

Methodik: Der Review-Prozess in der Praxis

Ein effektiver Architektur-Review folgt einem strukturierten Prozess, der in vier Phasen abläuft. Die Gesamtdauer beträgt typischerweise 3-6 Wochen, abhängig von der Größe und Komplexität der Systemlandschaft.

Phase 1: Vorbereitung und Scoping (Woche 1)

Ziel: Klares Verständnis des Scope, der Erwartungen und der verfügbaren Informationsquellen.

Checkliste Vorbereitung:

  • Review-Ziele mit Auftraggeber (CTO/IT-Leiter) abstimmen
  • Systemlandschaft grob erfassen (Anzahl Systeme, Technologien, Teams)
  • Vorhandene Dokumentation sichten (Architektur-Diagramme, ADRs, Betriebshandbücher)
  • Stakeholder-Liste erstellen (Architekten, Team-Leads, Ops, Product Owner, Business)
  • Interview-Termine planen (typischerweise 8-15 Interviews)
  • Zugang zu Code-Repositories, Monitoring-Dashboards und CI/CD-Pipelines klären
  • Bewertungsrahmen und Dimensionen mit Auftraggeber abstimmen

Wichtig: Kommunizieren Sie früh und klar, dass ein Architektur-Review kein Tribunal ist. Es geht nicht darum, Schuldige zu finden, sondern den Ist-Zustand objektiv zu erfassen und Verbesserungspotenziale zu identifizieren. Ohne dieses Framing werden Stakeholder defensiv und liefern keine ehrlichen Einschätzungen.

Phase 2: Datenerhebung (Woche 2-3)

Die Datenerhebung stützt sich auf drei Säulen: Stakeholder-Interviews, Code- und Infrastruktur-Analyse, und Metriken-Auswertung.

Stakeholder-Interviews:

Interviews sind die wertvollste Informationsquelle – aber nur, wenn sie richtig geführt werden. Technische Teams wissen fast immer, wo die Probleme liegen. Sie sprechen nur selten darüber, weil niemand fragt oder weil sie fürchten, dass Ehrlichkeit negative Konsequenzen hat.

Bewährte Interview-Leitfragen nach Rolle:

Für Entwickler und Architekten:

  • Wo verbringen Sie die meiste Zeit mit Workarounds statt mit Feature-Entwicklung?
  • Welche Teile der Codebase würden Sie am liebsten neu schreiben – und warum?
  • Wie lange dauert ein typisches Deployment von Commit bis Production?
  • Was bricht am häufigsten, und wie lange dauert die Behebung?

Für Ops und DevOps:

  • Wie viele Production-Incidents hatten Sie in den letzten 3 Monaten?
  • Was sind die häufigsten Ursachen für Ausfälle?
  • Wie ist der Automatisierungsgrad Ihrer Infrastruktur?
  • Welche Systeme bereiten Ihnen die größten Sorgen?

Für Product Owner und Business-Stakeholder:

  • Wie zufrieden sind Sie mit der Geschwindigkeit der Feature-Entwicklung?
  • Welche Features wurden aufgrund technischer Limitierungen abgelehnt oder verschoben?
  • Wo sehen Sie die größten Engpässe in der Zusammenarbeit mit der IT?

Code- und Infrastruktur-Analyse:

Neben den subjektiven Einschätzungen aus Interviews nutze ich eine Reihe von Tools für die objektive Analyse:

Statische Code-Analyse:

  • SonarQube/SonarCloud: Code-Qualität, Bugs, Vulnerabilities, Code-Smells, Testabdeckung
  • NDepend (.NET) oder Structure101 (Java): Abhängigkeitsanalyse, zyklische Abhängigkeiten, architektonische Verletzungen
  • OWASP Dependency-Check: Bekannte Sicherheitslücken in Abhängigkeiten

Architektur-Analyse:

  • Dependency-Graphen: Visualisierung der Abhängigkeiten zwischen Services und Modulen
  • Coupling-Analyse: Messung der Kopplung zwischen Komponenten (afferent/efferent coupling)
  • Change-Coupling: Welche Dateien werden immer zusammen geändert? (Hinweis auf versteckte Abhängigkeiten)

Infrastruktur-Analyse:

  • Cloud-Cost-Analyse: AWS Cost Explorer, Azure Cost Management oder vergleichbare Tools
  • Monitoring-Auswertung: Prometheus/Grafana, Datadog, New Relic – Analyse der letzten 3-6 Monate
  • Deployment-Metriken: Deployment-Frequenz, Lead-Time, Change-Failure-Rate, MTTR (DORA-Metriken)

Phase 3: Analyse und Bewertung (Woche 4)

Ziel: Synthese aller erhobenen Daten zu einem kohärenten Gesamtbild mit klaren Findings und Empfehlungen.

In dieser Phase konsolidiere ich die Erkenntnisse aus Interviews, Code-Analyse und Metriken. Jedes Finding wird nach folgendem Schema dokumentiert:

Finding-Template:

  • Titel: Kurze, prägnante Beschreibung
  • Dimension: Welche Bewertungsdimension ist betroffen?
  • Schweregrad: Kritisch / Hoch / Mittel / Niedrig
  • Beschreibung: Was wurde festgestellt?
  • Auswirkung: Welche konkreten Business-Auswirkungen hat dieses Finding?
  • Evidenz: Daten, Metriken, Zitate aus Interviews
  • Empfehlung: Vorgeschlagene Maßnahme
  • Aufwand: Grobe Schätzung (T-Shirt-Sizing: S/M/L/XL)

Priorisierung der Findings: Die Risikomatrix

Nicht alle Findings sind gleich wichtig. Die größte Herausforderung eines Architektur-Reviews ist nicht die Identifikation von Problemen – davon gibt es immer reichlich – sondern deren Priorisierung. Entscheider brauchen eine klare Antwort auf die Frage: Was müssen wir zuerst angehen?

Die Impact-Effort-Risikomatrix

Ich verwende eine zweidimensionale Matrix, die Business-Impact und Umsetzungsaufwand kombiniert:

Quadrant 1 – Quick Wins (Hoher Impact, Niedriger Aufwand): Sofort umsetzen. Diese Maßnahmen liefern schnellen, sichtbaren Mehrwert und bauen Momentum auf. Beispiele: Caching-Layer einführen, Monitoring verbessern, kritische Dependency-Updates durchführen.

Quadrant 2 – Strategische Projekte (Hoher Impact, Hoher Aufwand): Planen und in die Roadmap aufnehmen. Diese Maßnahmen erfordern signifikante Investitionen, sind aber für die langfristige Zukunftsfähigkeit essenziell. Beispiele: Monolith-Dekomposition, Datenbank-Migration, Einführung einer Event-Driven-Architektur.

Quadrant 3 – Füllmaterial (Niedriger Impact, Niedriger Aufwand): Bei Gelegenheit umsetzen, zum Beispiel als Teil regulärer Sprints. Nicht priorisieren, aber auch nicht ignorieren. Beispiele: Code-Formatting vereinheitlichen, veraltete Dokumentation aktualisieren, kleine Refactorings.

Quadrant 4 – Zeitfresser (Niedriger Impact, Hoher Aufwand): Bewusst zurückstellen oder streichen. Diese Maßnahmen binden Ressourcen ohne angemessenen Return. Beispiele: Migration eines stabilen Legacy-Moduls, das keine Änderungen erfordert; Einführung einer neuen Technologie in einem Bereich mit geringer Business-Relevanz.

Risikobewertung für Entscheider

Für die Kommunikation an CTOs und Geschäftsführung übersetze ich technische Findings in Business-Risiken:

Kritische Risiken (Sofortige Maßnahme erforderlich):

  • Sicherheitslücken, die aktiv ausgenutzt werden könnten
  • Single Points of Failure in geschäftskritischen Systemen
  • Compliance-Verstöße mit regulatorischen Konsequenzen

Hohe Risiken (Maßnahme innerhalb von 3 Monaten):

  • Performance-Engpässe, die das Nutzererlebnis signifikant beeinträchtigen
  • Abhängigkeit von End-of-Life-Technologien ohne Migrationspfad
  • Wissenskonzentration auf einzelne Personen ("Bus-Faktor 1")

Mittlere Risiken (Maßnahme innerhalb von 6-12 Monaten):

  • Steigende Betriebskosten ohne korrespondierende Wertschöpfung
  • Wachsende Technical Debt, die die Entwicklungsgeschwindigkeit bremst
  • Fehlende Automatisierung in Build-, Test- und Deployment-Prozessen

Niedrige Risiken (In Roadmap aufnehmen):

  • Architektonische Verbesserungen ohne unmittelbaren Business-Impact
  • Technologie-Updates, die mittelfristig relevant werden
  • Prozessverbesserungen für bessere Developer Experience

Von der Bewertung zur Roadmap

Ein Architektur-Review, der in einer Schublade landet, ist verschwendete Zeit und Geld. Der eigentliche Wert entsteht in der Umsetzung. Deshalb mündet jeder meiner Reviews in eine konkrete, umsetzbare Roadmap.

Die 30-90-180-Tage-Struktur

Erste 30 Tage – Quick Wins und Stabilisierung:

Fokus auf Maßnahmen aus Quadrant 1 der Risikomatrix. Ziel: Schnelle, sichtbare Verbesserungen, die Vertrauen in den Prozess schaffen und die dringendsten Risiken adressieren.

Typische Maßnahmen:

  • Kritische Sicherheitslücken schließen
  • Monitoring und Alerting für geschäftskritische Systeme einrichten oder verbessern
  • Offensichtliche Performance-Bottlenecks beseitigen (Caching, Index-Optimierung)
  • Dokumentation kritischer Architektur-Entscheidungen starten

Tag 31-90 – Fundament legen:

Fokus auf strukturelle Verbesserungen, die die Basis für größere Veränderungen schaffen.

Typische Maßnahmen:

  • CI/CD-Pipeline aufbauen oder verbessern
  • Testabdeckung für kritische Pfade erhöhen
  • Dependency-Management systematisieren
  • Erste Dekompositions-Schritte bei monolithischen Systemen (Strangler-Fig-Ansatz)
  • Observability-Stack implementieren (Logging, Tracing, Metrics)

Tag 91-180 – Strategische Transformation:

Fokus auf die großen architektonischen Veränderungen aus Quadrant 2.

Typische Maßnahmen:

  • Architektur-Modernisierung gemäß definiertem Zielarchitektur-Bild
  • Migration kritischer Komponenten
  • Aufbau neuer Capabilities (Event-Driven, API-First, Cloud-Native)
  • Etablierung architektonischer Governance-Prozesse

Business-Case für den Architektur-Review

CTOs und IT-Leiter müssen den Review intern rechtfertigen. Hier die Argumente, die in meiner Erfahrung am überzeugendsten sind:

Kostenargument: Ein typischer Architektur-Review kostet 40.000-80.000 Euro (3-6 Wochen, 1-2 Senior-Architekten). Die identifizierten Quick Wins amortisieren diese Investition in der Regel innerhalb von 3-6 Monaten durch reduzierte Betriebskosten, weniger Incidents oder höhere Entwicklungsgeschwindigkeit.

Risikoargument: Ein nicht durchgeführter Review bedeutet, dass Sie auf Basis unvollständiger Informationen Investitionsentscheidungen treffen. Das ist, als würden Sie ein Haus kaufen, ohne es vorher inspizieren zu lassen.

Strategieargument: Ohne klares Bild des Ist-Zustands ist jede Technologie-Roadmap Spekulation. Der Review schafft die faktische Basis für strategische Planung.

Typische Findings und Quick Wins

In meinen Architektur-Reviews tauchen bestimmte Findings immer wieder auf – weitgehend unabhängig von Branche und Unternehmensgröße. Diese Liste kann als erste Orientierung dienen; die Häufigkeitsangaben sind Erfahrungswerte aus der Praxis.

Die Top-10 der häufigsten Findings

1. Fehlende oder veraltete Architektur-Dokumentation Häufigkeit: praktisch in jedem Review. Die meisten Organisationen haben entweder keine Architektur-Dokumentation oder Diagramme, die drei Jahre alt sind und die aktuelle Realität nicht mehr abbilden. Quick Win: Architecture Decision Records (ADRs) einführen – lightweight, versioniert, nah am Code.

2. Unzureichende Testabdeckung Häufigkeit: in der großen Mehrheit der Reviews. Besonders kritische Geschäftslogik ist oft schlecht getestet. Das Ergebnis: Angst vor Änderungen, lange manuelle Test-Zyklen, häufige Regressionen. Quick Win: Test-Coverage für die 20% des Codes erhöhen, der 80% der Business-Logik enthält.

3. Monolithische Datenbank als Bottleneck Häufigkeit: in etwa drei von vier Reviews. Eine zentrale relationale Datenbank, die von allen Modulen oder Services gemeinsam genutzt wird, ist der häufigste architektonische Engpass. Quick Win: Read-Replicas einrichten, Caching-Layer einführen, langfristig Domain-spezifische Datenhaltung planen.

4. Fehlende Observability Häufigkeit: in gut zwei Dritteln der Reviews. Teams können nicht beantworten: "Wie performt unser System gerade?" oder "Was war die Ursache des letzten Incidents?" Quick Win: Zentrales Logging und grundlegendes Monitoring einführen. Bereits Prometheus plus Grafana oder ein verwalteter Service wie Datadog liefern enorme Sichtbarkeit.

5. Manuelle Deployment-Prozesse Häufigkeit: in mehr als der Hälfte der Reviews. Deployments erfordern manuelle Schritte und spezifisches Wissen einzelner Personen und finden nur selten statt – oft verbunden mit hohem Risiko. Quick Win: Einfache CI/CD-Pipeline aufsetzen. Selbst eine Pipeline, die nur Build und automatisierte Tests ausführt, ist ein enormer Fortschritt.

6. Veraltete Dependencies mit bekannten Sicherheitslücken Häufigkeit: in vier von fünf Reviews. NuGet-Pakete, npm-Module oder Maven-Dependencies, die seit Jahren nicht aktualisiert wurden und bekannte CVEs aufweisen. Quick Win: Automatisiertes Dependency-Scanning einführen (Dependabot, Renovate, OWASP Dependency-Check) und kritische Vulnerabilities sofort patchen.

7. Wissenssilos und Bus-Faktor 1 Häufigkeit: in rund zwei Dritteln der Reviews. Kritische Systeme oder Module, die nur eine einzige Person versteht. Wenn diese Person ausfällt, ist das Wissen verloren. Quick Win: Pair-Programming und Code-Reviews für kritische Bereiche einführen. Dokumentation der wichtigsten Abläufe und Entscheidungen.

8. Fehlende API-Strategie Häufigkeit: in etwa jedem zweiten Review. APIs sind inkonsistent (verschiedene Stile, fehlende Versionierung, keine Dokumentation), was die Integration zwischen Systemen und mit externen Partnern erschwert. Quick Win: API-Design-Guidelines definieren und für neue APIs durchsetzen. Bestehende kritische APIs dokumentieren.

9. Überdimensionierte oder fehlkonfigurierte Cloud-Infrastruktur Häufigkeit: in rund der Hälfte der Reviews bei Cloud-nutzenden Organisationen. Instanzen, die dauerhaft mit 10% Auslastung laufen, vergessene Entwicklungs-Umgebungen, fehlende Auto-Scaling-Konfiguration. Quick Win: Cloud-Cost-Audit durchführen, Right-Sizing der Instanzen, ungenutzte Ressourcen abschalten. Typische Ersparnis: 20-40% der Cloud-Kosten.

10. Fehlende Disaster-Recovery-Strategie Häufigkeit: in knapp der Hälfte der Reviews. Kein dokumentierter und getesteter Plan für den Ausfall geschäftskritischer Systeme. Backups existieren oft, wurden aber nie auf Wiederherstellbarkeit getestet. Quick Win: Recovery-Plan dokumentieren und einen Restore-Test für die wichtigsten Systeme durchführen.

Checkliste für Ihren eigenen Architektur-Review

Falls Sie zunächst eine Selbsteinschätzung vornehmen möchten, bevor Sie einen externen Review beauftragen, bietet diese Checkliste eine solide Ausgangsbasis. Beantworten Sie jede Frage ehrlich – idealerweise im Team, nicht allein.

Strategische Ebene

  • Existiert ein dokumentiertes Zielarchitektur-Bild?
  • Ist die Technologie-Strategie mit der Geschäftsstrategie abgestimmt?
  • Gibt es ein dokumentiertes Technical-Debt-Register?
  • Werden Architektur-Entscheidungen systematisch dokumentiert (ADRs)?
  • Existiert ein Technologie-Radar mit klaren Adopt/Trial/Assess/Hold-Kategorien?

Technische Ebene

  • Liegt die Testabdeckung kritischer Geschäftslogik über 70%?
  • Sind alle Dependencies auf aktuellem Stand (oder gibt es einen dokumentierten Plan)?
  • Existieren automatisierte CI/CD-Pipelines für alle produktiven Systeme?
  • Werden DORA-Metriken gemessen (Deployment-Frequenz, Lead-Time, MTTR, Change-Failure-Rate)?
  • Gibt es eine Observability-Strategie (Logging, Metrics, Tracing)?

Betriebliche Ebene

  • Existiert eine dokumentierte und getestete Disaster-Recovery-Strategie?
  • Werden Sicherheits-Scans regelmäßig durchgeführt?
  • Liegt das Verhältnis Wartung:Innovation unter 60:40?
  • Sind die Cloud-/Infrastrukturkosten optimiert und transparent?
  • Gibt es SLAs/SLOs für geschäftskritische Systeme?

Organisatorische Ebene

  • Ist der Bus-Faktor für alle kritischen Systeme größer als 1?
  • Können neue Entwickler innerhalb von 4 Wochen produktiv beitragen?
  • Gibt es regelmäßige Architektur-Reviews (mindestens jährlich)?
  • Existiert ein Prozess für Architektur-Governance?
  • Werden Post-Mortems nach Incidents durchgeführt und deren Erkenntnisse umgesetzt?

Scoring: Zählen Sie die Ja-Antworten. Weniger als 10 von 20: Dringender Handlungsbedarf. 10-15: Verbesserungspotenzial, gezielter Review empfohlen. 16-20: Gute Basis, periodischer Review zur Validierung.

Weiterführende Artikel:

Fazit: Drei Schritte für die nächsten 30 Tage

Ein Architektur-Review ist kein Prüfbericht, sondern der Startpunkt eines kontinuierlichen Steuerungsprozesses. Wenn Sie jetzt handeln wollen:

1. Füllen Sie die Checkliste aus diesem Artikel aus – ehrlich, im Führungsteam. Weniger als 10 Ja-Antworten bedeuten dringenden Handlungsbedarf. Diese Selbsteinschätzung kostet zwei Stunden und gibt Ihnen eine erste Priorisierung.

2. Übersetzen Sie Ihr größtes Finding in Business-Sprache. "Wir haben Technical Debt" bewegt keinen Vorstand. "Unsere Feature-Delivery-Geschwindigkeit hat sich halbiert, dadurch verzögern sich drei Umsatz-relevante Projekte" bewegt Budgets.

3. Entscheiden Sie: externer Review oder interner Prozess. Externe Reviews bringen Objektivität und Geschwindigkeit, interne Reviews Kontinuität. Beides funktioniert – Nichts-Tun funktioniert nicht.

Ihre Systemlandschaft ist das Fundament Ihrer digitalen Wertschöpfung. Behandeln Sie sie entsprechend.

Nächste Schritte

← Zurück zu allen Publikationen