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

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?

Im ersten Teil dieser Serie wurden die Nachteile von legacy.org und die Vorteile von agile.org gegenüber gestellt und erste Antworten zur Notwendigkeit einer Transformation bzw. eines Refactorings gegeben. In diesem Teil geht es darum, einen Anfang und eine Strategie für das weitere Vorgehen zu finden.

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?

Womit und wie anfangen?

Wie in Teil 1 dieser Serie gesehen, kann der Umbau einer legacy.org nur schrittweise erfolgen.
Doch bei welchem Teil des riesigen Legacy-Systems fängt man an?

Um einen möglichen strategischen Ansatz für diese Entscheidung zu zeigen, schauen wir uns zuerst zwei essentielle strategische Bestandteile des DDD Mindsets an, die solche Fragen beantworten können. Danach könnte die Entscheidung und das weitere Vorgehen etwas klarer sein.

Schnittmuster – Geschäftsmodelle sind beständiger als ihre Lösungen

Jede Organisation besteht aus mindestens einer Domäne. Eine Versicherungsgesellschaft bietet verschiedene Versicherungen an, ein Handelskonzern verkauft Waren.

Zoomt man tiefer hinein, so erkennt man, dass jede Domäne aus einigen bis sehr vielen Subdomänen (Subdomain) besteht. Der Handelskonzern hat z.B. einen Wareneingang, Verkauf, Online-Shop, Lagerhaltung, Vertrieb, Marketing, Kundenservice uvm. Manche dieser Subdomänen kommen in vielen Organisationen vor, andere sind sehr speziell oder einmalig. Und in allen gilt es, die dort vorhandenen “Probleme” zu kennen und die beste Lösung für die Benutzer oder Kunden zu finden.

Domäne (Domain bzw. Subdomain)
(von lateinisch dominium über französisch domaine „Herrschaft, Herrschaftsbereich“)

Wikipedia: Fachgebiete, also Themenbereiche, die Gegenstand einer inhaltlichen Spezialisierung sind.
Oder anders gesagt: Der Einflussbereich des Wissens, Einflusses oder der Aktivität. “Was eine Organisation kann und tut und die Welt, in der sie es tut”

Core Domain
(Mindestens) eine Subdomain, die einer Organisation einen Wettbewerbsvorteil, ein Alleinstellungsmerkmal oder einfach den meisten Nutzen und Ertrag bringt. Sie ist/sind die Legitimation dafür, dass wir die Software überhaupt selbst entwickeln.
(Wobei anzumerken gibt, dass es in vielen Organisation keinen solchen Grund gibt, weil das Softwaresystem nicht der entscheidende Faktor des Geschäftserfolgs ist. Und dennoch investiert man einen enormen Aufwand in die Entwicklung…)

Domain Model
Das Fachmodell (Domain Model) ist eine Abstraktion und Vereinfachung des Problems (oder eines Teils davon), mit dem es gelöst werden soll.

Die meisten Aufgaben- und Problembereiche der Subdomänen sind relativ stabil.
Ein Kundenservice wird sich meist um Kundenanfragen und deren Beantwortung kümmern, ein Wareneingang die Korrektheit der Lieferung überprüfen. Einzelne Themen, Abläufe oder Regeln ändern sich natürlich auch dort, die grundlegenden Problemstellungen bleiben jedoch relativ stabil.

Ungleich vielfältiger sind die Möglichkeiten der Lösung eines fachlichen Problems.
Ein Kundenservice kann per Telefon, E-Mail oder Facebook die Fragen und Wünsche seiner Kunden entgegen nehmen. Er kann sie nach Datum sortieren oder intelligente Algorithmen verwenden, um die Fragen nach Themen zu clustern. Oder einen automatischen Agenten mit künstlicher Intelligenz zum Beantworten entwickeln. Und vieles mehr.

Nicht nur, dass die einzelnen Subdomänen unterschiedliche Problemstellungen haben, die sie lösen müssen, sie haben zusätzlich ihre eigenen Mittel und Wege, ihre Fachsprache (Jargon, Ontologie) optimiert und wissen was gemeint ist, wenn sie einen Fachbegriff erwähnen.

