Ja, Transformative M&A ist ein probates Mittel, die <b bzw. mindestens zu unterstützen. Dies wurde bereits an anderer Stelle diskutiert (vgl. Transformative M&A: Der Fast Track für die Digitale Transformation Ihres Unternehmens?). </b
Geht es nun darum, ein Unternehmen mit einem Digitalen Geschäftsmodell zu akquirieren oder – etwa im Rahmen einer strategischen Kooperation – Anteile daran zu erwerben, dann spielt die Due Diligence der Digitalen Assets offenbar eine besondere Rolle. Denn häufig bildet bei Unternehmen mit Digitalem Geschäftsmodell eben ein Softwareprodukt oder eine selbstentwickelte Kernanwendung den zentralen Vermögenswert. Die IT Due Diligence verdient dann besondere Aufmerksamkeit.
Nachfolgend finden Sie einige zentrale Fragestellung und Prüfpunkte, die im Scope der IT Due Diligence liegen sollten. Gerade beim Erwerb von Softwareprodukten empfiehlt es sich, externe Spezialisten hinzuzuziehen (z.B. Maibornwolff, eine Beratung mit Sitz in Berlin), die bei der Beantwortung zentraler Fragestellung helfen können; dazu mehr unten.
Performance Verhalten von Software Code, Häufigkeit von Bugs
Einige grundsätzliche Fragen lassen sich in der Regel zunächst ohne Spezialisten beantworten: Wie performant ist der Code? Wie viele Fehler (Bugs) berichten die Nutzer täglich/wöchentlich? Wie lange wird benötigt, die Fehler zu beheben (MTTR: Mean-Time-to-Resolution)? Wie intuitiv ist die Bedienung der Software?
Hier bietet sich zunächst der Blick ins Ticketsystem an: Dort lässt sich quantitativ ermessen, wie viele Bugs eingestellt sind, mit welcher Priorität diese versehen sind und welche Durchlaufzeit die Tickets im Schnitt haben. Die Anzahl der Bugs kann man ins Verhältnis zur Anzahl der Nutzer sowie zum Alter der Software setzen (bei „älteren“ Softwareprodukten sollte die Anzahl der Bugs gegen Null tendieren, diese sollten ausgereift sein).
Für die Performance einer Software bieten sich einfache Lasttests an: Große Datenmengen zur Verarbeitung, eine Hohe Anzahl an Nutzeranfragen und derlei mehr. Ein Unternehmen sollte in der Regel solche Lasttests durchführen, ein Blick in solche Testberichte sollte genügen; nur im Zweifel werden dann eigene Lasttests durchgeführt.
Bewertung des Technology Stack, Bewertung der Qualität von Software Code
Der „Blick unter die Motorhaube“ im nächsten Schritt setzt bereits tieferes technisches Verständnis voraus. Vergleichsweise einfach ist es noch, den Technology Stack (also: Die in einem Softwareprodukt bzw. in einer Kernanwendung eingesetzten Programmiersprachen, Frameworks, Bibliotheken) darauf hin abzuprüfen, ob diese zukunftsfähig sind. Ist eine Anwendung etwa in Delphi geschrieben, dann erfüllt die Software eben dieses Kriterium nicht (vgl. auch den Artikel Executive Summary: Die wichtigsten Programmiersprachen, Frameworks).
Geht man nun einen Schritt weiter, dann gerät man gerade bei Softwareprodukten älteren Datums nicht selten in eine Diskussion Microservices versus Monolithische Architektur. Software wird heute zunehmend architektonische für den Betrieb in der Cloud ausgelegt, nämlich als Native Cloud Application (NCA), und diese zeichnet sich aus durch eine Software-Architektur, die auf Microservices basiert. Heißt: Eine Software wird stark modularisiert, es handelt sich je um kleine Dienste, die als eigene Prozesse laufen (mit eigener Datenbank und eigenem Storage) und die miteinander über APIs miteinander kommunizieren. Da diese Microservices unabhängig voneinander sind, können Sie in verteilten Umgebungen laufen, zudem kann jeder Microservice in einer eigenen Programmiersprache geschrieben sein. Microservices können in einer Container-Infrastruktur einfach skaliert werden.
Microservice-Architekturen sind Softwareapplikationen älteren Datums (die nach wie vor den Großteil der laufenden Software ausmachen) fremd. Häufig handelt es sich um eine monolithische Architektur, das heißt, verschiedene Services sind eben nicht miteinander entkoppelt, sondern stark verschachtelt. Das lässt sich nicht zuletzt (mithilfe von Analysetools) ermitteln, Metriken sind hier etwa tangled design oder nesting level.
Softwaredesign ist eher Kunst als Wissenschaft, darum ist monolithisches Design auch keineswegs einfach als „schlecht“ zu bewerten. Es kommt darauf an. Ja, tatsächlich. Erfordert die Produktentwicklung etwa häufige Veränderungen an Softwarekomponenten mit „monolithischer“ Architektur, dann ist das eher kritisch zu bewerten; denn aufgrund des tangled design sind derlei Anpassungen aufwändig. Ist aber eine solche Softwarekomponente ausgereift und gehärtet, dann kann das monolithische Design von Vorteil sein: Diese Codestrecken sind in der Regel hoch performant, es entfallen ja die Schnittstellen zwischen Services in einer NCA.
Geht man nun einen Schritt weiter und möchte die Qualität des Softwarecodes an sich beurteilen, dann ist viel Erfahrung erforderlich. Was sich natürlich einfach prüfen lässt: Wie gut ist die Dokumentation, kann man sich schnell in den Code einarbeiten, lässt sich der Code gut warten, haben wir „Spaghetti“-Code? Werden best practices bei der Benennung von Variablen und Konstanten eingehalten?
Und natürlich lassen sich weitere Regeln abklopfen, ich will nur ein Beispiel geben: Es gibt eine Metrik für die Messung von Softwarequalität, die sich Connascence nennt. Diese Metrik quantifiziert – vereinfacht ausgedrückt – für einen Programmiercode, wie hoch der Aufwand für Anpassungen ausfällt; dieser Aufwand wird nach dieser Metrik besonders hoch eingeschätzt, wenn eine Anpassung an einen Element A (Funktion, Codezeile, etc.) auch gleichzeitig die Anpassung von Element B erfordert. Es dürft klar sein, dass eine solche Analyse mit einem größeren Zeitinvestment verbunden ist.
Prozesse in einem Entwicklerteam und Kopfmonopole
Ich bin im Rahmen von Due Diligence Prozessen immer wieder mit sehr erfahrenen Entwicklern / Entwicklungsschefs unterwegs gewesen; in der Regel reichen drei (3) bis vier (4) Stunden aus, um sich ein Bild davon zu machen, wie der Entwicklungsprozess strukturiert ist, wie Unternehmen Methoden wie Scrum, Kanban oder häufig Scrumban leben, wo die Stärken und Schwächen liegen, und wo etwa Methoden wie Scrum völlig verbogen werden: in Scrum gibt es etwa die Rolle des IT Leiters nicht; gibt es zu wenige Full-Stack-Entwickler, widerspricht dies der Philosophie von Scrum ebenfalls.
Besondere Risikofaktoren liegen in der Qualitätssicherung: Wie hoch ist die Testabdeckung, heißt: Welcher Anteil an Anforderungen werden tatsächlich einem Testing unterzogen? Wie wird dokumentiert, wie gestaltet sich der Freigabeprozess für eine Software bzw. ein neues Feature? Welcher Anteil an Testing wird durch Testautomation abgedeckt (z.B. mit Selenium oder Robot Framework), wie viele automatisierte Testfälle gibt es?
Ein ebenso wichtiger Punkt ist die Identifizierung von Kopfmonopolen? Welche Entwickler / Architekten haben eine zentrale Funktion, lässt sich der Ausfall solcher Entwickler / Architekten kompensieren – und mit welchem Aufwand? Wie lange benötigt ein neuer Mitarbeiter, sich in eine Softwarekomponente einzuarbeiten, bevor er produktiv entwickeln kann? Wie hoch ist der Anteil an Full-Stack-Entwicklern im Team?
Penetration Test, Security
Es ist eine Binsenweisheit: Das Thema Anwendungssicherheit spielt eine wachsende Rolle für Software (vgl. etwa TOP5 Liste der weltweit größten Hacks). Gerade bei webbasierten Anwendungen (und Cloud-Anwendungen) ist hierauf besonderes Augenmerk zu legen.
Es sollte zum Standard gehören, dass Entwickler einer Webanwendung eine externe Firma für Penetrationstests beauftragen; hierzu sollten entsprechende Risikoberichte/-analysen vorgelegt werden und die Maßnahmen, die als Antwort hierauf umgesetzt wurden.
Lizenzen, OpenSource Software
Schließen wir ab mit einigen Überlegungen zu Lizenzen, insbesondere für die richtige Einbindung von OpenSource Software/Bibliotheken, die heutzutage in der Softwareentwicklung unverzichtbar geworden sind.
Grundsätzlich gilt, dass bei Weitergabe von Open Source Software an Dritte mindestens folgende Voraussetzungen einzuhalten sind: (a) Der Dritte wird auf die Verwendung der Open Source Software unter Nennung des Rechteinhabers hingewiesen und (b) die Lizenzbedingungen werden mitgegeben (also: Offenlegungs- und Hinweispflichten). Das lässt sich leicht überprüfen.
Eine spezifische Herausforderung bei der Nutzung von OpenSource Software bzw. genauer: mehrerer OpenSource-Komponenten ist die sogenannte Lizenzkompatibilität. Das heißt: Die Möglichkeit, verschiedene OpenSource-Software-Komponenten unter abweichenden Lizenzbedingungen zu einem neuen Programm zu kombinieren, wobei alle Lizenzbedingungen widerspruchsfrei erfüllt werden. Tatsächlich ist das alles andere als trivial, zur Vertiefung bietet sich folgender Artikel an: Open Source Software: Crash Kurs zum richtigen Umgang mit Compliance Anforderungen
Da sich bei Hundertausenden bzw. Millionen von Lines of Code (LOC) die Verwendung von OpenSource-Software „mit bloßem Auge“ auch kaum sinnvoll überprüfen, lässt werden bei großen M&A-Transaktionen (und bei berechtigtem Zweifel) sogenannte OSS Scanner eingesetzt, etwa OSS Discovery Project (Open Source Tool unter der Affero GNU Public License), Black Duck (ein Pionier im Bereich OSS Scanner, kommerzielles Tool) oder Flexera (vormals: Palamida, kommerzielles Tool). Diese Tools identifizieren nicht nur eingesetzte Open Source, sondern ermitteln auch (mögliche) Lizenzinkompatibilitäten.
Zum Weiterlesen:
