legacy.org => agile.org

Wie transformiert man zu einer agilen Organisation?
Wie macht man träge gewordene Softwaresysteme wieder schnell?
Und was haben Legacy-Systeme, DDD (Domain-driven Design), Clean Architecture und Microservices damit zu tun?

Wer nun glaubt, dass die ersten beiden Fragen hier endgültig beantwortet wird oder fragt, warum man das überhaupt tun sollte, für den ist dieser Artikel hier bereits zu Ende.
Die Antwort auf die letzte Frage vorab: sehr viel.

Was gesagt werden kann: es reicht nicht, solche Vorhaben nur isoliert und ohne Vision oder Zielvorstellung anzufangen, und dennoch muss man nicht gleich alles ändern. Es gibt Möglichkeiten, mit denen man herausfinden kann, welcher Weg der beste sein kann und bereits etliche vorhandene Konzepte und erprobte Erfahrungen, wie es gelingen kann. Und definitiv können Werkzeuge, Prozesse und Prinzipien, die zu der aktuellen Situation geführt haben, nicht die Lösung des Problems sein.

Diese Artikelserie beantwortet die Fragen
1) Warum gibt es legacy.org, will man agile.org und was sind die Voraussetzungen dafür?
2) Womit und wie anfangen und welche Strategie verfolgen?
3) Wen oder was benötigt man und wie geht man vor?

tl;dr – Zusammenfassung

Kommunikation, Kontinuität, Kontext

Die agile Transformation einer schwerfälligen IT-abhängigen Organisation und der Umbau eines schwer wartbaren Softwaresystems profitieren vom Einsatz der gleichen Mechanismen: einer holistischen Sicht- und Handlungsweise auf Agilität und der Unterstützung bei der Entwicklung komplexer Softwaresysteme durch das strategische Mindset von DDD.

Sie basieren alle darauf, dass nur gemeinsames und kontinuierliches Ausprobieren, Lernen und Anpassen und die Fokussierung auf überprüfbare Ziele und anpassbare Pläne erfolgreich sein können. Und das man Problem- und Lösungsmodelle innerhalb eines fachlichen Kontexts eingrenzen sollte und sie auch ständig Änderungen unterworfen sind, die man iterativ lösen muss.

Was ist legacy.org?

Mit legacy.org ist eine Organisation gemeint, die sehr oder vollständig von der IT abhängig ist oder die IT ein elementarer Bestandteil des Geschäftsmodells ist und eine oder mehrere der folgenden Zustände bereits erreicht hat oder kurz davor steht:

• Praktisch alle Services und Komponenten des Systems sind hart voneinander abhängig, jede Anpassung bedingt Änderungen an vielen gleichzeitig und kostet viel Zeit und Aufwand.
• Zentrale Datenbanken und Frameworks integrieren viele Komponenten und führen zu noch mehr Abhängigkeiten, die nicht mehr sauber aufgelöst werden können.
• Dadurch gerät das Unternehmen immer mehr in Schwierigkeiten, da entweder die Mitbewerber oder der Markt selbst eine schnellere Adaption bieten bzw. wollen.

Warum will man eine agile.org?

Nun, im Prinzip um die meisten oder gar alle obigen negativen Faktoren und Zustände einer legacy.org zu beseitigen. Die Organisation ist zu schwerfällig, komplex, starr und schwer steuerbar und anpassbar geworden, kann nicht mit dem Wettbewerb mithalten oder zumindest besteht akute Gefahr dazu.
Wegen all dieser Gründe möchte man etwas dagegen unternehmen.

Die Motivationen und Ziele für eine Transformation hin zu agile.org können u.a. sein:

• Es gibt heutzutage praktisch keine Branche oder Domäne einer IT-getriebenen Organisation mehr, die nicht in einem dynamischen und komplexen Umfeld operiert.
  Von daher sind Schnelligkeit , Anpassungsfähigkeit und die Möglichkeit seine Ziele relativ einfach ändern zu können, maßgebliche Faktoren für den Erfolg.
  Oder sogar das Überleben.
