Redaktion: Hallo Christian! Ihr bringt in eurem JAX Talk die Systemtheorie nach Luhmann mit Softwareentwicklung und -architektur zusammen. Was können Entwickler von der Systemtheorie lernen?

Es gibt eine starke Analogie zwischen der Kommunikation, die in sozialen Systemen stattfindet, und der Kommunikation innerhalb von Softwaresystemen.

Dr. Christian Mennerich: Den Vortrag halte ich ja zusammen mit Freddy Meseck, der bei uns als systemischer agiler Coach arbeitet und sich von daher mit der Systemtheorie sehr gut auskennt. Bei synyx arbeiten wir in den Softwareentwicklungsprojekten u.a. nach den Prinzipien des Domain-driven Design (DDD), folglich ist eine große gemeinsame Aufgabe das Finden der relevanten abgeschlossenen Kontexte (Bounded Contexts).

Freddy und ich sind nun schon ein paar Jahre zusammen in verschiedenen Projekten und Teams unterwegs und waren uns einig, dass ein guter soziologischer Ansatz fehlt, um diese Kontexte systematisch zu finden und zu beschreiben. Die sozialen Systeme gemäß der Systemtheorie nach Luhmann, so wie wir sie interpretieren, sind unserer Meinung nach hierzu gut geeignet.

Für Entwickler*innen in einem agilen Projekt ist die Systemtheorie, insbesondere der darin enthaltene konstruktivistische Ansatz, unserer Meinung nach ein geeignetes Werkzeug um zu verstehen, warum es in Softwareprojekten immer wieder zu Missverständnissen kommen wird. Aus diesem Bewusstsein heraus lässt sich das gemeinsame Verständnis mit POs, Stakeholdern und Endanwendern erhöhen.

Die Systemtheorie liefert noch einmal eine andere Sichtweise auf iteratives Vorgehen und motiviert zu kleinen Inkrementen in einem kontinuierlichem Ausrollprozess, experimentellem Lernen, “fail fast” und anderen agilen Elementen. Weiter verändert Software ja auch die “Gesellschaft” der Anwender. Für Entwickler*innen ist das eine wichtige Erkenntnis. Es gibt eine starke Analogie zwischen der Kommunikation, die in und zwischen sozialen Systemen stattfindet, und der Kommunikation innerhalb und zwischen Softwaresystemen. Dies legt eine nachrichtengetriebene Systemarchitektur nahe, und die Kommunikation über Domänen-Events.

Die Herausforderungen, die nachrichtengetriebene verteilte Systeme mit sich bringen (wie die Fragen nach Zeiten, Reihenfolgen, Zustellhäufigkeiten usw.), erhalten so eine starke fachliche Komponente, da Kommunikation zwischen sozialen Systemen oft ebenso “unvorhersagbar” stattfindet. Für Entwickler*innnen wird es so natürlicher, diese Herausforderungen auch im Code anzugehen und gegenüber POs und Stakeholdern zu motivieren.

Redaktion: Ihr schreibt in eurem Abstract zum Talk, dass es darauf ankomme, “die Realitätskonsense der beteiligten sozialen Systeme isomorph zur Deckung zu bringen, um ein für alle zufriedenstellendes Softwareprodukt zu erhalten.“ Kannst du das einmal anhand eines Beispiels erläutern?

Dr. Christian Mennerich: Ja klar, die Systemtheorie ist als solche ja sehr abstrakt und als Universaltheorie ja nicht so ganz trivial. Unserer Meinung nach ist an dem Ansatz aber nichts Esoterisches! In unserem Vortrag bringen wir ganz konkrete Beispiele aus einem unserer Kundenprojekte, in dem es um die Digitalisierung von Prozessen an Containerterminals im Hinterland geht.

