legacy.org => agile.org (Teil 3)

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?

Der zweite Teil dieser Serie beantwortete die Frage “Womit und wie anfangen, und welche Strategie verfolgen?”
Der letzte Teil beschäftigt sich nun mit den nötigen Werkzeugen und dem Vorgehen auf dem Weg von legacy.org zu agile.org.

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?

Andere Denkweise, andere Werkzeuge

Die Erkenntnisse des Abschnitts “Schnittmuster“ im zweiten Teil dieser Serie führten dazu, dass sich Softwareentwicklungen in den letzten Jahren vermehrt in Ansätzen manifestieren, die genau diesen Fokus besitzen und die Architektur und Entwicklung unterstützen. Einer dieser relativ neuen “Hypes”, Microservices (oder auch SCS und “Verticals”, a.k.a. autonome Komponenten), verfolgt dieses Schnittmuster.

Nicht umsonst wird DDD häufig im Zusammenhang mit Microservices oder SCS genannt.
Denn die Gestaltung komplexer Systeme mit den, insbesondere strategischen Denkweisen und analytischen Methoden von DDD führen fast zwangsläufig zu solchen Architekturen.

Analysiert man die am häufigsten genannten Merkmale solcher autonomen Komponenten, kann man darin viele Gemeinsamkeiten mit einer “idealen” agilen Organisation erkennen.

Business Capability
Die Summe dessen, was ein Bereich einer Organisation tut und das zum gesamten Erfolg der Organisation beiträgt. Diese Definition ist praktisch analog zu der von Domäne bzw. Subdomäne, so dass beide Begriffe wechselseitig in diesem Artikel verwendet werden.

Es kann eine Beziehung zwischen Business Capability und Bounded Context festgestellt werden:
Diese Leistungsfähigkeiten sind Bestandteile des Problemraums und ändern sich nur inhaltlich in den Lösungsmodellen, als Ganzes sind sie konstant vorhanden.
Wie bereits erwähnt, gibt es im Gegensatz dazu im Lösungsraum sehr viele mögliche Möglichkeiten, ein Lösungsmodell zu implementieren. Die Anwendbarkeit und tatsächliche Implementierung der Modelle muss explizit begrenzt werden. Die Fachlichkeiten, deren Sprache und die Artefakte der Lösung machen nur innerhalb dieser Grenzen einen Sinn.

Produkte statt Projekte
Ein oft genanntes Merkmal von Microservices ist, dass man in Produkten und nicht Projekten denken sollte. Das kann generell für alle agilen Vorgehen geraten werden, Projektdenken ist eines der größten Hindernisse in einer agilen Transformation.
Es würde den Artikel sprengen, diese hier genauer zu erklären, deshalb nur so viel dazu: Projekte messen ihren Erfolg anhand der Erreichung der drei Ziele Zeit, Budget und Umfang und danach wird die Entwicklung ausgerichtet. Bei Produkten zählt vorrangig ihr Nutzen bzw. ihr (Markt-)Erfolg.

Leistungsfähigkeit statt Produkt
Geht man noch einen Schritt weiter, so sollte man anfangen nach  “Leistungsfähigkeit eines Teams oder Geschäftsbereichs” (eine freie Übersetzung von Business Capability) zu gestalten.
Denn grundsätzlich löst ein Team solch eines Bereiches seine Probleme mit Mitteln, die er für die wirkungsvollsten hält. Das werden häufig selbst entwickelte Produkte sein, können aber ebenso gekaufte Produkte, SaaS bis hin zu externen Dienstleistern sein.

Capability (oder Goal) Roadmap
Gab es bisher eine globale Product Roadmap über verschiedene Bereiche eines Projekts oder Produkts hinweg, so wäre diese dann nicht mehr an konkrete Produkte gebunden, sondern an die Fähigkeiten, die alle Teams zur Organisation beitragen können. Sollen sie erweitert oder neu geschaffen werden, werden nicht mehr Produktreleases geplant sondern der Zeitpunkt, ab dem neue oder veränderte Probleme durch dieses Team gelöst werden können.

Abgesehen davon: Straßenkarten (also Roadmaps) bieten Optionen zu Erreichen eines Zieles an. Verfährt man sich oder stellt sich ein Weg als unpassierbar dar, kann man das Ziel auch auf anderem Wege erreichen. (Und selbst das Ziel kann sich ändern, weil man es z.B. nicht rechtzeitig erreichen kann und deshalb ein anderes wählt oder wieder zurück fährt).
Welche Optionen bieten die meist vorhandenen linearen “Einbahnstraßen” Product Roadmaps an?