• Der schwerfällige zentralistische und monolithische Ansatz der legacy.org ist kein Modell für die Zukunft, da er keinen der obigen Eigenschaften gewährleisten kann.
• Schnelligkeit und damit Anpassungsfähigkeit bedeuten nicht Qualitätseinbußen, weniger Konstanz oder mangelnde Sicherheit in der Planung. Sondern das Gegenteil davon, da man in der Lage ist, schnell und kontinuierlich seine Annahmen überprüfen und darauf reagieren zu können.  

Refactoring legacy.org

Wie baut man Legacy Software um oder ersetzt sie?
(Mit “Legacy Software” [LS] sind hier Softwaresysteme gemeint, die entweder zu schwerfällig, unwartbar oder instabil geworden sind, aus welchen Gründen auch immer).

Grundsätzlich gibt es drei Möglichkeiten:

1. LS-Entwicklung einstellen und neues System bauen
2. LS weiter betreiben, parallel neues System bauen und LS mit einem Release ersetzen
3. LS weiter betreiben, parallel und schrittweise einzelne Komponenten neu bauen und bestehende austauschen

Alle Vorgehen haben natürlich Vor-und Nachteile.
Mit dem Unterschied, dass Vorgehen 1 praktisch unmöglich ist. Außer man kann seine gesamte Organisation mehrere Jahre in bezahlten Urlaub schicken und in dieser Zeit auf Umsatz und Gewinn verzichten. Das dürfte nicht vielen Organisationen gelingen.

Auch Vorgehen 2 ist in der Praxis sehr schwierig umzusetzen. Da das alte System wahrscheinlich weiterhin produktiv ist und ebenso geändert wird, müssen bspw. alle Änderungen parallel berücksichtigt werden und ein immenser Aufwand für den Datenaustausch betrieben werden. Von den benötigten Ressourcen gar nicht zu reden, vor allem können die vorhandenen Fachexperten nicht an beiden Baustellen gleichzeitig arbeiten, und diese lassen sich leider nicht skalieren.

Bleibt also nur Vorgehen 3 als mögliche Lösung.
Auch hier muss ein hoher Aufwand wie bei Vorgehen 2 betrieben werden, allerdings nur für einen kleinen Teil des ganzen Systems. Und da man hier mit hoher Wahrscheinlichkeit auf viele Unbekannte oder Komplexitäten treffen wird, empfiehlt sich natürlich ein agiles Vorgehen, in kleinen, ständig überprüfbaren Schritten.

Gut, das geht vielleicht bei Softwaresystemen so – aber wie funktioniert es auf der Organisationsebene?

Grundsätzlich gibt es drei Möglichkeiten:

1. Organisation komplett neu agil aufstellen
2. Fachbereiche parallel neu aufsetzen und mit einem Mal bestehende ersetzen
3. Parallel und schrittweise einzelne fachliche Fähigkeiten neu aufsetzen und bestehende austauschen oder verkleinern

Hier kann man Gemeinsamkeiten erkennen. Analog zu SW-Systemen sind die gleichen Probleme und Herausforderungen zu meistern und genauso sind Vorgehen 1 und 2 nur sehr schwer oder überhaupt nicht durchsetzbar (außer die Organisation wird als Ganzes verkauft und der Käufer entfernt die unrentablen Bereiche…).

Kommunikation und Kontext sind die Könige

„Deine Organisationsstruktur löst deine Probleme nicht. Es ist nur ein Artefakt dessen, wie du es bisher gelöst hast.“
(A. Jacob)

Warum ein Softwaresystem und damit die davon abhängige Organisation zu einer trägen legacy.org wird, sind verschieden und doch folgt es oft einem gemeinsamen Muster. Nicht erst seit Conways Gesetz wissen wir, dass Systeme eine Kopie der Kommunikationsstrukturen des Unternehmens (und damit der “Achsen der Macht”) sind. Demnach sind die Ursachen dafür fast immer die vorhandenen Strukturen, Hierarchien und die Kommunikation (oder Nicht-Kommunikation) untereinander.

