Toolgestützte Software Due Diligence
Vor einem Investment in ein Unternehmen mit eigens entwickelter Software soll eine Due Diligence aufklären über Code-Qualität, Wartungskosten und mögliche Risiken. Statische Code Analysen, wie sie im Markt standardmäßig eingesetzt werden, liefern nur ungenügende Antworten. Bei wdp gehen wir bei der Analyse einen Schritt über den Marktstandard hinaus und liefern so ein deutlich akkurateres Bild.
— Dieser Artikel ist auch auf Englisch verfügbar.
Software-as-a-Service (SaaS) Lösungen und Emerging Technologies erleben als Investitionsziele einen wahren Boom. Die Kursentwicklung von Google und Zoom während einer globalen Pandemie bestätigt das große Interesse von Investoren an softwarebasierten Geschäftsmodellen.
Als wdp konnten wir schon viele Transaktionen mit einer entsprechenden Due Diligence begleiten. Eine Software Due Diligence ist dabei vermehrt Teil einer großen Technology Due Diligence, in welcher wir neben der Software Aspekte wie die IT-Organisation und andere Rahmenparameter genauer analysieren. Die Analyse geht dabei von der Produktperspektive bis in die Details der einzelnen Codezeilen.
Im Folgenden wollen wir auf unsere Erfahrungen aus der Prüfung dieser Assets zurückblicken und darstellen, wie Sie Ihr nächstes Software-Investment mit toolgestützter Software Due Diligence zum Erfolg führen.
Zielstellung
Software-Produkte sind der Kern der Wertschöpfung vieler moderner Unternehmen. Die Entwicklung und Wartung dieser Produkte kosten Ressourcen, die vor einem Investment im Rahmen einer Software Due Diligence abgeschätzt werden müssen. Standardmäßig kommt dabei eine rein statische Code Analyse zum Einsatz. Das bedeutet, der Code wird allein in seinem Ist-Zustand betrachtet. Dies ist ausreichend für eine Bewertung der Code Qualität, liefert aber keine befriedigenden Antworten auf folgende Fragen:
· Wie hoch ist der Wartungsaufwand tatsächlich?
· Wie abhängig ist der Code von bestimmten Entwicklern?
· Müssen Maßnahmen zur Verbesserung der Code Qualität ergriffen werden?
· An welchen Stellen lohnt sich eine Verbesserung der Code Qualität?
Um die obigen Fragestellungen zu beantworten, beziehen wir bei einer Code Analyse historische Daten der Versionsverwaltung mit ein. Eine Versionsverwaltung wie z.B. Git ist eine Software zum Verwalten und Versionieren von Source Code und kommt bei nahezu jedem Software-Projekt zum Einsatz. Dort kann exakt nachverfolgt werden, wer wann genau welche Änderungen am Code gemacht hat. Dies liefert z.B. Aufschluss darüber, an welchen Stellen aktuell gearbeitet wird.
Dieser Artikel diskutiert zur Beantwortung obiger Fragen die Ergebnisse einer umfangreichen toolgestützten Software Due Diligence unter Einbezug historischer Daten der Versionsverwaltung im Vergleich zum Marktstandard der rein statischen Code-Analyse.
Vorgehen und Methode
Der Ablauf einer toolgestützten Analyse der Software-Lösung des Zielunternehmens verläuft in vier Phasen:
· Organisation
· Datenerhebung
· Analyse
· Interpretation
Die Organisation einer toolgestützten Analyse sollte früh im Prozess geplant werden. Der Code ist für Unternehmen ein schützenswertes Gut, und wie bei anderen kritischen Informationen gibt man diese im Rahmen der Due Diligence nur ungern heraus. Wir adressieren diese Sorgen im Rahmen des Projekt Kick-Offs und stecken die Rahmenbedingungen für die Analyse ab.
Die Datenerhebung stellt die Grundlage für die Analyse dar. Auf Basis des Codes und weiteren Informationen der Versionsverwaltung werden mittels spezieller Analyse-Tools Metadaten („Daten über Daten“) erzeugt, die zwar nicht für den Menschen, aber durch entsprechende Tools lesbar sind. Diese reduzieren den Aufwand für das Zielunternehmen auf ein Minimum und belassen den Code bei Bedarf im Unternehmensnetzwerk.
Nach der Datenerhebung führen wir mit denselben Tools die Analyse der erhobenen Daten durch und visualisieren die Ergebnisse. Mit unserer Erfahrung aus mehr als 40 Due Diligence-Prozessen im Software-Umfeld interpretieren wir die Ergebnisse, ordnen diese in den Kontext des Investments ein und schätzen die zu erwartenden Kosten für die Businessplanung.
Ergebnisse
Im Folgenden gehen wir auf die Ergebnisse einer umfangreichen toolgestützten Software Due Diligence ein. Alle diese konkreten Teilergebnisse setzten wir in Kontext, um die oben gestellten Fragen zu beantworten. Wir setzen dabei auf eine Kombination aus statischer Code Analyse, d.h. die Bewertung der aktuellen Code Qualität anhand von diversen Kriterien sowie Verhaltens Code Analyse, d.h. eine Analyse unter Einbezug historischer Daten. Konkret liefern wir im Rahmen einer umfangreichen toolgestützten Software Due Diligence folgende Ergebnisse:
Legacy Code — “Wie hoch ist der Wartungsaufwand tatsächlich?”
Alter Code ist schlecht, richtig? Viele verbinden alten Code automatisch mit Legacy und technischer Schuld. Tatsächlich ist Code, der seit Jahren nicht geändert wurde, der beste Code. Schließlich fordert dieser seit geraumer Zeit keinen Aufwand mehr ein und läuft stabil. Dementsprechend ist neuer Code, der häufig geändert wird, schlecht? Jein. Häufige Änderungen verlangen Aufwand, sorgen aber auch für Effizienz, da die Entwickler den Code kennen und so Anpassungen schneller vornehmen können.
Problematisch ist Code, der nur gelegentlich geändert wird. Liegt die letzte Anpassung mehrere Monate zurück, muss sich der Entwickler an der entsprechenden Stelle wieder neu zurechtfinden. Idealerweise besteht eine Code Basis daher aus einem großen Anteil von altem, stabilem Code, welcher keinerlei Aufwand einfordert, einem mittelgroßen Teil, an dem aktiv entwickelt wird und einem nur kleinen Teil von Code, der gelegentlich gewartet werden muss.
Legacy Code — “Müssen Maßnahmen zur Verbesserung der Code Qualität ergriffen werden?”
Mittlerweile weitläufig bekannt ist, dass schlechte Code Qualität Wartungs- und Entwicklungsaufwände erhöht. Oftmals wird die Qualität der gesamten Code Basis bewertet. Ist das jedoch der richtige Ansatz? Unsere Antwort lautet eindeutig: NEIN.
Code Qualität ist am relevantesten dort, wo viel gearbeitet wird, und nahezu irrelevant an Stellen, die seit Jahren nicht mehr geändert wurden.
Im Rahmen einer Software Due Diligence bewerten wir daher zwei Faktoren. Wie ist aktuell die Code Qualität im Teil des Codes, der regelmäßig geändert wird? Und welcher Trend ist für die gesamte Code Basis bezüglich Qualität zu erkennen? Letzteres liefert uns Aufschluss, ob ggf. bereits Maßnahmen getroffen wurden, oder diese erst noch mit entsprechendem Aufwand getroffen werden müssen.
Wissensverteilung — ”Wie abhängig ist der Code von bestimmten Entwicklern?”
Hier beantworten wir die Frage nach Risiken bezüglich Wissens über die Software. Oftmals gibt es Teile des Source Codes, welche fast ausschließlich von einer Person erschaffen und gewartet werden. Dies birgt das Risiko, diesen Teil der Software nicht oder nur mit erheblichem Aufwand warten zu können, sollte der entsprechende Entwickler längerfristig ausfallen oder gar das Unternehmen verlassen. Möglicherweise haben bereits Schlüsselpersonen das Unternehmen verlassen und Wissen über gewisse Teile der Code Basis muss neu aufgebaut werden. Verstärkt wird dieses Risiko ggf. durch schlechte Code Qualität und mangelnde Dokumentation.
Im Rahmen einer Software Due Diligence identifizieren wir Wissensinseln, bewerten das Risiko unter Einbezug von Funktion, Code Qualität sowie Dokumentation und leiten ggf. Maßnahmen ab, um etwaigen Risiken entgegenzuwirken. Eine Möglichkeit hier wäre zum Beispiel der gezielte Aufbau von Dokumentation.
Hotspots — “An welchen Stellen lohnt sich eine Verbesserung der Code Qualität?”
Code Stellen mit hoher Komplexität, d.h. umfangreichen Funktionen mit vielen logischen Verzweigungen, sind nie gut, da sie bei Änderungen viel Aufwand von den Entwicklern einfordern. Werden an einer Stelle mit hoher Komplexität mit hoher Frequenz Änderungen vorgenommen, sprechen wir von einem Hotspot. Diese Hotspots treiben Aufwände für Wartung und Entwicklung rapide in die Höhe, wenn man sie unbeachtet wachsen lässt.
Im Rahmen einer Software Due Diligence identifizieren wir Hotspots, bewerten die Auswirkungen und leiten Gegenmaßnahmen ab. So können gezielt die Code Qualität an den wichtigsten Stellen verbessert und somit Wartungsaufwände effektiv reduziert werden.
Fazit
Durch die Kombination von statischer Code Analyse mit historischen Daten erhält man akkuratere Einschätzungen zu Wartungsaufwänden, Schlüsselpersonenrisiko und Code Qualität. Damit können Sie den Wert Ihres Investments optimal einschätzen und operative Maßnahmen nach der Akquisition ableiten und sichern so den Erfolg Ihres Investments.
Als Technology Analyst bei wdp beschäftigt sich Sebastian Krammer mit der Bewertung von IT-Organisationen und Software im Rahmen einer Technology Due Diligence, sowie der Umsetzung von getroffenen Empfehlungen im Nachgang an eine erfolgreiche Transaktion. Als Mathematiker liegt sein Augenmerk immer auf datengetriebenen Entscheidungen. Besonderes Interesse besitzt er für künstliche Intelligenz und Kryptographie.
