Architektur-Dokumentationen beschreiben die ursprüngliche Absicht. Die Architektur-Analyse setzt bei dem tatsächlich implementierten System an.

Gradion liest den Code, die Infrastrukturkonfiguration und die Monitoring-Daten, bevor wir mit jemandem sprechen. Diese Reihenfolge ist entscheidend. Die Fragen an die Ingenieure sind präziser, wenn der Prüfer das System bereits versteht. Die Ergebnisse basieren auf dem tatsächlichen Verhalten des Systems unter Last, nicht auf Annahmen des Teams. Das Ergebnis ist eine schriftliche Bewertung mit priorisierten Erkenntnissen und Empfehlungen – kein Foliensatz, keine Zusammenfassung von Interviews.

Wo es die Governance zulässt, setzt Gradion KI-gestützte Code-Analyse ein, um den Zeitrahmen der Bewertung zu verkürzen. Statische Analysen, Abhängigkeits-Mappings, Lücken in der Testabdeckung und architektonische Anti-Patterns, deren manuelle Identifizierung Wochen dauern würde, werden innerhalb von Tagen aufgedeckt. Das Ergebnis ist eine schnellere, umfassendere Diagnose – und eine Liste von Erkenntnissen, die den tatsächlichen Code widerspiegelt, anstatt dessen, was das Team über den Code annimmt.

Inhalte der Analyse

Systemtopologie und Datenfluss

Wir erfassen, was tatsächlich existiert – Services, Abhängigkeiten, Datenspeicher, Integrationspunkte, externe APIs – und vergleichen dies mit der vorhandenen Dokumentation. Abweichungen sind dabei selbst schon wichtige Erkenntnisse. Wir verfolgen Datenflüsse durch das System, um zu identifizieren, wo die Kopplung zu eng ist, wo Grenzen unklar sind und wo ein Fehler in einer Komponente unbemerkt auf andere übergreift.

Skalierbarkeit und Lastverhalten

Wir bewerten das Verhalten des Systems unter Last, basierend auf aktuellen Verkehrsdaten, Datenbankabfrage-Mustern und der Infrastrukturkonfiguration. Dazu gehört die Identifizierung von zustandsbehafteten Services, die eine horizontale Skalierung verhindern, fehlenden Caching-Schichten, synchronen Abhängigkeiten, die Latenzketten erzeugen, und Datenbankschemata, die mit zunehmendem Datenvolumen an Leistung verlieren.

Resilienz und Fehlerbilder

Wir analysieren Fehler-Szenarien: Was passiert, wenn eine Abhängigkeit ausfällt, eine Warteschlange überläuft oder eine Bereitstellung fehlschlägt. Wir bewerten Wiederholungslogiken, Circuit Breaker, Fallback-Pfade und die Abdeckung der Observability. Ein System, das im Normalbetrieb einwandfrei funktioniert, aber unter Stress stillschweigend versagt, stellt ein Risiko dar, das in Standard-Code-Reviews selten sichtbar wird.

Wartbarkeit und Betriebskosten

Wir bewerten den Engineering-Aufwand, der in der aktuellen Architektur steckt: wie schwierig es ist, neue Entwickler einzuarbeiten, wie lange Bereitstellungen dauern und wie viel manuelle Intervention Routineoperationen erfordern. Technische Schulden sind reale Kosten – wir quantifizieren sie, wo möglich, und zeigen auf, wo sie sich am schnellsten ansammeln.

Sicherheitsrelevante Angriffsfläche

Wir identifizieren die exponierte Angriffsfläche auf Architekturebene: öffentliche Endpunkte, die nicht öffentlich sein sollten, überprivilegierte Service-Konten, fehlende Verschlüsselung während der Übertragung oder im Ruhezustand, Authentifizierungsflüsse, die zentrale Identitätssysteme umgehen, und Infrastruktur, die Produktionsgeheimnisse an ungeeigneten Stellen speichert.

Was Sie erhalten

Das Ergebnis einer Architektur-Analyse ist eine schriftliche Bewertung, die um Erkenntnisse und Empfehlungen herum strukturiert ist – kein Foliensatz, der Gespräche zusammenfasst. Erkenntnisse werden nach Schweregrad und Kategorie klassifiziert. Empfehlungen werden nach Auswirkungen und Implementierungskomplexität priorisiert, sodass die ersten zehn Punkte auf der Liste den größten Nutzen für den geringsten Aufwand bieten.

Für Kunden, die dies wünschen, erweitern wir die Ergebnisse um eine vorgeschlagene Zielarchitektur mit Migrationssequenz, Abhängigkeitsreihenfolge und einem realistischen Zeitplan. Diese Erweiterung wird separat kalkuliert.

Ablauf des Engagements

Eine Standard-Architektur-Analyse dauert zwei bis drei Wochen. Größere oder komplexere Systeme benötigen mehr Zeit; dies klären wir im Voraus und erweitern den Umfang nur nach Absprache. Die abschließende Sitzung ist eine Arbeitsbesprechung der Ergebnisse mit dem technischen Team – keine Präsentation vor einem Publikum, sondern ein Dialog, in dem das Team Feedback geben, Kontext hinzufügen und bei der Priorisierung helfen kann.

Für wen diese Analyse geeignet ist

Dieses Engagement eignet sich besonders für eine kleine Anzahl von Situationen: neue technische Führungskräfte, die eine ehrliche Bestandsaufnahme benötigen; Vorstände oder Investoren, die widersprüchliche technische Einschätzungen erhalten haben; Teams, die sich auf eine umfassende Migration oder Plattformänderung vorbereiten; oder schnell wachsende Unternehmen, die vermuten, dass ihre Architektur nicht Schritt gehalten hat. Sollten Sie sich in einer anderen Situation befinden, beschreiben Sie uns diese. Wir prüfen dann, ob dieses Engagement passend ist oder ob eine andere Lösung sinnvoller wäre.

Nachweis im Produktivbetrieb

Ein Schweizer Anbieter von Bankentechnologie benötigte eine Architekturprüfung für über 300 Kernbankanwendungen, bevor er sich zu einer mehrjährigen Cloud-Migration verpflichtete. Gradion bewertete die gesamte Anwendungslandschaft, identifizierte die Migrationsreihenfolge und definierte eine hybride Roadmap für fünf bis sieben Jahre über Azure und Google Cloud. Jede Architektur-Entscheidung wurde so konzipiert, dass sie die FINMA-Anforderungen erfüllte. Die Prüfung verschaffte dem Unternehmen eine glaubwürdige Ausgangsposition, anstatt sich auf widersprüchliche Meinungen von Anbietern mit Eigeninteressen verlassen zu müssen.

ein führender B2B-Marktplatzbetreiber, Betreiber des führenden deutschen B2B-Überschussmarktplatzes, hatte über Jahre eine architektonische Komplexität aufgebaut, die jede Bereitstellung zu einem Risiko machte. Ingenieure vermieden es, Kernkomponenten anzufassen; die Bereitstellungsfrequenz war zum Schutz der Stabilität gesunken. Die Architekturprüfung von Gradion identifizierte die spezifischen Engpässe. Daraufhin wurden in einem gezielten Refactoring-Programm die Services containerisiert und der Release-Prozess neu strukturiert. Die API-Latenz sank um 70 Prozent. Die Bereitstellungssicherheit wurde wiederhergestellt. Das Team erweiterte nach dem Engagement den Umfang, anstatt ihn zu reduzieren.

Lassen Sie uns Ihre Systeme analysieren.

Teilen Sie uns eine Systemübersicht und Ihre Informationsbedürfnisse mit. Wir klären den Umfang der Prüfung in einem einzigen Gespräch.