Development Anwendungssoftware

Strategische Anwendungsmodernisierung mit Split+Extract-Strategien

Sie erfahren anhand eines (komplett anonymisierten) realen Beispiels, wie die inkrementelle Modernisierung eines historisch gewachsenen Systems funktionieren kann. Das riesige, gewucherte System VENOM mit mehr als 2 Mio. Codezeilen zu modernisieren oder komplett neu zu schreiben – vor dieser schweren Entscheidung stand die (fiktive, aber sehr realitätsnahe) Firma SAMM Inc.

Gernot Starke

Author

28.08.2020
Lesezeit: 19 Minuten
72 Views

Nachdem ein erster Versuch „Big Bang“ krachend gescheitert ist, übernimmt ein kundiger CTO und stimmt Team und Organisation auf ein mittelfristiges „changebut-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?

venom-Logo

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 – geben 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 zugrunde liegenden Credo von E-Commerce-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.

Abb. 1: Historie der SAMM Inc.

Der Fokus liegt auf sogenannten „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, insbesondere 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 Prozent des gesamten Umsatzes. Hier bietet VENOM unter anderem komplette Planung, Beschaffung, Aufbau von Gartenanlagen. Interessant hierbei ist die aufwendige Logistik, weil Teile der Materialien (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-Organisationen (NPO) und Non-Governmental Organizations (NGO) machen zwar nur 5 Prozent des Umsatzes aus, sind aber für SAMM Inc. wichtig fürs 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.

Abb. 2: Mehr als nur ein Webshop

Gute 45 Prozent 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 (grüne Kurve).

Abb. 3: Der Niedergang

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 aufwendigen 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 sogenannter Big Bang. In Anlehnung an die von der Gartner Inc. eine Zeit lang propagierte „IT der zwei Geschwindigkeiten“ (bimodale IT, siehe [Gartner]) hatte SAMM dazu in Berlin ein Start-up 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 Entwicklungsund Betriebsprozesse. Die genaue Analyse dieses gescheiterten Versuchs 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 [Spo00].
Nach fast 12 Monate Irrfahrt durch die Start-up-Szene, einem abstrus hohen Anteil extern vergebener Entwicklungsaufgaben (für ein Start-up viel zu teuer und wegen Know-how-Abwanderung zu riskant) und immens hoher Fluktuation (ein Zeichen fehlender Start-up-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 VE-NOM 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 Vertretern 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, siehe [aim42]), die in solchen Fällen eine Breitensuche empfiehlt (eine kompakte Zusammenfassung finden Sie in [Har20]). Details dieses systematischen Reviews spare ich hier aus Platzgründen, möchte allerdings festhalten, dass die Ursache vieler Probleme bei und mit VENOM in miserablen und überkommenen Prozessen statt in Sourcecode 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 Conway‘s 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.

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, sodass 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.

Abb. 6: Tagesgeschäft und Verbesserung vernetzen

Jede Iteration sollte aus beiden Bereichen Aufgaben enthalten. Ein vordringliches strukturelles Problem liegt in der schlechten Kohäsion und Modularisierung des gesamten Systems: VE-NOM erledigt schlicht zu viele Aufgaben – fachliche und technische Aspekte sind willkürlich gemischt. Schlechte Modularisierung führt bei VE-NOM 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.

Architektur und Technik von VENOM

VENOM besteht aus mehr als 2 Millionen Zeilen Code in mehr als 8 verschiedenen Sprachen, die grundsätzlich zeitgleich installiert 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.

Abb. 4: VENOM-Historie

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.

Abb. 5: VENOM, Bausteinsicht Ebene 1

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 weiter schreiben – 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 VE-NOM trotz dieser Zustände „am Leben“ erhalten.

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 bis 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-Code 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 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, das heißt 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 (SCS). 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: NGOs 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-spezifische Code aus VE-NOM-REST entfernt. Das ursprüngliche Entwicklungsteam, bei VENOM waren das circa 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. 200 kLOC, gegenüber den ursprünglichen 2 mLOC – wir haben also eine Reduktion auf 10 Prozent (!) 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, das heißt 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.

Abb. 7: NGO-Split

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. Die Pfeile in Abbildung 8 symbolisieren „benutzt“-Beziehungen des neuen Systems.

Abb. 8: Die Split+Extract-Kombination

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 gemanagt 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 usw. Insgesamt sprechen wir auch hier von mehreren 100 kLOC 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 gegebenenfalls auf mehrere, kürzere Sprints verteilen müssen.

Warum NGO?

Sie fragen jetzt möglicherweise, warum wir denn nicht sofort alle disjunkten Benutzergruppen zu eigenständigen Systemen 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 NGOs entfallen etwa 5 Prozent 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 Prozent 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 bis 6 weitere Kandidaten. Davon hat das Top-Management jedoch nur die ersten zwei zu Ende 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 aufwendig. Für Haskell gab es beispielsweise im Team nur eine Teilzeitkraft.
Aaron und das Team einigten sich auf eine Homogenisierung der Preisberechnung auf Basis von 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 Timeto-Market erreichen: Statt vorher mehr als zwei Wochen gehen Änderungen am Pricing mittlerweile in weniger als einer Woche live.

Fazit

Aaron hat mit seinem motivierten Entwicklungsteam das schwerfällige und von technischen Schulden belastete VE-NOM-System innerhalb von 12 Monaten hinsichtlich Time-to-Market, Zuverlässigkeit, Performanz und weiterer Qualitätseigenschaften signifikant verbessern können. Parallel dazu hat Beatrice (unsere sympathische Change-Managerin) einige organisatorische Aspekte im Unternehmen deutlich agiler, transparenter und flexibler gestalten können. Diese beiden Arten der Verbesserung (Technik/ Architektur sowie Prozesse) gehen Handin-Hand und führten auch betriebswirtschaftlich deutlich bergauf: Verbesserte Kundenzufriedenheit, kürzere Time-to-Market sowie weniger Produktionsfehler führten mittelfristig auch zu steigenden Erträgen.
Das vormals homogene Entwicklungsteam wurde auf mehrere („Pizza-Teams“) kleinere aufgeteilt, was zumindest bei manchen der Beteiligten weniger gut ankam. Zwischen diesen Teams fällt nach der Modernisierung Koordinationsund Abstimmungsaufwand an – der jedoch gegenüber den vielfältigen positiven Aspekten kaum ins Gewicht fällt. Insgesamt zeigt das Beispiel VENOM auf, dass auch große Verbesserungen parallel zum Tagesgeschäft möglich sind – gründliche Analyse, gute Kommunikation und ganzheitliches Herangehen vorausgesetzt. Insofern – mögen Beatrice und Aaron mit Ihnen sein.