Wechselwirkung von Conway’s Law

Ein weiterer Grund sind fehlende oder ungenaue Abgrenzungen der Kontexte von Fachbereichen, -konzepten und -logik.
Der lange Zeit vorherrschende Trend zu einer Architektur der Vereinheitlichung, Zentralisierung oder Aufteilung nach technische Aspekten (z.B. DBA, Infrastruktur, Security) kann für die meisten Domänen als nicht mehr zeitgemäß oder sogar gescheitert angesehen werden und wird heute eher als Hauptgründe für das Entstehen träger und nur schwer änderbarer Systeme angesehen.

Die Gründe dafür sind vielfältig:
Die zuständigen Teams werden nach diesen technischen Kriterien aufgestellt werden, damit in Silos arbeiten und bestrebt sind, möglichst eine Lösung für unterschiedliche Fachbereiche anzubieten. Die dann aus diesem Grund vermischte Daten und sogar Logik enthalten und die Abhängigkeiten von Systemen maximieren. Ein zusätzlicher Grund ist, dass fachliche Anforderungen und Geschäftsmodelle wesentlich stabiler und in der Anzahl geringer sind als deren mögliche technischen Lösungen. Zusätzlich, und das ist ein noch wesentlich kritischerer Punkt, entstehen gefährliche Verständnislücken und Probleme in der bereits angesprochenen Kommunikation zwischen den Fachabteilungen und technischen Teams, was zu einer erheblichen Schwerfälligkeit und einem hohen Aufwand bei der Abstimmung führt.

So wie es beim Refactoring von Legacy-Software und -Komponenten nicht ohne die Mitarbeit aller relevanten “Kräfte” und einer guten Kommunikation untereinander funktionieren wird, verhält es sich mit der (agilen) Transformation einer Organisation.

Holistisches Denken und Handeln ist gefragt

Agile Transformationen werden meist “experimentell” gestartet. Man traut der Methodik noch nicht und möchte es erst mal mit möglichst wenig Risiko ausprobieren, in dem man ein Team wählt, dass an (hoffentlich nur) einem Projekt arbeitet. Das ist zunächst auch nachvollziehbar und völlig legitim.

Man kann punktuell einem Team von Software-Entwicklern einen Product Owner und einen Scrum Master vorsetzen, den Scrum-Guide lesen und dann glauben, dass in kurzer Zeit eine agile Transformation gelingt. Das kann sogar erfolgreich sein, z.B. bei einer Neuentwicklung, einem relativ autonomen Teil des Ganzen, einem Startup oder einer dazu neu gegründeten Teilorganisation.

Bei großen Organisationen funktioniert das in der Regel kaum. Ein Hauptgrund ist, dass die relevanten Stakeholder, Fachexperten und auch Endbenutzer gar nicht im Team sind, zu weit weg von diesem oder unterschiedlichsten Kommunikations- und Machtstrukturen ausgesetzt sind. Selbst wenn dort ein punktueller Erfolg erzielt wird, kann das nicht für die gesamte Organisation als Vorlage dienen und den gleichen Erfolg mit anderen Teams erzielen, das wäre ein immenser Zufall.

Allerdings muss nicht unbedingt die ganze Organisation agil transformiert werden, wie auch eine Legacy SW-System nicht vollständig umgebaut werden muss. In einem späteren Kapitel wird aber gezeigt, für welche Bereiche es getan werden sollte.

Zwei Beispiele für Holistik in der agilen Softwareentwicklung

Scrum ohne kontinuierliche Auslieferung

Ohne die Möglichkeit, Software kontinuierlich ausliefern zu können, z.B. mit Continuous Delivery, macht (die Einführung von) Scrum keinen Sinn.
Zumindest sollten die ersten Ansätze dafür zur Verfügung stehen und das Mindset bekannt sein, auch das wird iterativ und inkrementell weiterentwickelt.