Keine Organisation käme auf die Idee zwei Fachbereiche zusammenzulegen, die völlig unterschiedliche Problembereiche und Lösungsmodelle besitzen. Was macht ein bemitleidenswerter Mitarbeiter eines Kundenservices, wenn er plötzlich im Wareneingang arbeiten muss und kein Wort mehr versteht?

Umgekehrt ist genau das sehr oft bei Softwaresystemen der Fall. Da wird generalisiert und zentralisiert, bis die Daten aller Domänen in einer Datenbank sind, alle mit den selben Mechanismen kommunizieren und jeder Protokolle aufgezwungen werden, die sie erst mal mühsam verstehen und transformieren muss. Und umgekehrt natürlich genauso.
Ganz zu schweigen vom enormen Aufwand, dies alles über Domänen hinweg steuern und planen zu müssen, zudem dann noch der unsicherste aller Faktoren hinzukommt: der Mensch.

Aus diesem Grund wurde in DDD das Konzept des abgegrenzten Kontexts (Bounded Context [BC]) als zentrales strategisches Konzept eingeführt. Denn nur wenn es eine klare Abgrenzung der Anwendbarkeit eines Domain Models gibt, kann auch eine konzeptionelle Integrität gewährleistet werden.

DDD ist keine Anweisung, wie etwas architektonisch oder technisch gestaltet werden muss. Es ist vielmehr ein analytischer Ansatz zur Gestaltung von komplexen fachlichen Zusammenhängen mit Hilfe von Modellen.

Das Hauptziel ist die Gewährleistung konzeptioneller Integrität von Modellen eines fachlichen Problems.

Nur wenn diese Integrität sicher gestellt werden kann, d.h. alle Elemente eines Modells “an ihrem Platz sind” und alle Invarianten eingehalten werden, die einen jederzeit gültigen Zustand eines Modells garantieren, dann wird auch eine gute Implementierung möglich sein.

Das Konzept Bounded Context beinhaltet aber noch mehr, es ist eine eindeutige Begrenzung

• der Fachsprache der Domäne und deren Lösungsimplementierung
• der Anwendbarkeit eines Lösungsmodells (Domain Model)
• der Teamorganisation (Social Architecture around explicit contracts)
• der Benutzung innerhalb spezifischer Teile einer Applikation
• von physikalischen Manifestationen, wie
  • Code
  • Datenbankschemata
  • Frameworks
  • …

Optimale Ausrichtung von SubDomain, Bounded Context und Domain Model. Die Realität sieht leider meist nicht so schön aus …

Visualisiert und liest man die Beschreibung eines BC durch, so erkennt man vielleicht schon eine Beschreibung eines “idealen” agilen Teams…

Grenze um was?
Wie erwähnt, wird das Konzept Bounded Context oftmals als wichtiges Merkmal von Microservices genannt. Allerdings ist es oftmals nicht klar, um WAS diese Grenze eigentlich gezogen werden soll.

Ein BC ist nicht die Begrenzung eines beliebigen Teils von Software oder eines besonders kleinen Services. Ein beliebig kleiner und spezieller Service mag sinnvoll und seine Verantwortung und Schnittstellen klar definiert sein. Doch ein Bounded Context ist immer die Begrenzung der Anwendbarkeit (mindestens) eines fachlich relevanten Modells (Domain Model). Deshalb sollte man auch hier auf eine klare Terminologie achten. Sonst benutzt man dieses strategisch eminent wichtige Konzept beliebig, und damit wird es beliebig.

Damit sind wir beim Fazit dieses Abschnitts und der Vorgabe für alles folgende:

• Das Schnittmuster von Softwaresystemen können nicht Technologien oder schon bestehende und schädliche Strukturen der Kommunikation sein.

• Die benötigte  Aufteilung des Systems sollte (muss?) die Struktur und Dynamik der einzelnen Subdomänen und ihrer Abgrenzung zueinander widerspiegeln. Sie sichern die konzeptionelle Integrität der Fachlichkeiten.
  

Womit fängt man an?

Jetzt können wir die ursprüngliche Frage beantworten: mit der Core Domain.

Wie erwähnt, ist das der Fachbereich der Organisation, der die höchstmögliche Innovation und Sorgfalt und bestmögliche Qualität erfordert. Das bedeutet auch, dass man hier die besten Mitarbeiter, Voraussetzungen und Möglichkeiten der Zusammenarbeit gewährleisten muss. Denn wenn es hier nicht funktioniert, wird der Rest wahrscheinlich auch keinen Erfolg haben.

Doch Vorsicht! Mit “Core” werden, v.a. in der Unternehmenswelt, auch gerne Erfolge der Vergangenheit manifestiert, sind in der Sprache der Vergangenheit formuliert und damit leider auch eine Hauptquelle für Trägheit. Ergo sollte man an dieser Stelle auch diesen vermeintlichen “Core” hinterfragen, vielleicht finden sich neue und bessere Kernkompetenzen oder Lösungen.

Als Gegenargument könnte man einbringen, dass das Risiko zu hoch ist, in einem solch kritischen Bereich anzufangen. Doch warum sollte man einen Unterschied zum gleichen Ansatz beim Umbau von Legacy-Software machen, wo auch “start where it hurts most” empfohlen wird?
Eine Skalierung bei Erfolg in weniger kritische Bereiche wird dann wahrscheinlich keine größeren Probleme bereiten. Fängt man mit weniger kritischen an, wird es kein Indiz sein, dass es im hoch kritischen funktionieren wird. Das Verfahren ist in beiden gleich, von daher nur Mut, es kann nur einfacher werden!

Nicht immer ist klar, welcher Bereich das tatsächlich ist oder es werden zu viele Elemente dort hinein interpretiert. Es gibt verschiedene Möglichkeiten, dies herauszufinden und auf das absolute Minimum zu destillieren. Letzteres ist extrem wichtig, da alles, was nicht unmittelbar dazu gehört entfernt werden sollte. Natürlich ist auch dies ein iterativer Prozess, und beim Umbau von SW-Systemen als auch Organisationseinheiten macht oft nur ein schrittweises und kontinuierlich überprüfbares Vorgehen Sinn.

Im Kapitel “Schnittmuster…” habe ich die weitere Klassifizierung von Subdomains übersprungen:  die zwei besonders erwähnenswerten sind Supporting und Generic Subdomain.
Supporting Subdomains sind quasi Zulieferer der Core Domain. Sie sind auch wichtig, aber eben nicht ganz so kritisch, oder auch austauschbar. Generic Subdomains sind Bereiche, die so generisch sind, dass sie eingekauft werden können oder es bereits Standardlösungen dafür gibt, so dass es sich nicht lohnt, hier etwas selbst zu entwickeln.

Mögliche Werkzeuge zur Identifizierung und Klassifizierung von Subdomains und Bounded Contexts seien hier exemplarisch genannt: Business Model Canvas , Impact Mapping , Purpose Alignment Model , Cynefin Framework , Event Storming .

Was ist wie wichtig?

Als Beispiel eine Analyse der Domains mit Hilfe des Purpose Alignment Models. Dieses hilft bei der Priorisierung und Gewichtung von Themen, in dem es auf den zwei Achsen die unternehmerische Kritikalität (wie wichtig ist das für uns?) und die Marktdifferenzierung (wie heben wir uns am Markt, vom Wettbewerb, von bereits bestehenden Lösungen ab?) darstellt und gegeneinander abwägt.

Klassifizierung von Subdomains mit dem Purpose Alignment Model

Je nachdem, wo eine Domäne bzw. deren Lösung (oder Produkt) dann eingestuft wird, bestimmt dies ihre Klassifizierung. Bei der Core Domain wird dies fast ausschließlich der obere linke Quadrant sein, denn sie macht den Unterschied aus. Deshalb besitzt sie die höchste Priorität und wir sollten auch dort mit dem Umbau anfangen – und sie selbst entwickeln.

Im letzten Teil dieser Serie werden einige mögliche Vorgehensweisen und Werkzeuge vorgestellt, die für die Umsetzung des Vorhabens mit der neuen Sichtweise, einem ersten Kandidaten für den Umbau und der nun klareren Richtung, hilfreich sind.