Gegenseitige Abhängigkeiten, Kommunikationswege und Beziehungen
Bei diesem, oft sehr kritischem Punkt hilft ein weiteres Werkzeug aus dem Strategie-Werkzeugkasten von DDD: die Context Map.

Wie behält man die Orientierung? Mit einer Karte!

Eine Context Map ist prinzipiell ein sehr einfaches und dennoch mächtiges Werkzeug: diese Karte visualisiert auf einem relativ hohen Maßstab die technischen und vor allem organisatorischen Abhängigkeiten eines System und seiner Kontexte. “Vorhanden” ist dabei wichtig, die Karte bildet immer den aktuellen Zustand ab.

Die (extrem vereinfachte) Context Map einer legacy.org kann nach einer ersten Analyse der Domänen und Kontexte so aussehen:

Vereinfachte und reduzierte Context Map einer legacy.org

Die interessantesten Bereiche sind die Überschneidungen der Kontexte (dargestellt durch die roten Blitze). Diese deuten auf unklare oder unsaubere Konzepte und Zuständigkeiten, starke Abhängigkeiten und komplexe Strukturen der Kommunikation hin. Welche Art von Überschneidungen und Abhängigkeiten es gibt, ist bei legacy.org sowieso meist nicht klar sichtbar.

Fängt man mit dem Umbau an, identifiziert und eliminiert die Probleme der Überschneidungen und extrahiert nach und nach die einzelnen Kontexte, dann bilden sich nach und nach etwas klarerer Strukturen:

Vereinfachte und reduzierte Context Map einer legacy.org auf dem Weg zur agile.org

Man wird nie alle Abhängigkeiten eliminieren können, und mache Kontexte werden weiterhin monolithisch sein. Es macht i.d.R. keinen Sinn, eine eigene Buchhaltungssoftware zu bauen. Das ist eine Domäne, die in fast allen Unternehmen benötigt wird und es gibt etliche ausgereifte und standardisierte Lösungen dafür.

Und wie bei normalen Landkarten auch, kann man natürlich mit verschiedenen Maßstäben und damit unterschiedlichen Detailgraden planen und designen…

Wie geht man konkret vor?

Im Prinzip nicht anders als bei einer Entwicklung eines neuen Produktes. In dem man nach und nach Teile der Geschäftslogik analysiert bzw. extrahiert und in ein neues Produkt implementiert.

Es gibt allerdings einen grundlegenden Unterschied zu einer legacy.org, in der schon (vermeintlich) alles vorhanden ist. Das kann ein Nachteil sein, da man vieles erst mal übernehmen (und erst mal verstehen) muss. Was allerdings im Gegensatz zu einem neuen System auch ein Vorteil sein kann, da nicht alles neu erfunden werden muss.

Die Frage kann im Speziellen natürlich nicht allgemeingültig beantwortet werden, dazu gibt es zu viele unterschiedliche Systeme und noch viel mehr mögliche Lösungen.
Bleiben wir hier im Zusammenhang mit DDD, so hat sich Clean Architecture (auch bekannt als Hexagonal oder Onion Architecture, oder Ports & Adapters) als Ansatz zur Gestaltung der Architektur sehr bewährt.

Was zunächst nach “klassischen” Layern aussieht, entfaltet seine Stärke, wenn man weiß, dass alle Abhängigkeiten immer nur von außen nach innen zeigen.
Das heißt der Kern, das Domain Model, ist nicht von den Applikationsregeln oder Use Cases, dieser nicht von Interfaces zu Controllern oder Gateways und der nicht von Treibern, Datenbanken oder UIs abhängig.

Clean Architecture mit beispielhaften typischen Elementen

Diese Architektur unterstützt das iterative Vorgehen sowohl von DDD als auch Agilität selbst in höchstem Maße. So kann man den kritischen Teil, das Domain Model, sauber und unabhängig von äußeren Einflüssen entwickeln und mit Unit Tests überprüfen.
Die übrigen Schichten, wie z.B. Application Services oder Adapter, können ebenfalls schrittweise implementiert werden, anfangs z.B. mit Mocks oder InMemory Datenbanken, danach mit konkreten Technologien. Sie stellen übrigens eine perfekte Nahtstelle für Akzeptanz- oder Integrationstests dar.