Schauen wir zum Beispiel auf das Terminalgate, den Ort, an dem LKWs, die Container bringen oder abholen, kontrolliert und eingelassen oder abgewiesen werden. Wir können das Gate als ein soziales System verstehen (einen Bounded Context), den wir in Software abbilden wollen. Die Mitarbeiter am Gate arbeiten schon seit langem zusammen, sind abgestimmt und haben einen “Konsens”, ein gemeinsames Verständnis über ihre Arbeitsweisen und -prozesse: Wie wird mit LKWs im “Normalfall” umgegangen? Wie mit welchen, die nicht angemeldet sind, die trotz Anmeldung nicht kommen usw.? In der Sprache Luhmanns spricht man hier von “anschlussfähiger Kommunikation”, von “Mustern” und “Prozessen”.

Nun soll das Gate durch eine Software unterstützt werden. Ein Requirements Engineer “verzerrt” diesen Konsens bei der Anforderungserfassung, da er das soziale System “Gate” verändert und zusätzlich seine Sichtweise unvermeidlich mit einbringt (seine “Konstruktion der Realität”). Das Ergebnis soll dann von einem Entwicklerteam umgesetzt werden. Die Entwickler sind aber auch ein soziales System, das eine eigene Konstruktion und Interpretation der Anforderungen ausbildet, sich also einen “Konsens” darüber bildet, was es umsetzen soll und was das bedeutet.

Um bei den Mitarbeitern am Terminal eine hohe Akzeptanz zu schaffen und sie bestmöglich in ihrem Prozessen zu unterstützen, sollten Mitarbeiter und Entwickler die Prozesse möglichst gleich verstehen. Das meinen wir damit, wenn wir davon sprechen, dass die Konsense zur Deckung kommen sollen. Für uns ist eine hohe Übereinstimmung der Konsense eine Art Maß dafür, dass die Software leistet, was sie soll und auch akzeptiert ist.

Software-Architektur Trends

Redaktion: Software-Architektur ist allgemein ein breit gefächertes Gebiet – ebenso unterschiedlich ist das Rollenverständnis unter Software-Architekten. Worin siehst du persönlich in deiner Position als Software-Architekt deine Hauptaufgabe? Was ist dir besonders wichtig?

Mir persönlich ist es wichtig, dass die Architektur-Entscheidungen fachlich getrieben sind.

Dr. Christian Mennerich: Mir persönlich ist es wichtig, dass die Architekturentscheidungen fachlich getrieben sind, das heißt, dass die Entwicklung Business-zentriert stattfindet, nicht technisch. Dies gilt für alle Ebenen der Softwarearchitektur, von den groben Systemschnitten bis hin zur konkreten Implementierung der einzelnen Services.

Hier achten wir verstärkt auf DDD, nachrichtenorientiertes Denken von Beginn an, das Einhalten hexagonaler Architektur-Pattern und ähnliches. Hier ist es meiner Meinung nach unerlässlich, iterativ zu arbeiten und die Teams von vorne herein mit möglichst breit gefächertem Wissen aufzustellen.

Redaktion: Welchen Architektur-Trend findest du momentan besonders spannend?

Dr. Christian Mennerich: Streng nachrichtenorientiertes Design in verteilten Systemen, vor allem den Gedanken der Domänen-Events konsequent anzuwenden, finde ich spannend. Wenn wir fachlich getrieben kleine abgeschlossene Services auch in verteilten Teams entwickeln lassen, dann bekommt auch die Kommunikation über Nachrichten und deren unterschiedliche Interpretation durch verschiedene Services eine fachliche Entsprechung. Das wirft eine gute neue Perspektive auf Diskussionen über Garantien in solchen verteilten Systemen (wie Zustell-Reihenfolgen und -zeiten, exactly-once delivery usw.).

Redaktion: Und welches Thema im Bereich der Software-Architektur ist deiner Meinung nach im aktuellen Diskurs etwas unterbelichtet?