Das erste Prinzip des agilen Manifests besagt, dass das Ziel ist, den Kunden durch eine frühzeitige und kontinuierliche Auslieferung von wertvoller Software zufrieden zu stellen. Denkt man holistisch und nach dem Prinzip “begin with the end in mind”, muss der Prozess primär darauf ausgerichtet sein. Denn was bringt es, nach einem zweiwöchigen Sprint ein Stück Software zu haben, das man nicht ausliefern und damit auch nicht überprüfen kann? Das führt den Kern agilen Vorgehens, den Inspect & Adapt Kreislauf, ad absurdum

Software- und Architekturdesign ohne Fachexperten

Die Grundhypothese von DDD ist:
“Der wesentliche Sinn von Software, ist die Fähigkeit, Probleme der Domäne für den Benutzer zu lösen.“

Und es basiert auf zwei Annahmen:

• Der Schwerpunkt des Softwaredesigns liegt auf der Fachlichkeit und der Fachlogik.
• Der Entwurf komplexer fachlicher Zusammenhänge sollte auf einem Fachmodell basieren.

Angefangen von der strategischen Planung von Problemen der Fachlichkeit, über die Gestaltung möglicher Lösungen mit Domänenmodellen, einer Abstraktion des fachlichen Problems, über die taktischen Bausteine der Implementierung: alles in DDD folgt dem praktisch gleichen Kreislauf.

Eine Architektur, Domänenmodelle und alle sonstigen Elemente sind niemals “fertig”, sondern werden kontinuierlich angepasst, sobald sich Rahmenbedingungen ändern. Und es spielt keine Rolle, wo das passiert. Eine neues Szenario in der Fachlichkeit kann zu einer Änderung in den Modellen und der implementierten Software führen. Und anders herum stellen sich in vielen Gründen die ursprünglichen Modelle als suboptimal heraus, sobald sie implementiert werden, was ebenso zu einer Anpassung führt.

DDD geht noch einen Schritt weiter und stellt durch die Ubiquituous Language, einer von allen Beteiligten verstandenen Fachsprache, sicher, dass der kritischen Faktor Kommunikation besser gebändigt wird.

Warum ich das Mindset von DDD als ein wichtiges Element eines holistischen Ansatzes der Agilität oder der Transformation dort hin ansehe, dürfte sich vielleicht hier schon manifestieren. In den nächsten Teilen dieser Artikelserie wird das hoffentlich noch deutlicher.

Nur gesamtheitlich erfolgreich

Weder die Fachexperten noch das Implementierungsteam aus Architekten, Entwicklern, Designern, Administratoren usw. arbeiten isoliert. Ohne kontinuierliche und gemeinverständliche Kommunikation und Abstimmung untereinander, funktioniert es nicht. Gerade bei der Transformation der Organisation sind alle Teile der Wertschöpfungskette gleichermaßen und gleichzeitig an deren Erfolg beteiligt. Die Möglichkeit der schnellen Auslieferung und Änderung von Software ist ein erstrebenswertes und in vielen Organisation sogar ein Überleben rettendes Ziel.
Doch es wird scheitern wenn diejenigen, die es entscheiden können und mitgestalten sollen, nicht parallel mit dem Umsetzungsteam kommunizieren, kooperieren und iterieren.

DDD selbst funktioniert überhaupt nicht ohne die permanente Zusammenarbeit aller Beteiligten, insbesondere nicht ohne Fachexperten. Andererseits ermöglicht und erzeugt es eben deshalb ein Verständnis, dass dazu benötigt wird.
Das Gegenteil davon ist der Grund, warum Organisationen wie legacy.org entstehen.

Im nächsten Teil dieser Serie wird die Frage beantwortet, womit man und wie anfangen sollte, wenn die Entscheidung für einen Umbau gefallen ist.