Nachdem ein erster Versuch „Big-Bang“ krachend gescheitert ist, übernimmt ein kundiger CTO und stimmt Team und Organisation auf ein mittelfristiges „change-but-keep-treasures“ ein.
Die zugrunde liegende Strategie lautet split + extract: Das gesamte e-Commerce System wird hinsichtlich Kundensegmenten aufgespalten (split) - und einige querschnittlich benötigte Features werden herausgezogen (extract).
Damit gewinnen wir eine Menge Unabhängigkeit und Flexibilität - und können uns dem Abbau einiger technischer Schulden widmen, beispielsweise dem inkrementellen Update uralter Technologien oder der Abkehr von Not-invented-here.
Schlangengift?
Der englische Begriff VENOM bedeutet „Schlangengift“ und ist gleichzeitig der Titel eines Actionfilms von 2019 – für uns steht er aber als Kurzform von „very normal system“: Aus diversen realen Erlebnissen und Systemen meiner beruflichen Praxis habe ich Sachverhalte gesammelt, und in dieser VENOM-Story verarbeitet. Ähnlichkeiten mit realen Systemen sind daher möglich und erwünscht – jedoch keinerlei Rückschluss auf konkrete Unternehmen oder Personen. Alle geschilderten Sachverhalte sind mir wirklich begegnet – jedoch auf unterschiedliche Systeme und Organisationen verteilt und weniger komprimiert.
Das (fiktive) Unternehmen SAMM Inc. ist ein international operierendes Handelsunternehmen mit Verwaltungssitz in Durango, Colorado (USA) und Firmenzentrale in Berlin. SAMM Inc. bündelt die Kompetenzen von über 500 Spezialisten, welche die gesamte vertriebliche und technische Bandbreite abdecken. Der Name ist Programm und steht für „sell and make money“ – dem grundliegenden Credo von eCommerce Unternehmen. Die SAMM Inc. blickt auf eine langjährige und bewegte Geschichte zurück, geprägt durch Übernahmen und Fusionen in dynamischen Unternehmensmärkten. Abbildung 1 gibt einen Überblick. Diese Historie ist insofern wichtig, als dass sie sich in der Komponentenstruktur unseres VENOM-Systems in ähnlicher Form wiederfindet – aber dazu später mehr.
SAMM handelt über das VENOM-System mit Waren, aber auf spezielle Weise und in speziellen Märkten. Der Fokus liegt auf so genannten „komplexen Produkten“, also Dinge die beispielsweise umfangreiche Konfiguration, Installation, Inbetriebnahme oder Logistik erfordern. VENOM ist das zentrale IT-System für SAMM, das sowohl die Beschaffung und Produktion von Artikeln steuert, als auch den Verkauf (neudeutsch: online-Shop), die Logistik, Abrechnung und so weiter.
Schauen wir auf ein paar Beispiele, was Kunden über VENOM kaufen können:
Kundensegmente
Historisch stark ist VENOM im Bereich von Privatkunden, beispielsweise in der Konfiguration spezieller Kleinmöbel (spezielle Regalsysteme, Schränke mit Sondermaßen und -ausstattung. So können sich Privatkunden beispielsweise Schuhschränke in nahezu beliebigen Dimensionen (etwa: Über-Eck, gerundet) in vielerlei Materialien, mit belüfteten Türen) zusammenstellen. Die verwendeten Materialien, Hölzer, Beschichtungen, Sonderausstattungen stammen von verschiedenen Herstellern, Beschaffung und Produktion wird über VENOM koordiniert. Kunden erhalten einen all-inclusive Service und bekommen ihr Spezialmöbel nach Hause geliefert und benutzungsfertig aufgebaut. Auch die Koordination eventuell benötigter Handwerker übernimmt VENOM.
Ein zweites Kundensegment sind Botschaften und diplomatische Vertretungen (in Abbildung 2: Government Users), verantwortlich für ca. 25% des gesamten Umsatzes. Hier bietet VENOM unter anderem komplette Planung, Beschaffung, Aufbau von Gartenanlagen. Interessant hierbei ist die aufwändige Logistik, weil Teile der Materialen (empfindliche Mikrofone, Störsender, Peilgeräte) nicht mit normalem Versand in die ausländischen Vertretungen geschickt werden, sondern VENOM dafür geeignete Kuriere und spezielle Zollformalitäten nutzt.
Eine dritte Kundengruppe, die Non-Profit-Organizations (NPO) und Non-Government-Organizations (NGO) machen zwar nur 5% des Umsatzes aus, sind aber für SAMM Inc. wichtig für’s Karma :-). NGOs stellen teilweise höchste Anforderungen an Transportlogistik, wenn sie beispielsweise nach Naturkatastrophen größere Mengen an Zelten, Decken und medizinischen Gütern buchstäblich sofort ans Ende der Welt geliefert haben müssen. VENOM stützt sich dabei auf langjährige Logistik- und Zoll-Erfahrung.
Gute 45% des Umsatzes erwirtschaftet VENOM mit Firmenkunden (Corporate Users), beispielsweise Planung, Aufbau und Inbetriebnahme komplexer Kommissionierautomaten für Apotheken. Hier verfügt VENOM über ausgefeilte Planungs- und Konfigurationsmechanismen, bei denen die Pharmazeuten lediglich die Grundrisse ihrer Apotheken hochladen, und VENOM mit einer Mischung aus (einfacher) KI und menschlicher Expertise schnell und günstig Vorschläge für passende Automaten erstellen kann.
Niedergang
Über viele Jahre hat VENOM grundsätzlich gut funktioniert, und der SAMM Inc. ordentliche Erträge beschert. Aufgrund der bewegten Unternehmenshistorie mussten in VENOM allerdings ständig andere (zugekaufte) IT-Systeme in unterschiedlichen Technologien integriert werden – und wie (branchen-)üblich immer unter massivem Zeitdruck. Das hat auf Dauer zu einigen gravierenden Problemen geführt – eines davon in Abbildung 3 ersichtlich: Die Time-to-Market hat massiv gelitten: Neue Features und Bug-Fixes brauchten mittlerweile ewig lange, bis sie im produktiven System umgesetzt waren (in Abbildung 3 die grüne Kurve). Dafür wurde das System (rote Kurve) immer instabiler, die kritischen Fehler zur Laufzeit nahmen immer mehr zu.
Hinzu kamen immense technische Schulden, starker Umsatzrückgang in maßgeblichen Kundensegmenten, fehlende Unterstützung für mobiles Internet (weil die aufwändigen Konfiguratoren von VENOM sämtlich auf der veralteten ActionScript/Flash Technologie basieren). Ein externes Review von VENOM brachte weitere kritische Defizite ans Licht, beispielsweise:
- Zu geringe Standardisierung in Prozessen und Produkten, etwa im Bereich IT-Governance und IT-Betrieb.
- Kaum Automatisierung in Build, Test und Deployment des Systems
- Zu große Technologievielfalt (im Review war von „Wildwuchs“ die Rede)
- Zu hoher Anteil an Eigenentwicklung bei Standard IT-Aufgaben, etwa Persistenz, Logging, Reporting, UI.
Big-Bang-Fail
Der erste Versuch von SAMM Inc., die Situation zu retten war ein so genannter Big-Bang. In Anlehnung an die von der Gartner-Group eine Zeitlang propagierte „IT der zwei Geschwindigkeiten“ (bimodale IT) hatte SAMM dazu in Berlin ein Startup gegründet, das auf der grünen Wiese das gesamte VENOM System neu bauen und betreiben sollte.
Das verantwortliche Management hatte dabei jedoch in diversen Dimensionen versagt, unter anderem bei der Personalakquise, der Anforderungsklärung und der Einführung moderner Entwicklungs- und Betriebsprozesse. Die genaue Analyse dieses gescheiterten Versuches wäre ein spannendes Thema für einen eigenen Artikel – insofern möchte ich hier lediglich die (alte) Warnung von Joel Spolsky zitieren: Never rewrite.
Nach fast 12 Monate Irrfahrt durch die Startup-Szene, einem abstrus hohen Anteil extern vergebener Entwicklungsaufgaben (für ein Startup viel zu teuer und wegen Know-How Abwanderung zu riskant) und immens hoher Fluktuation (ein Zeichen fehlender Startup-Kultur) hatte damals der Aufsichtsrat der SAMM Inc. beschlossen, die Strategie „bimodale IT“ zugunsten einer inkrementellen Inhouse-Modernisierung zu beenden.
Fun Fact: Das beteiligte Management verließ mit besten Zeugnissen das Unternehmen, nur um kurze Zeit später als externe Berater für bimodale IT von anderen Firmen angeheuert zu werden.
Systematische Analyse
Der Aufsichtsrat von SAMM hat zur Modernisierung respektive Rettung von VENOM kurz darauf einen (neuen) IT-Manager eingesetzt, nennen wir ihn hier mal Aaron. Dessen erste Amtshandlung war eine systematische Analyse der gesamten Situation in SAMM und VENOM, die er gemeinsam mit Vertreter*innen von Entwicklungsteams, der Fach- und Betreiberseite sowie zwei Externen durchgeführt hat. Dabei folgte Aaron in weiten Teilen der Open-Source Methodik „aim42“ (architecture improvement method), die in solchen Fällen eine Breitensuche empfiehlt (eine kompakte Zusammenfassung finden hier).
Details dieses systematischen Reviews spare ich hier aus Platzgründen, möchte allerdings festhalten, die Ursache vieler Probleme bei und mit VENOM in miserablen und überkommenen Prozessen statt in Source-Code liegen. Daher war Aarons zweite Amtshandlung nach dem Review, eine dedizierte Person (nennen wir Sie hier Beatrice) zur Veränderung der allzu starren Anforderungs-, Entwicklungs-, Test- und Release-Prozesse bei SAMM zu installieren. Architektur und Organisationsstruktur hängen untrennbar miteinander zusammen – was wir unter der Bezeichnung Conways Law ja kennen, aber in der realen Welt doch zu häufig ignorieren.
Prozesse und Technik
Beatrice geht das Thema Process Change behutsam und unter Einbezug sämtlicher Beteiligten an. Ihre Strategie zielt auf den Abbau von Silo-Denken, der Einführung agiler und iterativ-inkrementeller Vorgehensweisen in Fachbereichen, Entwicklung und IT-Betrieb sowie der starken Vernetzung von Entwicklung und Betrieb. Solches Change-Management benötigt neben Empathie, Fingerspitzengefühl, Erfahrung und Kommunikationsfähigkeit auch Durchsetzungsstärke. Technisch fokussierte Entwicklungsteams allein können das nicht leisten – daher halte ich eine Doppel-Besetzung wie Aaron und Beatrice für einen wichtigen Erfolgsfaktor in gesamthaften Verbesserungsprojekten. Viele der über lange Zeit gewachsenen Probleme von Legacy-Systemen können wir nicht rein technisch (d.h. über bessere Programmierung und Refactoring) lösen, sondern müssen parallel dazu auch die betroffenen Prozesse angehen.
Architektur und Technik von VENOM
VENOM besteht aus mehr als 2 Millionen Zeilen Code in mehr als 8 verschiedenen Sprachen, die grundsätzlich zeitgleich deployed werden müssen, obwohl sie auf unterschiedlichen Betriebsplattformen (Host, Linux-Server, Desktop-PC) betrieben werden. Die gesamte Struktur ist historisch so gewachsen – in Abbildung 4 sehen Sie den stark vereinfachten „Stammbaum“ von VENOM. Dessen Geschichte beginnt mit einem Cobol-System im Jahre 1992, und ist seither durch ein paar Dutzend Integrationen geprägt, die meist unter Zeitdruck erfolgten. Die Farben repräsentieren verschiedene Technologien, die sich (ungeplant…) in das Gesamtsystem geschmuggelt haben.
Die Baustein- oder Komponentensicht von VENOM schaut noch viel schlimmer aus, als die Historie das befürchten lässt: Eine wüste Gemengelage von Komponenten, miserable Kohäsion, bunt gemischte Technologien, Verwendung nicht mehr unterstützter Frameworks, Eigenimplementierung rein technischer Komponenten (z.B. eine selbst geschriebene Version von Apache mod_proxy, weil ein hochnäsiger Entwickler vor langer Zeit mal geglaubt hatte, er könne das besser als die Apache-Foundation). Abbildung 5 zeigt diesen Horror in Farbe.
Als wäre das nicht schon schlimm genug: Die VENOM-UI basiert auf Flash – allerdings werden große Teile der grafischen Oberfläche nicht von kundigen Entwicklungsteams programmiert, sondern über einen selbstdefinierten XML-Dialekt konfiguriert und über einen (Prolog- und Jboss-Drools basierten) selbst geschriebenen Generator generiert.
Über die chaotische Datenhaltung möchte ich hier gar nicht weiterschreiben – erhebliche Teile der notwendigen Stamm- und Bewegungsdaten sowie der Anwendungszustand liegen in einem Konstrukt aus 5 Oracle-Tabellen mit jeweils über 400 Spalten. Sie haben richtig gelesen. 400 Spalten pro Tabelle einer Oracle-DB, massiv mit den anderen Tabellen vernetzt, und natürlich keine sprechenden Bezeichner. Dann gibt es noch ein teilweise korruptes optisches Archiv, eine XML-DB und ein paar weitere Datensenken und -quellen – aus denen VENOM zur Laufzeit wichtige Konfigurations-, Produkt- und Logistik-Daten lesen muss. Liest sich schlimm, ist schlimm. Aber: Das Entwicklungsteam, ca. 50 Personen, hat das seit Jahren gepflegt und VENOM trotz dieser Zustände „am Leben“ erhalten.
Kontinuierliche Verbesserung
Auf Basis der systematischen Breitensuche schlägt Aaron eine inkrementelle Strategie zur Modernisierung von VENOM vor. Verbesserung wird dabei mit Tagesgeschäft parallel bearbeitet, so dass Fachbereiche kontinuierlich neue Features oder Bugfixes bekommen, aber begleitend immer Verbesserungsmaßnahmen laufen. In Abbildung 6 erkennen Sie, dass der Umfang von Tagesgeschäft und Verbesserungsmaßnahmen sich zwischen Iterationen unterscheiden kann. Jede Iteration sollte aus beiden Bereichen Aufgaben enthalten.
Ein vordringliches strukturelles Problem liegt in der schlechten Kohäsion und Modularisierung des gesamten Systems: VENOM erledigt schlicht zu viele Aufgaben – fachliche und technische Aspekte sind willkürlich gemischt.
Schlechte Modularisierung führt bei VENOM zu massiven fachlichen Abhängigkeiten: Wird beispielsweise für die NGO-Kunden ein Feature-Update notwendig (Sie erinnern sich, für die NGO Kunden muss VENOM schwierige logistische Herausforderung meistern), so ist dessen Inbetriebnahme von vielen anderen Komponenten und Teams abhängig und musste (bisher) in den meisten Fällen auf die Fertigstellung anderer Dinge warten.
Kleiner ist feiner
Als Abhilfe wählte Aaron zuerst eine Extraktions-Strategie: Funktionen, die wenig inhaltlichen Zusammenhang mit dem Rest des Systems haben, werden herausgelöst (extracted). Das führt von einem einzigen großen Monolithen hin zu mehreren kleineren Systemen. Dazu sucht Aaron eine Gruppe von 3–4 Personen aus verschiedenen Bereichen der VENOM Entwicklung, die sich auf die Suche nach solchen Features/Teilen begeben. Ein Kandidat bei VENOM waren diverse Funktionen zur PDF-Erzeugung und -Bearbeitung. Statt diese Funktionen an mehreren Stellen über den VENOM Source zu verstreuen, konnte das Team daraus eine eigenständige Komponente schaffen. In erster Näherung ist es dabei sogar egal, ob wir diese neue Komponente als Framework oder Library verwenden, oder sie als (Micro-)Service oder SCS eigenständig deployen und betreiben. Auf diese Weise hat das Extraction-Team fast ein Dutzend Komponenten extrahieren können, und den VENOM Sourcecode dabei um geschätzt 100.000 Zeilen Sourcecode bereinigen können.
Wenn Sie jetzt einwenden, dass SAMM sich diese Verkleinerung durch möglicherweise erhöhte Komplexität im Betrieb erkauft hat, dann haben Sie völlig Recht. Jede Veränderung birgt Risiken und geht Kompromisse ein. Aus der Sicht der VENOM Entwicklung hat die Extraktion diverser Funktionen jedoch zu signifikant besserer Modularisierung geführt, und diverse Funktions-Updates der extrahierten Bestandteile gingen erheblich schneller (time-to-market), als dies früher der Fall war.
Extraktion gehört zur Gruppe der brainsizing Ansätze: Kleinere Systeme, d.h. weniger Code, sind meistens besser verständlich und leichter zu ändern – einer der Gründe für die hohe Akzeptanz von Microservices und self-contained Systems. In VENOM konnte das Team das brainsizing jedoch noch deutlich weiterführen:
Noch kleiner: Split
Wenn wir die fachlichen Funktionen von VENOM betrachten, dann fällt auf, dass die Kundensegmente und damit verbunden die jeweiligen Produkte/Produktgruppen völlig disjunkt sind: NGO’s kaufen komplett andere Dinge und haben andere Anforderungen an Transport/Logistik/Lieferzeiten, als das Privatkunden oder Apotheken haben.
Diese Beobachtung führten zu einer Split-Strategie für VENOM (siehe Abbildung 7): In der Ausgangssituation (1) verwenden alle Nutzergruppen den VENOM Monolithen. In Schritt (2) wird eine vollständige Kopie des gesamten Systems erzeugt, nennen wir die der Einfachheit halber mal VENOM-NGO und VENOM-REST. Ab jetzt wird in VENOM-NGO alles gelöscht, was für das Kundensegment NGO nicht benötigt wird. Entsprechend wird jeglicher NGO-spezifischer Code aus VENOM-REST entfernt. Das ursprüngliche Entwicklungsteam, bei VENOM waren das ca. 50 Personen, wurde entsprechend aufgeteilt in ein (kleines) NGO-Team und ein Team für den Rest. Als Resultat entstehen zwei verkleinerte Systeme, siehe (3) in der Abbildung.
In der Realität umfasste das NGO-Split System nur noch ca. 200kLOC, gegenüber den ursprünglichen 2mLOC – wir haben also eine Reduktion auf 10% (!) des gesamten Codes geschafft. Ich durfte mit dem NGO-Team drei Monate nach dem Split eine Retrospektive durchführen, und habe selten in so kurzer Zeit so viele positive Veränderungen erlebt: Die Time-to-Market im NGO war von 30 Tagen auf 5 Tage (!) gesunken, d.h. Feature-Requests konnten jetzt innerhalb einer Woche umgesetzt und in Betrieb genommen werden. Die Betriebsstabilität des Only-NGO Systems war deutlich besser als vorher, von der erheblich gestiegenen Zufriedenheit im Entwicklungsteam ganz zu schweigen.
Split+Extract kombinieren
An dieser Stelle bringt Aaron die beiden Ansätze Split und Extract zusammen – weil wir parallel zum Split noch weitere Teile des ursprünglichen VENOM Systems aus NGO und REST extrahieren können. Damit bekommen wir dann drei „Systeme“, die jeweils einzeln deutlich kleiner („brainsized“) gegenüber dem ursprünglichen VENOM System geworden sind (siehe Abbildung 8). Die Pfeile in Abbildung 8 symbolisieren „benutzt“-Beziehungen.
Völlig korrekt: gemeinsame Bestandteile bergen das Risiko versteckter und organisatorischer Abhängigkeiten – aber das ist in jeglicher Art von Modularisierung ein Thema. Auch in modernen Microservice-Systemen gibt es solche Art Aufrufabhängigkeiten -und auch dort müssen sie explizit beachtet und aktiv gemanaged werden.
Zu den „Common Services“ gehörten bei VENOM übrigens Dienste zur Rechnungsstellung und Integration der Buchhaltung, diverse rein technische Security-Funktionen, einige Adapter zu externen Datenlieferanten und Logistik-Anbietern etc. Insgesamt sprechen wir auch hier von mehreren 100kLOC an extrahiertem Code, eine beträchtliche Menge
Der NGO-Split inklusive der Extraktion relevant großer Common-Services dauerte übrigens mehr als 6 Monate. Das dient als Beispiel dafür, dass Sie Operationen an offenen Software-Herzen möglicherweise längerfristig planen sollten, und ggfs. auf mehrere kürzere Sprints verteilen müssen.
Warum NGO?
Sie fragen jetzt möglicherweise, warum wir denn nicht sofort alle disjunkten Benutzergruppen zu eigentständigen System gemacht haben, sondern mit dem eher kleinen NGO Split begonnen haben? Der Grund liegt im aktiven Risikomanagement: Ein solcher Split war für die SAMM Inc. ein Novum, etwas Vergleichbares hatte niemand im Team vorher durchgeführt, und wir haben eine Option gesucht, die folgende Bedingungen erfüllt:
- klein genug, um das gesamte wirtschaftliche Risiko im Rahmen zu halten,
- groß genug, damit dieser Versuch als Vorlage für weitere Splits dienen kann.
In Abbildung 2 haben Sie die Umsatzverteilung pro Kundensegment sehen können – auf die NGO’s entfallen etwa 5% des Umsatzes von SAMM. Selbst wenn der NGO-Split krachend gescheitert wäre, hätte das kein Insolvenzrisiko bedeutet. Auf der anderen Seite sind diese 5% wirtschaftlich so relevant, dass der erfolgreiche Split hervorragend als Vorbild weiterer Splits dienen konnte.
Auf Basis des erfolgreichen NGO-Splits hat Aaron dann tatsächlich noch weitere Splits angestoßen: Die Botschaften und diplomatischen Vertretungen sind nur einer davon, im realen VENOM-System gab es noch 5–6 weitere Kandidaten. Davon hat das Top-Management jedoch nur die ersten zwei zuende gebracht, danach wurde das Resultat als „gut genug“ eingeschätzt – sehr zum Unmut der Entwicklungsteams: Die hatten sich angesichts der positiven Auswirkungen bei NGO & Co. auch in ihren eigenen Bereichen auf deutliche Verbesserungen gefreut, wurden nun jedoch enttäuscht.
Technische Optimierungen
Im ursprünglichen VENOM versteckten sich vielfältige Altlasten: Frameworks von mittlerweile insolventen Herstellern, miserable Datenmodelle, unwartbare XML-Konfigurationen, Flash und weitere Sünden der Vergangenheit. Durch die bisher beschriebenen Ansätze zur besseren Modularisierung und zum systematischen Verkleinern haben wir ja noch keines dieser Probleme adressiert. Eines dieser Themen war die Berechnung von Artikel- und Angebotspreisen (pricing): Diese Aufgabe war in VENOM auf mehrere Komponenten verteilt (schlechte Kohäsion!), und dann auch noch in sehr unterschiedlichen Technologien (Java, Python, Cobol und Haskell) implementiert. Keine einzelne Person im Entwicklungsteam war in diesen vier Sprachen gleichermaßen „fit“, viele Änderungen am Pricing waren rein organisatorisch immens aufwändig. Für Haskell gab’s beispielsweise im Team nur eine Teilzeitkraft.
Aaron und das Team einigten sich auf eine Homogenisierung des Preisberechnung auf Basis Java. Große Teile der ursprünglich in Haskell implementierten Rechenregeln wurden mit Jboss-Drools neu implementiert, einige Python-Module schrittweise über Jython ebenfalls auf die Java-Plattform gebracht. Dieser Prozess streckte sich über mehr als sechs Monate – aber auch hier konnte das Team eine signifikante Verbesserung der time-to-market erreichen: Statt vorher 2+ Wochen gehen Änderungen am Pricing mittlerweile in weniger als einer Woche live.