Dr. Christian Mennerich: Was mich brennend interessiert, ist die Frage, was die neuen Architekturstile genau bedeuten und mit der Anwenderschaft machen. Wenn wir in Microservices (oder noch kleineren Einheiten) entwickeln, was bedeutet das dann beispielsweise für Bounded Contexts nach DDD und Conways Law, wie können wir diese Konzepte dann noch verstehen?

Das ist auch eine Frage, die Freddy und mich angetrieben hat, Luhmanns Systemtheorie und Softwareentwicklung zusammen zu bringen; Software und Digitalisierung machen ja etwas mit der Gesellschaft, und umgekehrt. An dieser Stelle fände ich eine breitere Diskussion spannend, wie sie beispielsweise momentan anläuft, wenn es um ML und moralische Fragestellungen geht.

Redaktion: Was ist die Kernbotschaft eurer Session, die jeder Besucher mit nach Hause nehmen sollte?

Dr. Christian Mennerich: Wir wünschen uns klar zu machen, dass eine objektive Realität keine Relevanz hat, da die Realität nicht objektiv beschrieben werden kann! Beschreibung ist immer Konstruktion des Beobachters. Um gute Software zu bauen, gilt es, gut und viel zu kommunizieren, um die richtigen Konsense zu finden. Denn alle am Softwareentwicklungsprozess beteiligten sozialen Systeme haben jeweils einen “eigenen Konsens”. Diese Konsense gilt es dann gemeinschaftlich zu harmonisieren, und da hilft nur das gemeinsame Ausprobieren kleiner Änderungen, um beweglich zu bleiben.

Redaktion: Vielen Dank für dieses Interview!

Das Interview führte Hartmut Schlosser.

The post Was Software-Architekten von der Soziologie lernen können appeared first on JAX.

Was ist eine Wardley Map?

Wir betrachten ein beispielhaftes Szenario, das sich an einen realen Anwendungsfall anlehnt. In diesem Szenario bietet ein Unternehmen seinen Kunden eine Übersicht über Verträge und Leistungen über ein webbasiertes Kundenportal an. Das Kundenportal greift auf ein cloudbasiertes CRM-System und auf ein internes System zur Vertragsführung zu. Letzteres ist an eine Standardlösung von SAP angebunden, um Ein- und Auszahlungsvorgänge abzuwickeln. Kundenportal, Vertragsführung und SAP werden inhouse im eigenen Rechenzentrum betrieben, das CRM wird als Software-as-a-Service-Angebot genutzt. Zusätzlich entwickelt das Unternehmen eine Kunden-App, die über ein Backend an das Kundenportal angebunden ist. Die App soll dessen Funktionen auch zur mobilen Nutzung anbieten. Die Entwicklung von App und Backend hat gerade erst begonnen.

_{Abb. 1: Eine Landkarte des Beispielszenarios}

Abbildung 1 zeigt eine Wardley Map unseres Szenarios, bestehend aus einem Bezugspunkt (Anchor) und miteinander verbundenen bedeutsamen Dingen (Components). Der Bezugspunkt ist der Nordpfeil unserer Landkarte, Positionen werden relativ zu diesem Bezugspunkt in der Karte vermerkt. Auf unserer Karte ist der Kunde der Bezugspunkt, alle Components werden also bezogen auf den Kunden ausgerichtet. Direkt verknüpft mit dem Bezugspunkt sind Components, die Bedarfe (Needs) repräsentieren. In unserem Fall drückt die Map aus, dass der Kunde mit den Components „App“ und „Kundenportal“ interagiert.

Components repräsentieren alle Dinge von Bedeutung im Kontext unserer strategischen Betrachtung. Es handelt sich um Abstraktionen, maximale Vereinfachungen komplexer Zusammenhänge. Softwaresysteme können ebenso in einer Map als Component vorkommen wie Dienstleistungen, Wissen oder physikalische Kräfte. Daumenregel: Ist es strategisch bedeutsam, wird es als Component Teil der Map.

Die Ausrichtung der Components erfolgt entlang der vertikalen Achse (Value), abhängig von der Sichtbarkeit des Werts für den Kunden (unser Bezugspunkt, Anchor). Components, mit denen der Kunde direkt interagiert, sind für ihn auch direkt wahrnehmbar und werden daher weiter oben angeordnet. Weiter unten stehende Components sind, relativ zum Bezugspunkt Kunde, weniger sichtbar – aber nicht weniger wichtig. Der Wert einer Component und seine vom Bezugspunkt aus wahrnehmbare Sichtbarkeit sind zwei voneinander zu unterscheidende Merkmale. Durch die Verbindungen zwischen den Components ergibt sich eine Wertkette (Value Chain), bei der Components aufeinander aufbauen.

Je weiter oben sich eine Component befindet, umso erkennbarer ist ihr Wert für den Kunden, je weiter rechts sie sich befindet, desto höher und reifer ist sie entwickelt. Die horizontale Achse beschreibt den Grad der Entwicklung (Evolution). Dieser sagt etwas über den Charakter der jeweiligen Component aus: Stellen wir ein Softwaresystem als Component am linken Rand der Map dar, sagen wir damit aus, dass das System sich am Anfang seiner evolutionären Entwicklung befindet. Gleiches gilt für Components, die Wissen oder Methoden repräsentieren. Steht eine Component weit links, kann das beispielsweise bedeuten, dass Technologien oder Konzepte eingesetzt wurden, zu denen bisher im Unternehmen wenig Wissen verfügbar ist. Dadurch erhält die Component im betrachteten Kontext experimentellen Charakter. Das birgt Chancen für neuartige Ideen und somit künftiges Potenzial sowohl für Wettbewerbsvorteile als auch für Risiken. Am linken Rand der Evolutionsachse sind die Unwägbarkeiten hoch. Je weiter eine Component sich entlang der Achse bewegt, umso reifer wird sie, d. h. umso geringer die Unwägbarkeit, und umso besser lassen sich Chancen und Risiken erkennen und bewerten. Die Einteilung der Achse in vier Segmente verdeutlicht das: Im ersten Segment (Genesis) findet die „Werdung“ statt. Der Fokus liegt auf der Erforschung und Erkundung und der ursprünglichen Entstehung von etwas Neuem. Im zweiten Segment handelt es sich um spezifische, maßgeschneiderte (Custom-Built-)Lösungen. Im dritten Segment erhält eine Component hinsichtlich ihrer Entwicklung und Reife die Eigenschaften eines Produkts. Components im vierten Segment sind so weit entwickelt, dass sie allgegenwärtig und einfach verfügbar sind (Commodity + Utility), vergleichbar mit Elektrizität, Radioempfang oder, dank Cloud Computing, Rechenleistung. Nicht alle Components erreichen auch die höchste Entwicklungsstufe, aber sie entwickeln sich entlang der Achse in diese Richtung – freilich in unterschiedlicher Geschwindigkeit.

Nun haben wir alle Bausteine kennengelernt, um eine Karte einer bestimmten Landschaft zu zeichnen: Wir haben einen Bezugspunkt (Anchor) und können strategisch relevante Elemente (Component) relativ dazu positionieren (Value). Entfernungen zwischen den Elementen sind für uns unterscheidbar und bedeutsam (Evolution). Diese Karte können wir anderen zeigen, um über die Landschaft zu diskutieren. Der beste Weg, eine Map zu erstellen, ist, dies direkt in einer Gruppe zu tun, gemeinsam mit den jeweiligen Experten. Dabei ergeben sich wertvolle Diskussionen: „Warum ist das so weit unten?“, „Warum wird X weiter als Y entwickelt dargestellt?“, „Ist A wirklich Teil der Landschaft? Warum ist B nicht abgebildet? Wo ist C?“. Durch kritische Auseinandersetzung werden Annahmen hinterfragt und Erkenntnisse geteilt – ein gemeinsames Verständnis wird aufgebaut und weiter gefördert. Wer dabei an Domain-driven Design (DDD) und die Ubiquitous Language denkt, liegt genau richtig. Sobald wir ein gemeinsames Verständnis der Landschaft haben, können wir uns den Umgebungsbedingungen (Climate) widmen und diese ebenfalls in unsere Map übertragen.

Klimatische Einflüsse

Bodenwetterkarten enthalten neben der geografischen Abbildung der Landschaft weitere Informationen, etwa über Hoch- und Tiefdruckgebiete, Windverhältnisse, Niederschläge und Temperaturen. Die klimatischen Verhältnisse wirken auf die Landschaft ein und beeinflussen die geltenden Bedingungen. Je mehr relevante Details unsere Karte enthält, umso besser erkennen wir, dass der beste Weg von A nach B nicht zwangsläufig eine Gerade ist. Ein steiler Aufstieg an einer auf der Karte verzeichneten Felswand (Landscape) ist, je nach klimatischen Verhältnissen, anstrengend aber machbar, oder eben ein lebensgefährliches Wagnis. Dieser Informationsvorsprung ist entscheidend und stellt laut Simon Wardley den Unterscheid zwischen Maps und klassischen Methoden der Strategieplanung (siehe Kasten „Über die Methode“) dar.

Um eine erfolgreiche Strategie zu entwickeln, müssen wir uns explizit und ganz bewusst mit den Dingen beschäftigen, auf die wir keinen Einfluss haben. Während wir uns die Gegebenheiten der Landschaft zu Nutze machen und sie auch ein Stück weit verändern können, entziehen sich klimatische Einflüsse unserem Willen: Wir können sie nicht steuern, aber wir können sie entdecken und auch diese Erkenntnisse für uns vorteilhaft nutzen. Bewegungen an Märkten, strategische Entscheidungen von Wettbewerbern, technologischer oder gesellschaftlicher Wandel sind klimatische Einflüsse, die wir auf unseren Karten abbilden können und wollen.

_{Abb. 2: Wardley Maps mit klimatischen Einflüssen}

In Abbildung 2 werden klimatische Gegebenheiten genutzt, um eine Strategie zu entwerfen. App und zugehöriges Backend werden parallel vom gleichen Team entwickelt. Der gemeinsame Kontext wird durch die Umrandung sichtbar gemacht, da er für die strategische Entwicklung eine Rolle spielt. Beide Systeme sind noch in einem frühen experimentellen Status und nicht produktionsreif. Es müssen das UI optimiert und Performanceprobleme ausgeräumt werden, um eine positive Kundenerfahrung und somit Akzeptanz am Markt zu ermöglichen. Der rote Pfeil drückt die angestrebte Bewegung (Movement) entlang der Evolutionsachse aus. Die Software soll ihren experimentellen Charakter mit der Zeit verlieren und die Eigenschaften eines reifen Produkts erhalten. Die strategische Entscheidung wird zusammen mit der dafür zu nehmenden Hürde abgebildet: In unserem Fall mangelt es an Wissen und Kapazität, was als schwarzer Balken dargestellt wird. Der Balken beschreibt Inertia, die zu überwindende „Massenträgheit“. Nur wenn diese Hürde überwunden werden kann, ist der Weg frei für die Evolution von einer Eigenentwicklung (Custom Built) zu einem reifen und konkurrenzfähigen System mit Produktcharakter.

Cloud Computing ermöglicht nicht nur die Nutzung von SaaS, sondern auch alternative Betriebskonzepte für Eigenentwicklungen, was Einfluss auf die Bereitstellung hat. Der rote Pfeil beschreibt den Schritt weg vom rechenzentrumsbasierten Betrieb standardisierter VMs (Product) hin zu Container as a Service in einer Public Cloud (Commodity). Dieser Schritt ist jedoch nicht ohne Weiteres gangbar, denn auch hier existiert Inertia, also Widerstand durch eigene Trägheit. Das Know-how muss aufgebaut werden, Deployment und Betrieb erfordern neue infrastrukturelle Maßnahmen, die physische Anbindung zwischen Cloud und dem eigenen Haus muss ggf. neu dimensioniert werden. Sind diese Herausforderungen bewältigt, ergeben sich neue Möglichkeiten für andere Components auf der Map, sie können sich weiterentwickeln. Das Backend profitiert von der Umstellung auf containerbasierte Bereitstellung und kann cloudbasiert betrieben werden, sobald dieses Betriebsmodell zu einem späteren Zeitpunkt bereit ist. Die rote Linie beschreibt diese Verbindung der Components in der Zukunft. Dazu lohnt es sich, das Konzept der Evolution noch einmal genauer zu betrachten.

Evolution

Die Evolution beginnt mit dem Auftreten einer Component am linken Rand, der sogenannten Uncharted Domain (Abb. 3). Ihre Charakteristiken sind geprägt von Begriffen wie „experimentell“, „chaotisch“, „unzureichend verstanden“. Wir können schwer oder gar nicht vorhersehen, wie Dinge in der Uncharted Domain sich entwickeln werden. Daraus ergibt sich zum einen ihr hohes Potenzial in der Zukunft, aber auch ihr hohes Risiko durch eben diese Unsicherheit.

_{Abb. 3: Evolution von der Uncharted zur Industrialised Domain}

Je weiter eine Component sich entwickelt, umso mehr weicht die Unsicherheit der Gewissheit und es wird möglich, im industriellen Maßstab zu denken. Aus den ersten Laborversuchen mit transistorbasierten CPUs werden spezialisierte Kleinserien gefertigt, die später Produktreife erlangen und schließlich kostengünstig in Massenfertigungsprozessen in ausreichender Stückzahl produziert und für jeden erhältlich angeboten werden können. Je weiter wir uns auf der Map an den rechten Rand bewegen, umso mehr gelangen wir in die Industrialised Domain. Die Differenzierbarkeit zwischen verschiedenen Produkten nimmt ab, dafür sind diese wohl verstanden und lassen sich effizient her- und bereitstellen. Die Verfügbarkeit steigt rapide an, die Kosten pro Stück fallen. Je weiter entwickelt eine Component ist, umso eher kann sie die Ausgangsbasis für neue Entwicklungen sein, die dann ihrerseits wieder in der Uncharted Domain einsetzen. Aus kostengünstig in hoher Stückzahl gefertigten CPUs wurden Serverfarmen und wurde schließlich Cloud Computing, bei dem die Rechenleistung (nicht die Hardware) allgegenwärtig verfügbar ist. In unserem Beispiel ist die Evolution des Betriebsmodells vom eigenen Inhouse-Rechenzentrum hin zu cloudbasierten Containerdiensten die Basis für die technologische Weiterentwicklung des Backends. Das App-Experiment entwickelt sich zu einem reifen Produkt, je weiter es in die Industrialised Domain vorstößt.

Strategische Entscheidungen treffen

Bislang wurden die rein visuellen Eigenschaften von Wardley Maps besprochen. Mit Kenntnis der Landschaft und der Kräfte, die auf diese einwirken, können wir uns nun den strategischen Entscheidungsprozessen widmen. Kennen wir die Landschaft und die klimatischen Einflüsse, können wir individuelle Handlungen ableiten und universelle Prinzipien, die in jedem Kontext zutreffen, anwenden. Muster helfen uns dabei, diese zu erkennen und anzuwenden. Simon Wardley beschreibt dies mit den fortgeschrittenen Konzepten Doctrine und Leadership und gibt dem interessierten Leser Patternkataloge und Strategeme an die Hand, um eigene Strategien basierend auf Maps effektiver entwickeln zu können. Diese Konzepte sprengen den Rahmen dieses Artikels, sollen aber nicht gänzlich unerwähnt bleiben. Zusammen mit dem Konzept des Strategy Cycles bilden sie den wahren Kern des strategischen Mappings.

Um das zu verdeutlichen, wenden wir das gesammelte Wissen an und greifen das Pattern „No Single Method fits all“ heraus. Es besagt, dass es keine Methode gibt, die sich sinnvoll universell auf alle Components einer Map anwenden lässt. Beziehen wir das auf die unterschiedlichen Ansätze zur Softwareentwicklung und übertragen sie in das Konzept von Uncharted und Industrialised Domain, ergibt sich das Bild aus Abbildung 4.

_{Abb. 4: Verschiedene Methoden eignen sich je nach Evolutionsgrad besser}

Sowohl App als auch Backend befinden sich in der Uncharted Domain. Das bedeutet, dass mit häufigen Änderungen zu rechnen ist, sozusagen „by Design“. Dies ist eine wesentliche Eigenschaft von Components in der Genesis-Phase der Evolution und somit der Uncharted Domain. In diesem Fall bietet es sich an, mit agilen Methoden auf den steten Wandel zu reagieren, um die dadurch anfallenden Kosten unter Kontrolle zu behalten. Elemente am rechten Rand der Skala unterliegen diesem Wandel weniger stark. Ihre Charakteristiken sind wohl bekannt und somit kalkulierbar. Für Eigenentwicklungen, die es bis zu diesem Stadium schaffen, könnte (nicht muss!) Outsourcing eine Option sein. Das CRM ist beispielsweise von Anfang an als SaaS im Einsatz und keine individuelle Eigenentwicklung.

Fazit, Anwendungsmöglichkeiten und Ausblick

Wir haben die auffälligsten Merkmale von Wardley Maps angesprochen und anhand einfacher Beispiele verdeutlicht. Für fortgeschrittene Themen wie Doctrine, Gameplay und die Patternkataloge wird auf das frei verfügbare, unter CC-BY-SA lizensierte, Werk von Simon Wardley verwiesen, da dieser Artikel dafür nicht ausreichend Raum bieten kann [1], [2].

Die Entwicklung einer Map im Team kann im Rahmen eines Workshops stattfinden. Das Ergebnis kann leicht eine ganze Wand füllen. Entscheidend ist hier der nächste Schritt: Die Reduktion auf das Wesentliche, z. B. durch Aufspaltung einer Map in mehrere. Auf diesem Weg werden immer wieder neue Erkenntnisse über bestehende Annahmen gesammelt.

Im Kontext von DDD lassen sich Wardley Maps nutzen, um strategische Entscheidungen über Bounded Contexts zu treffen. Welche Veränderungen zeichnen sich ab? Welches Team und welche Methode eignen sich für welche Region der Karte? In welchen Bounded Context (nicht in welches System!) lohnen sich Investitionen, um neue Chancen nutzbar zu machen? Wardley Maps sind ein weiteres Werkzeug in unserer Designtoolbox, auf das wir im Bedarfsfall zugreifen können.

Auch wenn Wardley Maps ursprünglich für strategische Entscheidungen auf CEO-Level entwickelt wurden, können wir sie überall dort anwenden, wo wir uns ein Bild von komplexen Situationen verschaffen wollen, um fundierte Entscheidungen zu treffen. Das gilt für das strategische Architekturmanagement des Enterprise-Architekten ebenso wie für Projektleiter und System Owner, die eine vorausschauende (eben strategische) Planung betreiben wollen.

Abschließend lässt sich noch die Frage aufgreifen, ob es möglich ist, mit Wardley Maps komplexe Sachverhalte der realen Welt wirklich treffend darzustellen. Auch dazu gibt es ein mehr als treffendes Zitat von Simon Wardley: „All models are wrong but some are useful.“

Links & Literatur

[1] Ebook von Simon Wardley, frei verfügbar als Serie von Blogposts: https://medium.com/wardleymaps
[2] Projektseite mit Referenz und Artikeln für den Einstieg: https://learnwardleymapping.com/

The post Domain-driven Design: Strategisches Mapping mit Wardley Maps appeared first on JAX.