Wichtig: das ist NICHT die Architektur des gesamten Systems!
Sondern nur einer einzelnen autonomen Komponente bzw. eines Bounded Context.

Das alles passiert in einem Kreislauf, in DDD dem sog. “Modelling Whirlpool”, an dem alle Mitglieder des Teams ständig arbeiten. Man entwirft und implementiert ein Szenario, überprüft es, “fordert” es mit Grenzbedingungen heraus, modelliert, programmiert und präzisiert es immer mehr. Ein weiterer, eminenter Vorteil ist die Austauschbarkeit von Elementen jeder Schicht, was aufgrund der eine wichtige Grundvoraussetzung für adaptive Systeme ist.

DDD Modelling Whirlpool

Dieses Vorgehen empfiehlt sich ganz besonders beim Umbau eines Legacy-Systems.
Dort wird man nur schrittweise vorgehen können, und ein Use Case nach dem anderen implementieren, das Domain Model verifizieren und ggfs. anpassen und von vorne beginnen. Wahrscheinlich mit dem Unterschied, dass die Interfaces zur Persistenz oder externen Schnittstellen mit einem temporären Zwischensystem zur Überbrückung der Umbauphase (Stichwort: ACL [Anti-corruption Layer], siehe dazu den Post meines Kollegen Tobias Flohre ) gestaltet werden müssen, da in dieser Phase unterschiedliche Datenmodelle in eine oder beide Richtungen verarbeitet und übersetzt werden.

Man wird, und muss auch nicht, den kompletten Monolithen ersetzen. Teile dessen können sehr gut mit den bestehenden Zuständen weiter arbeiten. Zumal wahrscheinlich viele Teile so viele Abhängigkeiten haben, dass ein temporärer Adapter auch mal zu einem permanenten werden kann, weil sich der Aufwand für einen kompletten Umbau nicht lohnt. Selbstredend muss diese Einschränkung transparent sein und explizit gemacht werden.

Wen oder was benötigt man für den Umbau?

Hat die Analyse der gesamten Domäne eine oder mehrere Core Domains identifiziert und ist die wichtigste (ggfs. mit Priorisierungen) ausgewählt und ihr Inhalt und Grenzen (Bounded Context) formuliert, gilt es nun ein interdisziplinäres und schlagfertiges Team aufzustellen, und es mit allen nötigen Personen und Ressourcen auszustatten, die die Probleme dieser Domäne erkennen und mit Software lösen können.

Zwei Rollen im Team sind unabdingbar:
Erstens, und das ist die wichtigste Rolle überhaupt, einen oder mehrere (typische) Vertreter der eigentlichen Nutznießer (Benutzer/Kunden) der Lösung.

Und zweitens mindestens ein erfahrener Fachexperte, der Vollzeit in diesem Team mitarbeitet und dessen Beitrag durch keine weiteren Aufgaben beeinträchtigt wird.

Ohne den Fachexperten wird man das eigentliche Problem nicht analysieren und modellieren können und ohne einen Nutznießer nicht wissen, ob es den gewünschten Nutzen oder Mehrwert bringt.

Nur so kann man sicher stellen, dass das Vorhaben eine vernünftige Basis hat, die eine Transformation auch realistisch messbar machen. Denn ist dies nicht der Fall, wie in vielen halbherzigen Vorhaben dieser Art, wird sie nur mit viel Glück erfolgreich sein. Im schlimmsten, und leider häufigsten Fall, wird das Scheitern oder die nicht ausreichenden Erfolge als Nachteil des agilen Vorgehens selbst gewertet.

Wichtig hierbei: es ist wesentlich entscheidender, hier technische und Designexzellenz der Mitarbeiter im Team zu haben als saubere Prozesse. Der Prozess mag noch so gut sein, mit mittelmäßigen Leuten wird auch das Ergebnis mittelmäßig. Umgekehrt wird ein nicht optimaler Prozess sehr oft durch Meisterschaft aufgefangen.
Sollte auch dieses Team scheitern, dann hat man ein anderes Problem…

Wie dieses Team dann seine Arbeit organisiert, welches Vorgehens und welche Technologien es wählt ist primär nicht entscheidend, so lange sie agil vorgehen, also vor allem iterativ und mit Augenmerk auf schnelles Feedback.

Wie geht es weiter?

Zeigt das erste Refactoring von legacy.org Erfolg, so kann man mit dem oder den nächsten BC weiter machen.

