Der Ausgangspunkt: der Code

Eine Architektur-Dokumentation beschreibt, wie ein System einmal geplant war. Eine Architektur-Analyse zeigt, wie es heute tatsächlich funktioniert. Die Arbeit beginnt deshalb am Code, an der Infrastrukturkonfiguration und an den Monitoring-Daten, bevor ein Gespräch mit deinem Team stattfindet. Diese Reihenfolge macht die anschließenden Fragen an deine Ingenieure präziser, weil wir das System zu diesem Zeitpunkt schon verstehen. Die Ergebnisse stützen sich auf das tatsächliche Verhalten deines Systems unter Last, jenseits reiner Annahmen des Teams.

KI-gestützte Code-Analyse

Wo es die Governance-Vorgaben deines Unternehmens zulassen, ergänzen wir die manuelle Prüfung um KI-gestützte Werkzeuge. Sie decken statische Analysen, Abhängigkeits-Mappings, Lücken in der Testabdeckung und architektonische Fehlmuster ab. Das Ergebnis ist eine Liste von Erkenntnissen, die den tatsächlichen Code widerspiegelt – unabhängig davon, was dein Team über den Code annimmt.

Systemtopologie und Datenfluss

Wir erfassen in diesem Bereich, was tatsächlich existiert: Dienste, Abhängigkeiten, Datenspeicher, Integrationspunkte und externe Schnittstellen, abgeglichen mit der vorhandenen Dokumentation. Schon Abweichungen zwischen beidem zählen als wichtige Erkenntnis. Wir verfolgen die Datenflüsse durch das System, um zu erkennen, wo die Kopplung zu eng ist und wo Grenzen unklar sind. Ebenso wichtig ist, ob ein Fehler in einer Komponente unbemerkt auf andere übergreift.

Skalierbarkeit und Lastverhalten

Grundlage sind aktuelle Verkehrsdaten und Datenbankabfrage-Muster, dazu die Infrastrukturkonfiguration deines Systems. Zustandsbehaftete Dienste, die eine horizontale Skalierung verhindern, fehlende Caching-Schichten, synchrone Abhängigkeiten, die Latenzketten erzeugen, sowie Datenbankschemata, die mit wachsendem Datenvolumen an Leistung verlieren, gehören dazu.

Resilienz und Fehlerbilder

Wir analysieren Ausfallszenarien, etwa den Ausfall einer Abhängigkeit, eine überlaufende Warteschlange oder eine fehlschlagende Bereitstellung. Wiederholungslogiken, Circuit Breaker, Ausweichpfade und die Abdeckung durch Observability werden dabei bewertet. Ein System, das im Normalbetrieb einwandfrei funktioniert und unter Belastung still versagt, trägt ein Risiko, das in gewöhnlichen Code-Überprüfungen selten sichtbar wird.

Wartbarkeit und Betriebskosten

Wir bewerten den Entwicklungsaufwand, der in deiner bestehenden Architektur steckt: wie schwierig die Einarbeitung neuer Entwickler ist und wie lange Bereitstellungen dauern. Hinzu kommt, wie viel manuelles Eingreifen Routinevorgänge noch erfordern. Technische Schulden gelten dabei als reale Kosten, die wir nach Möglichkeit beziffern, zusammen mit der Stelle, an der sie sich am schnellsten anhäufen. Fehlende Dokumentation brachte bei einer europäischen Handelsgenossenschaft genau dieses Problem an den Tag: Neue Entwickler brauchten Monate, um sich zurechtzufinden, bis eine vollständige Systemdokumentation entstand, die es zuvor nicht gab.

Sicherheitsrelevante Angriffsfläche

Wir identifizieren in diesem Bereich, was auf Architekturebene angreifbar ist: öffentlich erreichbare Endpunkte, die es nicht sein sollten, überprivilegierte Servicekonten, fehlende Verschlüsselung bei der Übertragung oder im Ruhezustand, Authentifizierungsabläufe, die zentrale Identitätssysteme umgehen, sowie Infrastruktur, die Produktionsgeheimnisse an ungeeigneten Stellen speichert.

Deine priorisierte Bewertung

Du bekommst am Ende eine schriftliche Bewertung, aufgebaut um Erkenntnisse und Empfehlungen – ausdrücklich kein Foliensatz –, die du in Ruhe nachlesen und mit deinem Team teilen kannst. Erkenntnisse ordnen wir nach Schweregrad und Kategorie ein, Empfehlungen priorisieren wir nach Wirkung und Umsetzungsaufwand, sodass die ersten zehn Punkte der Liste den größten Nutzen bei geringstem Aufwand bringen.

Wir erweitern die Ergebnisse auf Wunsch um eine vorgeschlagene Zielarchitektur: Migrationsreihenfolge und Abhängigkeitsordnung, dazu ein realistischer Zeitplan. Diese Erweiterung wird gesondert berechnet.

Ablauf und Dauer

