IT-Projekte & technische Due Diligence
Architekturen entstehen selten in einem einzigen Diagramm. Entscheidungen verteilen sich auf ADRs, Tickets, Pull Requests, Infrastrukturcode, Schnittstellendokumentation und gelebte Implementierung. Für eine technische Rekonstruktion müssen dokumentierte Absicht und tatsächlich realisierter Systemzustand zusammengeführt werden.
Kurzantwort
Untersucht werden nicht nur Architekturzeichnungen, sondern Entscheidungsgrund, technische Alternativen, Qualitätsziele, Abhängigkeiten und der implementierte Zustand. Ein Risiko wird erst dann belastbar beschrieben, wenn Ursache, betroffene Systemteile, Eintrittsbedingungen und technische Auswirkung nachvollziehbar belegt sind.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Architekturabsicht und realen Systemzustand trennen
Architekturdokumente beschreiben häufig einen geplanten oder idealisierten Zustand. Für eine Begutachtung muss deshalb geprüft werden, ob die dargestellten Komponenten, Schnittstellen und Verantwortlichkeiten im untersuchten Build oder Deployment tatsächlich vorhanden sind.
Abweichungen zwischen Diagramm und Implementierung sind nicht automatisch Fehler. Sie können auf Weiterentwicklung, bewusste Vereinfachung oder veraltete Dokumentation zurückgehen. Der Befund besteht zunächst in der Differenz und ihrem zeitlichen Kontext.
2. Entscheidungen mit Gründen und Alternativen rekonstruieren
Ein Architecture Decision Record, Ticket oder Review-Kommentar kann dokumentieren, welches Problem gelöst werden sollte, welche Alternativen betrachtet wurden und welche Konsequenzen akzeptiert wurden. Fehlen solche Unterlagen, können Commit-Historie, Infrastrukturcode oder Schnittstellenänderungen zusätzliche Indizien liefern.
Wichtig ist die zeitliche Reihenfolge. Eine heute erkennbare technische Schwäche darf nicht ohne Weiteres so bewertet werden, als seien spätere Erkenntnisse oder inzwischen verfügbare Technologien bereits zum damaligen Entscheidungszeitpunkt bekannt gewesen.
3. Qualitätsziele den Architekturmerkmalen zuordnen
Skalierbarkeit, Verfügbarkeit, Sicherheit, Änderbarkeit und Beobachtbarkeit stellen unterschiedliche Anforderungen an die Architektur. Ein monolithischer Aufbau ist beispielsweise nicht per se ungeeignet; seine Eignung hängt von Last, Änderungsfrequenz, Teamstruktur und Betriebsmodell ab.
Die Untersuchung verknüpft daher ein behauptetes Qualitätsziel mit konkreten Architekturmerkmalen und Evidenz. Ein Single Point of Failure, eine synchrone Kaskade oder eine unkontrollierte gemeinsame Datenbank können technische Risiken begründen, wenn ihre Auswirkung im konkreten System nachvollziehbar ist.
4. Abhängigkeiten und Schnittstellen als Risikotreiber prüfen
Externe Dienste, Bibliotheken, Datenbanken, Message Broker und Identitätsanbieter bilden oft kritische Abhängigkeiten. Relevant sind Version, Betriebsverantwortung, Ausfallverhalten, Sicherheitsgrenzen und Möglichkeiten zur Isolation oder Wiederherstellung.
Auch organisatorische Grenzen können technisch sichtbar werden: fehlende Ownership, nicht dokumentierte Schnittstellen oder manuelle Deployment-Schritte erhöhen die Unsicherheit. Die technische Bewertung beschreibt diese Zusammenhänge, ohne daraus automatisch eine organisatorische Pflichtverletzung abzuleiten.
5. Risiko nicht mit bloßer Abweichung verwechseln
Ein technisches Risiko umfasst mindestens eine Ursache oder Bedingung und eine mögliche nachteilige Auswirkung. Eine ungewöhnliche Architekturentscheidung ist deshalb nicht allein aufgrund ihrer Abweichung von einer Best Practice ein Risiko.
Für belastbare Aussagen werden Eintrittsbedingungen, betroffene Assets oder Funktionen und vorhandene Gegenmaßnahmen dokumentiert. Wo eine Quantifizierung nicht seriös möglich ist, sollte nicht mit scheinpräzisen Prozentwerten gearbeitet werden.
6. Architekturrekonstruktion revisionsfähig halten
Bei laufenden Projekten verändern Refactorings, Cloud-Migrationen und neue Schnittstellen den Architekturstand. Der Bericht benennt daher den untersuchten Zeitraum und kennzeichnet, welche Aussagen auf dokumentierten historischen Zustand und welche auf aktuelle Beobachtung gestützt sind.
Neue ADRs, geänderte Infrastruktur oder entfernte Abhängigkeiten können einen Revisionsanlass bilden. Frühere technische Risiken werden dann gegen den neuen Stand neu geprüft, statt unverändert fortgeschrieben zu werden.
Bei der Risikoeinordnung ist auch die Kopplung zwischen Komponenten zu betrachten. Gemeinsame Datenmodelle, synchrone Aufrufketten oder geteilte Infrastruktur können lokale Änderungen systemweit wirksam machen. Umgekehrt können klare Schnittstellen, Isolation und automatisierte Wiederherstellung die Auswirkung begrenzen. Solche Eigenschaften sollten anhand konkreter Artefakte und Tests belegt werden.
Für historische Entscheidungen ist außerdem zu prüfen, ob bekannte Einschränkungen bewusst akzeptiert und mit einer späteren Maßnahme versehen wurden. Ein offener Architekturpunkt mit dokumentiertem Migrationsplan ist anders einzuordnen als eine unbeachtete Abhängigkeit. Entscheidend bleibt, was zum untersuchten Zeitpunkt tatsächlich umgesetzt und wirksam war.
Bei priorisierten Risiken kann zusätzlich geprüft werden, ob ihre Auswirkungen in einer kontrollierten Umgebung demonstrierbar sind. Ein Lasttest, Failover-Test oder gezielter Konfigurationsvergleich kann eine abstrakte Risikoannahme in beobachtbare Evidenz überführen. Wo ein solcher Test den Produktivbetrieb gefährden würde, wird stattdessen mit vorhandenen Incident-, Monitoring- oder Staging-Nachweisen gearbeitet.
Ist eine Abweichung von Best Practices bereits ein technischer Mangel?
Nein. Best Practices sind Kontextwissen und keine automatische Soll-Vorgabe.
Entscheidend sind Prüfauftrag, projektspezifische Anforderungen, Qualitätsziele und der tatsächliche Systemkontext.
Eine Abweichung kann ein Prüfhinweis sein; die fachliche Bewertung benötigt jedoch konkrete technische Auswirkungen und Evidenz.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind Architekturabsicht und real implementierter Zustand getrennt dokumentiert?
- Sind wesentliche Architekturentscheidungen zeitlich und mit ihrem Entscheidungsgrund nachvollziehbar?
- Sind relevante Komponenten, Schnittstellen und externe Abhängigkeiten vollständig genug erfasst?
- Sind technische Risiken mit Ursache, Eintrittsbedingung und Auswirkung beschrieben?
- Sind bestehende Gegenmaßnahmen und Resilienzmechanismen berücksichtigt?
- Wurde geprüft, ob das Risiko auch durch eine andere plausible Ursache erklärt werden kann?
- Bezieht sich die Bewertung auf den dokumentierten Projekt- und Systemstand?
Konstruiertes Beispiel
Ein Projekt dokumentiert eine asynchrone Verarbeitung, im Produktivstand ruft jedoch ein zentraler Dienst mehrere externe APIs synchron auf. Die Begutachtung ordnet zunächst die tatsächliche Implementierung und ihre Historie. Anschließend wird geprüft, ob Zeitüberschreitungen oder Ausfälle dieser Abhängigkeiten die behaupteten Verfügbarkeitsziele technisch beeinträchtigen.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Internationaler Standard ISO/IEC/IEEE 42010:2022 beschreibt Anforderungen an Architekturbeschreibungen und deren Konzepte. Quelle öffnen.
- Technischer Sicherheitsrahmen OWASP SAMM strukturiert unter anderem Secure Architecture und Architecture Assessment. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- IT-Projektverlauf rekonstruieren
- Change Requests und Änderungsstände rekonstruieren
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich IT-Projekte & technische Due Diligence
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Projektgutachten