Was ist eine technische Due Diligence?
Eine technische Due Diligence ist die strukturierte Prüfung einer Software, ihrer Architektur und ihres Betriebs vor einer wichtigen Entscheidung, etwa einer Übernahme, Investition oder größeren Modernisierung. Sie soll Chancen, Abhängigkeiten und Risiken sichtbar machen. Bei einem Shop prüft das Team beispielsweise, ob Zahlungsintegration, Datenmodell, Hosting und Support mit den geplanten Anforderungen vereinbar sind.
Prüfbereiche von Code bis Betrieb
Der Umfang richtet sich nach der Entscheidung. Eine Prüfung betrachtet typischerweise:
- Codequalität, Testabdeckung und Sicherheitsstand,
- Architektur, Datenmodell und Integrationen,
- Dokumentation, Build- und Release-Prozesse,
- Infrastrukturkosten, Verträge und Rechte an Komponenten.
Bestehende Quality-Assurance-Prozesse liefern wichtige Belege; ohne Zugriff auf Code und Betrieb bleibt die Bewertung dennoch unvollständig.
Dokumente, Gespräche und Stichproben verbinden
Prüfende sprechen mit Verantwortlichen, lesen technische Unterlagen und untersuchen ausgewählte kritische Pfade. Sie vergleichen Aussagen mit beobachtbaren Belegen, etwa Build-Prozess, Änderungsverlauf, Testläufen und Vorfällen. Eine Stichprobe kann Risiken aufdecken, beweist aber nicht, dass jede Funktion fehlerfrei ist.
Ergebnisse für konkrete Entscheidungen
Ein Bericht trennt bestätigte Befunde von offenen Fragen und ordnet sie nach Wirkung und Aufwand. Er beschreibt, welche Maßnahmen vor einer Entscheidung nötig sind und welche später geplant werden können. Die Migration eines Systems ist nur eine mögliche Folge; oft sind gezielte Verbesserungen oder vertragliche Klärungen sinnvoller.
Eine Stichprobe bleibt eine Stichprobe
Zeit, Zugang und Datenqualität begrenzen die Aussagekraft. Fehlende Unterlagen dürfen nicht stillschweigend als positive Befunde gelten. Eine technische Due Diligence liefert Entscheidungsgrundlagen, keine Garantie für zukünftige Verfügbarkeit, Sicherheit oder Entwicklungsdauer. Ihre Fragen müssen zum Geschäftsmodell und zu den geplanten Änderungen passen.
Befunde nach Wirkung und Dringlichkeit ordnen
Ein Sicherheitsproblem in einem öffentlich erreichbaren Kontoablauf hat eine andere Wirkung als eine unklare Benennung im internen Code. Befunde sollten deshalb mit dem geplanten Geschäftsvorhaben verbunden werden. So bleibt der Bericht eine Entscheidungsgrundlage und wird nicht zur bloßen Sammlung technischer Mängel.
