Jemand will ein Unternehmen kaufen, dessen Produkt auf einer zwölf Jahre alten PHP-Anwendung läuft. Ein Investor soll eine weitere Runde finanzieren und fragt, was das technisch bedeutet. Ein Konzern übernimmt einen Wettbewerber und bekommt dessen Plattform dazu. In allen drei Fällen wird dieselbe Frage gestellt: Was genau kaufen wir hier?
Und in allen drei Fällen bekommt der Fragende dieselbe unzureichende Antwort. Ein Entwickler sieht sich zwei Tage lang den Quelltext an und berichtet, dass er nicht schön ist. Das stimmt fast immer und hilft niemandem. Ob der Code schön ist, entscheidet nicht über den Kaufpreis. Darüber entscheidet, was die nächste Änderung kostet und was passiert, wenn morgen die Datenbank stehen bleibt.
Dieser Artikel beschreibt, wie ich ein Altsystem in fünf Tagen prüfe und was am Ende im Bericht steht. Er ist für die Situation geschrieben, in der geplant geprüft wird, mit Zugang und Zeit. Wenn der Entwickler gerade gekündigt hat und Sie nicht wissen, wie das System überhaupt ausgerollt wird, ist die Reihenfolge eine andere; die steht in einem eigenen Artikel.
Drei Fragen, die am Ende beantwortet sein müssen
Eine technische Due Diligence produziert leicht vierzig Seiten, die niemand liest. Damit das nicht passiert, schreibe ich vor dem ersten Zugriff die drei Fragen auf, die der Auftraggeber wirklich hat. Es sind immer dieselben drei.
Erstens: Was kostet der Betrieb, wenn wir nichts ändern? Server, Lizenzen, Dienstleister, und vor allem die Menschen, die das System am Laufen halten. Diese Zahl steht selten vollständig irgendwo, weil sie über drei Kostenstellen verteilt ist.
Zweitens: Was kostet die nächste Änderung? Nicht irgendeine Änderung, sondern die, die im Businessplan steht. Ein neues Preismodell, ein zweiter Mandant, eine Schnittstelle zu einem Partner. Der Preis dieser einen Änderung sagt mehr über das System aus als jede Kennzahl über Codequalität.
Drittens: Was kann uns umbringen? Das sind die Risiken, die nicht graduell sind. Eine Datenbank ohne wiederhergestelltes Backup. Eine Bibliothek mit einer bekannten Lücke und ohne Pfad nach vorn. Eine einzige Person, die das Deployment kennt. Diese Liste ist kurz und sie gehört auf die erste Seite.
Alles, was ich in den fünf Tagen tue, zahlt auf eine dieser drei Fragen ein. Findet sich etwas, das auf keine davon einzahlt, ist es interessant, aber es gehört in einen Anhang.
Warum fünf Tage und nicht zwei Wochen
Fünf Tage klingen nach zu wenig für ein System mit zweihunderttausend Zeilen. Sie sind es nicht, und zwar aus einem Grund, der mit dem System nichts zu tun hat: Der Erkenntnisgewinn pro Tag fällt nach Tag fünf steil ab.
Die ersten Tage bringen die strukturellen Befunde. Ob es eine Pipeline gibt. Ob das Schema Fremdschlüssel hat. Ob die Abhängigkeiten noch gepflegt werden. Das sind Eigenschaften des Systems, und die sieht man schnell, weil sie überall gleich sind. Danach beginnt die Detailarbeit: einzelne Module verstehen, einzelne Fehler nachvollziehen. Die ist wertvoll, aber sie beantwortet keine der drei Fragen besser, sie beantwortet sie nur genauer.
Für eine Kaufentscheidung reicht die Größenordnung. Ob die Modernisierung sechs oder acht Monate dauert, ändert selten den Preis. Ob sie sechs Monate oder drei Jahre dauert, ändert alles. Diesen Unterschied sehen Sie in fünf Tagen.
Was Sie dafür brauchen, klären Sie vorher, sonst gehen zwei der fünf Tage für Zugänge drauf: lesenden Zugriff auf das Repository mit voller Historie, eine Kopie der Produktionsdatenbank oder wenigstens das Schema, Zugriff auf die Betriebsumgebung, und zwei Stunden mit jemandem, der das System kennt.
Tag 1: Lässt sich das System überhaupt herstellen?
Der erste Tag hat genau ein Ziel: Das System läuft auf meinem Rechner, gebaut aus dem, was im Repository liegt. Das klingt banal. Es ist der aussagekräftigste einzelne Befund der ganzen Prüfung.
Gelingt es an einem Tag, ist das System reproduzierbar. Dann gibt es eine Beschreibung der Umgebung, die stimmt, und jemand hat sie in den letzten Monaten benutzt. Gelingt es nicht, ist die wichtigste Zahl des Berichts schon bekannt: Jeder neue Entwickler braucht dieselbe Zeit, bevor er die erste Zeile ändern kann, und jede Änderung wird direkt in Produktion getestet.
Ich beginne mit der Historie, nicht mit dem Code. Sie sagt in fünf Minuten mehr über den Zustand eines Projekts als eine Stunde Lesen:
# Wer hat in den letzten zwei Jahren committet, und wie viel?
git shortlog -sn --since="2 years ago"
# Wann wurde zuletzt etwas ausgeliefert?
git log --first-parent -20 --date=short --pretty="%ad %an %s"
# Welche Dateien werden am häufigsten geändert? Dort sitzt die Arbeit,
# und dort sitzt später das Risiko.
git log --since="2 years ago" --name-only --pretty=format: \
| sort | uniq -c | sort -rn | head -30Die dritte Abfrage ist die, auf die ich am längsten schaue. Sie zeigt die Dateien, die das Geschäft tatsächlich beschäftigen. Wenn dort eine Datei mit viertausend Zeilen steht, die dreihundertmal geändert wurde, haben Sie den Ort gefunden, an dem jede künftige Änderung teuer wird. Das ist kein Urteil über den Entwickler, der sie geschrieben hat. Es ist eine Aussage über Ihre nächsten zwei Jahre.
Danach das Bauen. Was es dafür braucht, steht im besten Fall in einer Datei und im schlechtesten im Kopf von jemandem: PHP-Version, Erweiterungen, Datenbankversion, Suchindex, Nachrichtenwarteschlange, ein Verzeichnis mit Dateien, das nicht im Repository liegt. Jedes Element dieser Liste, das nicht in Code beschrieben ist, ist ein eigener Befund.
Am Ende von Tag 1 steht eine Zahl im Bericht: Zeit bis zur ersten lauffähigen Kopie. Unter vier Stunden ist gut, ein Tag ist normal, mehr als eine Woche ist ein eigenes Kapitel.
Tag 2: Die Datenbank überlebt jede Modernisierung
Der Code eines Altsystems lässt sich ersetzen. Das Schema nicht, jedenfalls nicht in einem Schritt, weil daran alles hängt: Berichte, Schnittstellen, Exporte, eine Handvoll direkter Zugriffe aus anderen Systemen, von denen niemand weiß. Deshalb bekommt die Datenbank einen ganzen Tag.
Drei Dinge interessieren mich. Wie groß ist sie, wie ist sie geschnitten, und wie wird sie geändert.
Die Größe zuerst, weil sie die Migrationsstrategie bestimmt. Eine Datenbank mit acht Gigabyte zieht in einem Wartungsfenster um. Eine mit vierhundert nicht.
-- Größe je Tabelle, größte zuerst. Zeigt auch, wo die Historie liegt.
SELECT table_name,
ROUND((data_length + index_length) / 1024 / 1024) AS mb,
table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length + index_length DESC
LIMIT 20;
-- Tabellen ohne Primärschlüssel. Jede einzelne ist ein Problem bei
-- Replikation, bei Migrationen und beim Nachvollziehen von Änderungen.
SELECT t.table_name
FROM information_schema.tables t
LEFT JOIN information_schema.table_constraints c
ON c.table_schema = t.table_schema
AND c.table_name = t.table_name
AND c.constraint_type = 'PRIMARY KEY'
WHERE t.table_schema = DATABASE() AND c.constraint_name IS NULL;Dann der Schnitt. Gibt es Fremdschlüssel? Wenn nicht, liegt die referenzielle Integrität in der Anwendung, und das heißt in der Praxis: Sie liegt an den Stellen, an denen jemand daran gedacht hat. Für die Prüfung ist das eine der teureren Entdeckungen, weil sie jede Datenmigration aufwendiger macht. Man kann dann nicht mehr darauf vertrauen, dass die Daten zusammenpassen, man muss es messen.
Und schließlich: Wie kommen Änderungen ins Schema? Es gibt drei Antworten, und sie unterscheiden sich stark. Ein Migrationswerkzeug mit versionierten Schritten im Repository ist der gute Fall. Ein Verzeichnis mit durchnummerierten SQL-Dateien ist der normale Fall. „Der Kollege macht das abends von Hand" ist der Fall, der in die Risikoliste gehört, weil dann kein Mensch weiß, ob Test und Produktion dasselbe Schema haben. Prüfen lässt sich das in zehn Minuten, indem man beide Schemata exportiert und vergleicht:
mysqldump --no-data --skip-comments produktion > /tmp/prod.sql
mysqldump --no-data --skip-comments test > /tmp/test.sql
diff /tmp/prod.sql /tmp/test.sqlIch habe diesen Vergleich noch nie ohne Ausgabe erlebt. Interessant ist nicht, ob es Unterschiede gibt, sondern wie viele und ob jemand sie erklären kann.
Tag 3: Abhängigkeiten und ihre Ablaufdaten
Am dritten Tag geht es um die Frage, wie lange das System in seiner jetzigen Form überhaupt betrieben werden darf. Das ist die Frage nach dem End of Life, und sie hat einen Termin, der nicht verhandelbar ist.
Die Bestandsaufnahme selbst ist schnell:
php -v # Läuft die Version noch im Sicherheitssupport?
composer show --direct # Die Pakete, die das Projekt selbst gewählt hat
composer audit # Bekannte Lücken in allem, was installiert ist
composer outdated --direct # Wie weit ist der Abstand zur gepflegten Version?Interessant wird es bei der Auswertung, und dort gibt es drei Kategorien, die sich sehr unterschiedlich anfühlen und sehr unterschiedlich kosten.
- Veraltet, aber gepflegt. Das Paket hängt zwei Hauptversionen zurück, wird aber weiterentwickelt und hat eine Upgrade-Anleitung. Das ist Arbeit, planbar und mit bekanntem Ende.
- Aufgegeben, mit Nachfolger. Das Paket wird nicht mehr gepflegt, aber jemand hat es übernommen oder es gibt einen anerkannten Ersatz. Teurer, weil Schnittstellen abweichen, aber der Weg ist klar. Zend Framework 1 ist der bekannteste Fall dieser Art.
- Aufgegeben, ohne Nachfolger. Ein Paket von 2014, das genau eine Sache tut, die das System braucht, das niemand mehr pflegt und zu dem es keinen Ersatz gibt. Das wird Eigenbau, und das gehört mit einer Schätzung in den Bericht.
Zu jedem Fund in der dritten Kategorie notiere ich, wie tief er sitzt. Ein aufgegebenes Paket, das an drei Stellen aufgerufen wird, ist eine Woche Arbeit. Dasselbe Paket, dessen Klassen in zweihundert Dateien importiert werden, ist ein Quartal. Das sehen Sie mit einer einzigen Suche, und diese Zahl ist im Bericht mehr wert als der Name des Pakets:
grep -rl "Alter\Namensraum" src/ | wc -lTag 4: Was weiß niemand mehr?
Der vierte Tag ist der unangenehmste, weil er nicht technisch ist. Es geht um die Frage, wie viel Wissen über das System außerhalb von Köpfen existiert, und die Antwort entscheidet darüber, was eine Übernahme kostet.
Zwei Messungen und ein Gespräch.
Die erste Messung ist die Testabdeckung, und sie wird fast immer falsch gelesen. Vierzig Prozent Testabdeckung klingen nach der Hälfte von achtzig. So funktioniert das nicht. Entscheidend ist, ob die Stellen abgedeckt sind, an denen das Geschäft stattfindet. Deshalb vergleiche ich die Abdeckung mit der Liste der am häufigsten geänderten Dateien von Tag 1. Wenn die zwanzig meistgeänderten Dateien null Tests haben, ist die Gesamtzahl bedeutungslos, egal wie hoch sie ist.
Die zweite Messung ist der Bus-Faktor, und der lässt sich aus der Historie ablesen. Für jeden wesentlichen Bereich des Systems: Wie viele Menschen haben dort in den letzten zwei Jahren etwas geändert, und sind sie noch da? Ein Bereich mit genau einem aktiven Autor ist kein Personalproblem, sondern ein Preisbestandteil.
Das Gespräch dauert zwei Stunden und hat drei Fragen. Was würden Sie als Erstes ändern, wenn Sie Zeit hätten? Welche Stelle im System macht Ihnen Sorgen? Was müsste ich wissen, das ich nicht gefragt habe? Die dritte Frage bringt die Antworten, wegen derer sich der Termin gelohnt hat, und sie funktioniert nur, wenn vorher klar ist, dass es hier nicht um eine Bewertung von Personen geht.
Was Sie an diesem Tag nicht tun sollten: die Dokumentation als Beleg nehmen. Ein Wiki mit zweihundert Seiten sagt nichts darüber, ob dort etwas Aktuelles steht. Ein Stichprobenverfahren hilft: drei Seiten aufschlagen, die beschriebenen Schritte nachvollziehen, zählen, wie viele noch stimmen.
Tag 5: Betrieb, Zugänge, Rückweg
Am letzten Tag geht es um die Fragen, die erst wehtun, wenn etwas passiert ist. Sie sind der Teil der Prüfung, der am häufigsten übersprungen wird, und der einzige, der Risiken findet, die ein Unternehmen wirklich treffen können.
Drei davon sind nicht verhandelbar.
Das Backup ist erst ein Backup, wenn es einmal zurückgespielt wurde. Ich frage nicht, ob es Sicherungen gibt, sondern wann zuletzt eine wiederhergestellt wurde und wie lange das gedauert hat. Gibt es darauf keine Antwort mit Datum, steht im Bericht: Wiederherstellung ungeprüft. Das ist kein Formfehler. Eine Sicherung, die niemand zurückgespielt hat, ist eine Vermutung, und ich habe Sicherungen gesehen, die seit Monaten eine leere Datei schrieben, ohne dass jemand etwas gemerkt hat.
Wer kommt an die Produktion? Nicht wer sollte, sondern wer kann. Die Liste ist regelmäßig länger als erwartet und enthält ehemalige Dienstleister, gemeinsam genutzte Zugänge und einen Schlüssel auf einem Rechner, den es nicht mehr gibt. Für eine Übernahme ist das eine der ersten Aufräumarbeiten und gehört mit Aufwand in den Bericht.
Was passiert, wenn das Deployment schiefgeht? Gibt es einen Weg zurück, und ist er schon einmal gegangen worden? Ein System ohne Rückweg zwingt jede Änderung in ein Wartungsfenster, und das begrenzt, wie schnell sich nach der Übernahme überhaupt etwas ändern lässt. In einem Fall, den ich begleitet habe, war genau das der Grund, warum die Modernisierung überhaupt möglich war: eine Redaktionsplattform mit zwanzig Jahren Geschichte ließ sich ohne einen einzigen Ausfalltag umbauen, weil jeder Schritt einzeln ausrollbar und einzeln zurückdrehbar war.
Dazu kommen die Kosten. Server, Dienste, Lizenzen, externe Dienstleister. Bei Systemen in der Cloud lohnt hier ein genauer Blick, weil ein erheblicher Teil der Rechnung oft nicht aus der Last kommt, sondern aus der Architektur; wo dieses Geld typischerweise liegt, habe ich an anderer Stelle aufgeschrieben.
Was in diesen fünf Tagen an Zahlen entsteht, ist noch keine Messreihe. Welche drei Kennzahlen danach dauerhaft mitlaufen sollten, steht in Drei Kennzahlen, bevor Sie eine Zeile refaktorieren.
Was im Bericht steht
Der Bericht hat vier Teile und passt auf zehn Seiten. Längere Berichte werden nicht gelesen, und was nicht gelesen wird, ändert keine Entscheidung.
Eine Seite Befund. Die drei Fragen vom Anfang, beantwortet, mit Zahlen. Keine Einleitung, keine Methodenbeschreibung.
Die Risikoliste. Jedes Risiko mit drei Angaben: was passieren kann, wie wahrscheinlich es ist, was es kostet, es zu beseitigen. Sortiert nach dem Produkt aus den letzten beiden, nicht nach technischer Schwere. Eine ungeprüfte Wiederherstellung steht über einer veralteten Bibliothek, auch wenn die Bibliothek in jedem Scanner rot leuchtet.
Der Preis der nächsten Änderung. Das Vorhaben aus dem Businessplan, durchgerechnet an diesem System. Hier zahlt sich Tag 1 aus: Wenn die betroffenen Dateien zu den meistgeänderten gehören und keine Tests haben, ist die Schätzung eine andere, als wenn sie in einem ruhigen Bereich liegen.
Was ich empfehlen würde, in Reihenfolge. Drei bis fünf Punkte für die ersten sechs Monate. Der erste Punkt ist in vielen Fällen kein Umbau, sondern eine Pipeline oder ein geprüftes Backup, weil ohne die beiden jeder weitere Schritt riskanter ist als nötig.
Was nicht in den Bericht gehört, ist eine Note. „Codequalität: befriedigend" ist keine Aussage, aus der jemand eine Entscheidung ableiten kann, und sie verdeckt, dass ein Teil des Systems sehr gut und ein anderer sehr schlecht sein kann.
Wer aus dem Befund eine Hausnummer machen muss, findet die fünf Größen, die den Preis treiben, in Was eine Modernisierung kostet.
Drei Dinge, die eine Due Diligence nicht leistet
Damit der Bericht nicht mehr verspricht, als er kann, sage ich vorher, was er nicht enthält.
Er findet keine Sicherheitslücken. Fünf Tage Prüfung sind kein Penetrationstest. Was auffällt, wird notiert, aber die Abwesenheit von Funden ist kein Beleg für Sicherheit.
Er sagt nicht, ob das System die Geschäftslogik richtig abbildet. Ob die Provisionsberechnung stimmt, weiß der Fachbereich, nicht der Prüfer. Ich kann sagen, ob sie testbar ist und ob jemand sie erklären kann.
Er ersetzt die erste Änderung nicht. Die ehrlichste Schätzung entsteht, wenn jemand eine kleine, echte Änderung an dem System vornimmt und misst, wie lange das gedauert hat. Wo das möglich ist, empfehle ich es: eine Woche Prüfung plus eine echte Änderung schlägt zwei Wochen Prüfung.
Wenn Sie aus diesem Artikel eine Sache mitnehmen, dann die Reihenfolge. Erst die drei Fragen aufschreiben, dann prüfen. Eine Prüfung, die mit dem Quelltext beginnt, endet mit einem Urteil über Quelltext, und das war nie die Frage. Und wenn am Ende die Übernahme ansteht: wie eine geordnete Projektübernahme abläuft, steht auf einer eigenen Seite.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
