Architekturbewertung
Ein Software-Architektur-Review ist eine strukturierte, zeitlich begrenzte Bewertung Ihres Systems. Wir prüfen an Ihren Qualitätszielen, wo die Architektur trägt, wo sie Risiken birgt und was als Nächstes zu tun ist. Von Olching bei München aus unterstützen wir IT-Leitungen und Geschäftsführungen, die vor einer Investition eine Einschätzung von außen brauchen oder ein IT-Projekt stabilisieren wollen.
Kurz gesagt
Wir führen das Software-Architektur-Review als Paket mit festem Umfang durch: vereinbarte Qualitätsziele wie Änderbarkeit, Verfügbarkeit oder Sicherheit als Maßstab, Interviews, Stichproben in Code und Infrastruktur, eine priorisierte Risikoliste, ein Zielbild und konkrete Migrationsschritte. Es richtet sich an Unternehmen, die vor einer Ausschreibung, einer Cloud-Migration oder einer KI-Integration stehen oder deren Projekt in Schieflage geraten ist.
Für wen
Aus der Praxis unseres Gründers: Als Solution Architect mit iSAQB-Zertifizierung (CPSA, Certified Professional for Software Architecture) verantwortete er bei einem Premium-Automobilhersteller die Architektur eines microservice-basierten Diagnose-Service auf Google Cloud mit über 15.000 Nutzern pro Monat. Er leitete den Shift-to-Cloud des Legacy-Vorgängersystems und führte das internationale 14-köpfige Entwicklungsteam fachlich und technisch.
Die Kennzahlen stammen aus Projekten, die unser Gründer in verantwortlicher Rolle bei Herstellern und Zulieferern umgesetzt hat, nicht im Auftrag von Amperbytes AI.
Leistungen im Detail
Wir beginnen mit der Frage, was Ihr System leisten muss, nicht mit dem Code. Gemeinsam legen wir drei bis fünf Qualitätsziele fest, wie es auch die arc42-Vorlage vorschlägt. Jedes Ziel machen wir mit Szenarien messbar, eine Methode aus der iSAQB-Ausbildung. Ein Beispiel: Kommt ein neuer Partner hinzu, ist seine Schnittstelle im Normalbetrieb innerhalb von zwei Wochen live. Ohne diesen Maßstab wäre jede Bewertung Geschmackssache.
In kurzen, strukturierten Gesprächen erfahren wir, wie das System tatsächlich gebaut, betrieben und genutzt wird. Entwickler kennen die Stellen, die niemand anfassen will, der Betrieb kennt die nächtlichen Störungen, der Fachbereich die Wartezeiten. Widersprüche zwischen diesen Sichten zeigen, wo genauer hingesehen werden muss.
Wir prüfen gezielt, ob die Aussagen aus Dokumentation und Interviews stimmen: Abhängigkeiten zwischen Modulen, Datenzugriffe, Build- und Deployment-Pipelines, Infrastrukturbeschreibung, Logs und Monitoring. Wir lesen nicht jede Zeile, sondern die Stellen, die für Ihre Qualitätsziele entscheidend sind. Der Zugriff ist lesend, Änderungen nehmen wir nicht vor.
Jedes Risiko beschreiben wir mit Beleg, betroffenem Qualitätsziel, möglicher Auswirkung und Empfehlung. Priorisiert wird nach Schaden und Dringlichkeit, nicht nach Anzahl der Befunde. Ebenso wichtig: Wir halten fest, was gut gelöst ist. Das schützt vor dem Reflex, funktionierende Teile beim nächsten Umbau mitzuverändern.
Aus den Risiken leiten wir ein Zielbild ab: wie die Architektur in ein bis zwei Jahren aussehen sollte, damit Ihre Qualitätsziele erreichbar werden. Dazu gehören konkrete Schritte in sinnvoller Reihenfolge, jeweils mit Nutzen, Voraussetzungen und Kostentreibern. So entsteht ein Plan, den Ihr Team oder ein Dienstleister umsetzen kann.
Wichtige Entscheidungen halten wir als Architecture Decision Records fest, kurz ADR: je eine Seite mit Kontext, Optionen, Entscheidung und Konsequenzen. Die Ergebnisse ordnen wir in die Struktur der frei verfügbaren arc42-Vorlage ein, soweit sie für Ihr System sinnvoll ist. Ihr Team kann die Dokumentation danach selbst weiterführen.
Ratgeber
Nicht jedes Problem mit einer Software ist ein Architekturproblem, und nicht jede Prüfung beantwortet dieselbe Frage. Bevor Sie ein Review beauftragen, lohnt ein Blick darauf, was Sie eigentlich wissen wollen.
| Prüfung | Beantwortet | Beantwortet nicht | Sinnvoll, wenn |
|---|---|---|---|
| Automatisierte Code-Analyse | Wo Regeln verletzt werden, wo Code dupliziert oder sehr komplex ist | Ob die Struktur zu den Anforderungen passt | Ihr Team laufend Qualität messen will |
| Code-Review | Ob eine konkrete Änderung korrekt und verständlich ist | Ob das Gesamtsystem die nächsten Jahre trägt | Änderungen in den Hauptzweig einfließen |
| Sicherheitsprüfung, z. B. Penetrationstest | Welche Schwachstellen ein Angreifer ausnutzen kann | Ob das System änderbar und betreibbar bleibt | Sie Angriffsflächen nachweisen oder schließen müssen |
| Architektur-Review | Ob Struktur, Schnittstellen und Betrieb Ihre Qualitätsziele erreichen können, und was als Nächstes zu tun ist | Jede einzelne Codezeile und jede Schwachstelle | Eine größere Entscheidung ansteht: Vergabe, Migration, Neubau, KI-Integration |
Die Prüfungen ergänzen sich. Ein Review nutzt vorhandene Ergebnisse aus Code-Analyse oder Sicherheitsprüfungen als Eingangsmaterial, ersetzt sie aber nicht. Einen Penetrationstest ersetzt ein Architektur-Review nicht. Zeigt das Review, dass einer nötig ist, halten wir das als Empfehlung fest.
Ein Review ohne Maßstab bleibt eine Meinung. „Die Architektur ist veraltet“ ist kein Befund, solange niemand sagt, wofür sie nicht mehr reicht. Deshalb formulieren wir Qualitätsziele als Szenarien mit vier Teilen: Auslöser, Umgebung, erwartete Reaktion und Messgröße. Ein Beispiel für Änderbarkeit: „Der Fachbereich braucht ein neues Feld in der Auftragsübersicht. Im Normalbetrieb ist die Änderung innerhalb von fünf Arbeitstagen in Produktion, ohne dass andere Module angepasst werden müssen.“
Solche Szenarien machen Zielkonflikte sichtbar. Wer maximale Verfügbarkeit, minimale Betriebskosten und schnellste Änderungen gleichzeitig will, muss priorisieren. Szenariobasierte Verfahren wie die Architecture Tradeoff Analysis Method (ATAM) des Software Engineering Institute nennen diese Stellen Tradeoff-Punkte. Das vollständige ATAM sieht mehrtägige Bewertungen mit einem großen Kreis von Beteiligten vor. Wir übernehmen die Idee der Szenarien und der Tradeoffs in schlankerer Form, passend zur Größe mittelständischer Systeme.
Planen Sie direkt nach dem Abschlussworkshop einen Termin, in dem Sie die drei wichtigsten Risiken einer verantwortlichen Person und einem Zeitraum zuordnen. Alles Weitere kommt ins Backlog, mit der Risikoliste als Begründung.
Oft steht am Ende die Frage, ob sich das System schrittweise modernisieren lässt oder ob eine Neuentwicklung ehrlicher ist. Die Optionen und Muster dafür beschreiben wir im Beitrag Software modernisieren oder neu entwickeln. Soll das System danach in die Cloud, begleiten wir das in der Legacy-Modernisierung und Cloud-Migration. Steht eine Neuvergabe an, fließen die Qualitätsziele aus dem Review direkt in das Lastenheft für Ihr Software-Projekt ein, sodass Anbieter gegen denselben Maßstab anbieten. Soll ein Sprachmodell eingebunden werden, hilft der Beitrag zu Build oder Buy bei LLM-Lösungen bei der nächsten Entscheidung.
Die Dokumentation muss danach nicht neu erfunden werden. Die frei verfügbare arc42-Vorlage mit ihren zwölf Abschnitten bietet eigene Kapitel für Qualitätsanforderungen, Architekturentscheidungen sowie Risiken und technische Schulden. Führt Ihr Team diese drei Kapitel weiter, kann das nächste Review auf diesem Stand aufsetzen.
Qualität
Vorgehen
Anlass, Systemgrenzen, Beteiligte und die Fragen, die das Review beantworten soll. Danach steht der Umfang fest. Workshops und Interviews finden nach Absprache bei Ihnen vor Ort in München und Umgebung statt oder per Video.
1 Termin
Vorhandene Dokumentation, Architekturskizzen, Repository- und Pipeline-Zugang lesend, Betriebskennzahlen.
etwa 1 Woche
Workshop zu Qualitätszielen und Szenarien, Einzelgespräche, Analyse von Code, Pipelines und Infrastruktur.
1 bis 3 Wochen
Risiken priorisieren, Zielbild und Migrationsschritte ausarbeiten, Entscheidungen dokumentieren.
etwa 1 Woche
Ergebnisse mit Entscheidern und Team besprechen, offene Punkte klären, Bericht übergeben.
1 Termin
Ihr Nutzen
Technologien und Methoden
Praxisbeispiele
Die Kennzahlen stammen aus Projekten, die unser Gründer in verantwortlicher Rolle bei Herstellern und Zulieferern umgesetzt hat, nicht im Auftrag von Amperbytes AI.
KI · Automotive
LLM-Assistent mit Retrieval (RAG) für einen Diagnose-Service auf Google Cloud, Antwortqualität per KPIs gemessen. Praxisbeispiel unseres Gründers.
Cloud · Automotive
Legacy-Diagnosesystem in eine Microservice-Plattform auf Google Cloud überführt, mit CI/CD, Containern und Terraform. Praxisbeispiel unseres Gründers.
Wissen
Software · 10 Min. Lesezeit
Lastenheft für Software und KI-Projekte: Unterschied zum Pflichtenheft, messbare Anforderungen, Test-Set, Kosten pro Antwort und Gliederung als Vorlage.
KI · 11 Min. Lesezeit
Microsoft 365 Copilot, ChatGPT Business oder eigene KI? Acht Kriterien, Entscheidungsmatrix und der MIT-Befund zu Kaufen und Bauen im Mittelstand.
Software · 9 Min. Lesezeit
Software modernisieren oder neu entwickeln? Die 7R, Lift and Shift vs. Refactoring und das Strangler-Fig-Muster, mit Entscheidungstabelle.
Häufige Fragen
Ein Software-Architektur-Review ist eine zeitlich begrenzte Bewertung, ob die Struktur eines Systems die geforderten Qualitätsziele erfüllen kann, etwa Änderbarkeit, Verfügbarkeit, Sicherheit oder Kosten im Betrieb. Andere Bezeichnungen sind Architekturbewertung oder Architektur-Audit. Anders als ein Code-Review prüft es nicht einzelne Änderungen, sondern ob Struktur, Schnittstellen und Betrieb die Qualitätsziele des Gesamtsystems tragen. Ergebnis sind belegte Risiken mit Prioritäten, ein Zielbild und konkrete nächste Schritte.
Für ein einzelnes System mittlerer Größe rechnen wir mit drei bis sechs Wochen Laufzeit vom Vorgespräch bis zum Abschlussworkshop. Ihr Team ist dabei nur punktuell gebunden, vor allem für Interviews und einen Workshop zu den Qualitätszielen. Größere Systemlandschaften teilen wir in mehrere Reviews mit eigenem Umfang.
Den Aufwand bestimmen vor allem vier Faktoren: die Zahl der Systeme und Schnittstellen im Umfang, Menge und Qualität der vorhandenen Dokumentation, die Zahl der Interviewpartner und die Tiefe der Stichproben in Code und Infrastruktur. Einen festen Umfang vereinbaren wir nach dem Vorgespräch, damit Sie vorher wissen, worauf Sie sich einlassen.
Lesenden Zugang zu Repository, Pipelines und Infrastrukturbeschreibung, die vorhandene Dokumentation in beliebigem Zustand und Termine mit drei bis sechs Personen aus Entwicklung, Betrieb und Fachbereich. Architekturfragen bewerten wir unabhängig von der Programmiersprache. Am tiefsten gehen unsere Code-Stichproben in unserem eigenen Stack, bei anderen Sprachen sagen wir vorab, wie weit sie reichen.
Ja, wenn Sie wissen wollen, woran es liegt. Typische Anzeichen sind wiederholt verschobene Releases, steigende Fehlerzahlen nach jedem Deployment und Schätzungen, denen niemand mehr traut. Ein Review trennt Architekturprobleme von Problemen in Anforderungen, Vorgehen oder Teamaufstellung und benennt die Ursachen, die zuerst angegangen werden sollten. Es stabilisiert das Projekt nicht allein, schafft aber die Grundlage, um gezielt statt hektisch zu handeln.
Ja. Wir prüfen, ob die angebotene Architektur zu Ihren Anforderungen und Qualitätszielen passt, wo Annahmen fehlen und welche Risiken der Anbieter nicht adressiert. Dabei lohnt es sich, auch die Ausschreibung selbst zu prüfen: Sagt sie genug über Qualitätsziele und Schnittstellen, damit Anbieter vergleichbar anbieten können?
Auf Wunsch ja, als Solution Architect oder Technical Product Owner auf Zeit oder in der Umsetzung selbst. Das Review ist aber bewusst so angelegt, dass Sie die Ergebnisse ohne uns nutzen können. Eine Umsetzung mit uns ist keine Bedingung.
Auf die Rolle unseres Gründers als Solution Architect und technischer Leiter eines Diagnose-Service auf Google Cloud bei einem Premium-Automobilhersteller, außerhalb von Amperbytes AI. Dort verantwortete er Zielarchitektur und Architekturentscheidungen und leitete den Shift-to-Cloud des Vorgängersystems. Er ist nach iSAQB als Certified Professional for Software Architecture (CPSA) zertifiziert. Aus einem früheren Projekt als Product Owner einer MES-Plattform bei einem Hausgerätehersteller kommt die Erfahrung mit Schnittstellenkonzeption und ERP-Anbindung. Das Review bündelt diese Arbeit in einem festen Format mit klarem Umfang.
Das iSAQB (International Software Architecture Qualification Board) definiert Lehrpläne und Zertifizierungen für Softwarearchitektur, darunter den Certified Professional for Software Architecture. arc42 ist eine frei verfügbare Vorlage mit zwölf Abschnitten für Architekturdokumentation, von Qualitätsanforderungen bis zu Risiken und technischen Schulden. Beide geben uns eine gemeinsame Sprache und Struktur, schreiben aber kein starres Vorgehen vor.
Direkter Kontakt
Sie sprechen direkt mit unserem Gründer
Gründer und Solution Architect: iSAQB CPSA · Certified ScrumMaster · M.Sc. Wirtschaftsingenieurwesen. Olching bei München, Termine vor Ort nach Absprache.
Passende Leistungen
Externer Solution Architect oder Interim Product Owner für Ihr Softwarevorhaben: Zielarchitektur, Roadmap, Backlog und fachliche Führung des Teams, auf Zeit und mit geplanter Übergabe.
Gewachsene Systeme Schritt für Schritt modernisieren und in die Cloud überführen, während sie weiterlaufen: Zielarchitektur, automatisierte Pipelines, Container und reproduzierbare Umgebungen.
Interne Tools, Web-Anwendungen und Schnittstellen zu ERP und MES, die Ihren Ablauf abbilden. Dokumentiert, getestet und übergabefähig.
Beschreiben Sie uns kurz Ihr System und den Anlass. Wir sagen Ihnen, welcher Umfang sinnvoll ist und ob ein Review überhaupt der richtige erste Schritt ist.