Es sollten jedoch zwei Einschränkungen berücksichtigt werden:
Dass ein Team erfolgreich agil arbeitet, ist kein Indiz dafür, dass es bei anderen auch gelingt. Ebenso können nicht externe Beispiele erfolgreicher agiler Transformationen für die eigene Organisation kopiert werden. Nicht jede Organisation ist Google, Netflix oder Spotify, und eine Skalierung kann sich völlig unvorhersehbar verhalten, wenn bestimmte Kapazitäten oder Mengen unter- oder überschritten werden.

Zweitens lässt sich nicht jede Subdomäne bzw. BC agil transformieren oder der Aufwand rechtfertigt nicht den Nutzen. Weniger, weil es nicht methodisch oder technisch möglich wäre, sondern vielmehr weil Teile der Organisation, die einen Einfluss auf die Subdomäne haben, nicht die entsprechenden Voraussetzungen oder Motivationen haben, dies zu unterstützen. Oder auch nicht wollen.

Nicht alle Organisationen können agil werden
Es gibt Grenzen, wie sehr sich eine Organisation, bzw. ein Teil davon, ändern kann.
Ein Grund sind gegebene Genotypen und Phänotypen. Ein Genotyp ist prinzipiell die DNA der Organisation, und dieser wird fast ausschließlich von der Führung her bestimmt, zumindest in den derzeit immer noch vorherrschenden Strukturen von Organisationen. Der Phänotyp ist durch äußere Einflüsse anpassbar, aber eben nur in bestimmten Grenzen – und diese Grenzen setzen fast immer die Menschen, die daran beteiligt sind.
Es gibt erfolgreiche Beispiele, wo dies dennoch gelingen kann. Aber es sollte zumindest bekannt sein, dass aus u.a. diesen Gründen eine Transformation oft nicht gelingen kann.
Mehr dazu und weitere Quellen gibt es hier: http://ralfw.de/2016/03/the-agile-organization-illusion/

In jeder (größeren) Organisation gibt es Bereiche, die in unterschiedlichen Quadranten des Cynefin-Modells untergebracht sind. Wobei anzumerken ist, dass man sich aufgrund der heutigen Dynamik von Märkten und Technologien praktisch immer im Quadranten “Komplex” bewegen wird.

Deshalb sollten alle Subdomains, die entweder vom Typ Core oder Supporting sind, agil transformiert werden. Die Komplexität und Dynamik erfordert ein exploratives und iteratives Vorgehen.

Fazit: wieder mal, “Communication & Context is King”

Man kann ein monolithisches Softwaresystem nicht von heute auf morgen in eine Architektur mit selbstbestimmten und autonomen Komponenten transformieren. Analog dazu kann nicht eine legacy.org mit einem Mal agil transformiert werden. Daran sind zu viele Aspekte beteiligt, allen voran die vorhandene Kultur der Zusammenarbeit und Kommunikation der Organisation..

Es wird bei beiden immer Teilbereiche geben, die nicht (vollständig) transformiert oder nicht autonom gestaltet werden können. Doch auch das kann iterativ immer weiter verbessert werden. Und falls es ab einer gewissen Stufe nicht weiter möglich ist oder der Aufwand im Verhältnis zum Nutzen zu hoch ist, ist es zumindest transparent geworden und die Einschränkung kann in der weiteren Planung berücksichtigt werden.

Was aber immer im Fokus stehen und meiner Meinung nach transformiert werden sollte, sind die Bereiche, die für die Organisation von eminenter Wichtigkeit sind. Sei es, weil sie einen Wettbewerbsvorteil bieten oder für die weitere Entwicklung oder gar das Überleben notwendig sind. Die heutigen Märkte und Möglichkeiten sind zu dynamisch, um sie mit den gleichen Möglichkeiten zu bestehen, mit denen die legacy.org entstanden ist.

Das wichtigste Kriterium dabei ist, dass man die Grenzen, d.h. den Kontext der Leistungsfähigkeit explizit setzt, diese klar definiert und sie im Gesamtkontext transparent macht. Das wird wahrscheinlich nicht beim ersten Mal und nicht immer vollständig gelingen. Von daher gilt auch hier, dass ein iteratives Vorgehen, das Einholen von schnellem Feedback, der permanenten Mitarbeit aller relevanten und fähigen Personen und die Gestaltung aller Artefakte und Prozesse auf hohe Anpassbarkeit der Schlüssel zum Erfolg ist.