Eine Standard-Architektur-Analyse dauert zwei bis drei Wochen. Größere oder komplexere Systeme brauchen mehr Zeit. Das wird vorab geklärt, und der Umfang wächst nur nach Absprache. Die Abschlusssitzung ist als Arbeitsbesprechung angelegt, keine Präsentation vor Publikum: ein Dialog, in dem dein Team Rückmeldung geben und Kontext ergänzen kann, bis hin zur gemeinsamen Priorisierung.

Für wen sich die Analyse eignet

Die Analyse ist für neue technische Führungskräfte gedacht, die eine ehrliche Bestandsaufnahme brauchen, etwa einen frisch eingesetzten CTO oder VP Engineering, der ein System übernimmt, das er noch nicht kennt. Die vorhandene Dokumentation und die Aussagen des bestehenden Teams zählen zu Beginn meist als einzige Quelle für dich, während die Analyse zeigt, was wirklich im Code steckt. Das Ergebnis ist eine schriftliche Bewertung – ein konkretes, belastbares Arbeitsdokument. Ein regionaler Fensterhersteller übernahm nach einem Anbieterwechsel eine Plattform, der Dokumentation, Architekturdiagramme oder Versionshistorie komplett fehlten. Er hatte am Ende der Analyse eine vollständige Kartierung seines Systems und die Kontrolle darüber zurück.

Vorstände und Investoren beauftragen die Analyse oft in einer bestimmten Lage: Sie haben bereits widersprüchliche technische Einschätzungen erhalten und wissen nicht, wem sie vertrauen sollen. Mit der Analyse liefern wir eine neutrale Bewertung, unabhängig von den Interessen einzelner Anbieter, und schaffen damit eine belastbare Ausgangsposition für die nächste Entscheidung.

Teams, die sich auf eine umfassende Migration oder einen Plattformwechsel vorbereiten, tragen ein reales Risiko: Die falsche Reihenfolge oder ein verletztes regulatorisches Detail kann ein mehrjähriges Vorhaben teuer machen. In der optionalen Zielarchitektur legen wir die Migrationsreihenfolge und die Abhängigkeitsordnung fest, ergänzt um einen realistischen Zeitplan; diese Erweiterung berechnen wir gesondert. Der Umfang der Zusammenarbeit wächst dabei nur nach Absprache, nie von selbst.

Schnell wachsende Unternehmen vermuten oft zu Recht, dass ihre Architektur nicht mehr mit dem Wachstum Schritt hält. Ein System, das im Normalbetrieb tadellos läuft und unter Last still versagt, zeigt sein Risiko selten in gewöhnlichen Code-Überprüfungen. Eine Standard-Analyse dauert nur wenige Wochen und bindet dein Team damit spürbar kürzer, als der potenzielle Schaden eines unentdeckten Engpasses kostet.

Befindest du dich in einer anderen Situation, schildere sie: Wir prüfen, ob die Analyse passt oder eine andere Lösung sinnvoller ist.

Fünf Referenzen aus dem Produktivbetrieb

Fünf Einsätze aus unterschiedlichen Branchen zeigen, wie die Analyse in der Praxis wirkt:

• Schweizer Bankentechnologie-Anbieter: Gradion prüfte die Architektur von über 300 Kernbankanwendungen vor einer mehrjährigen Cloud-Migration und definierte eine hybride Roadmap über fünf bis sieben Jahre auf Azure und Google Cloud. Der vollständige Audit samt Roadmap stand nach 8 Wochen, und jede Entscheidung richtete sich nach den Anforderungen der Schweizer Finanzmarktaufsicht FINMA.
• Deutscher B2B-Überschussmarktplatz: Die Architekturprüfung deckte die Engpässe hinter sinkender Bereitstellungshäufigkeit auf, Containerisierung der Dienste und neu strukturierte Auslieferung senkten die API-Latenz um 70 Prozent, die Zusammenarbeit wuchs im Anschluss weiter.
• Europäische Handelsgenossenschaft: Gradion verschaffte sich sechs Monate lang reines Systemverständnis, bevor an der seit Jahren gewachsenen, undokumentierten Plattform die erste Änderung erfolgte. Danach sanken die Datenabweichungen bei Preisen und Beständen um 50 Prozent, und es entstand eine vollständige Systemdokumentation, die zuvor nicht existierte.
• Regionaler Fensterhersteller: Gradion betrieb Reverse Engineering an einer dokumentationslosen E-Commerce-Plattform nach einem Anbieterwechsel und entwickelte Startseite und Bestellprozess neu. Echtzeit-Monitoring kam hinzu, die Besucherzahlen stiegen spürbar, die Konversion verbesserte sich, und die Ausfallzeiten sanken deutlich.
• Weltweit tätiger Frachtträger: Gradion führte einen vollständigen Penetrationstest unter aktiven Bedrohungsbedingungen durch und schloss die Angriffswege für gefälschte Aufträge, unbefugte Zahlungsmarkierung und Sendungsumleitung. Zusätzlich beseitigte Gradion die Ransomware-Angriffsvektoren.