Anschub für IT-Modernisierung – Teil 2: Context Mapping und seine Bausteine
Im ersten Teil Mehr als eine Wand voll Post-its – Wie Event Storming & Co das Neue beflügeln haben wir verstanden, dass es mehrere Varianten von Event Storming mit unterschiedlichen Zielrichtungen gibt. Wir haben erklärt, warum die Ergebnisse des Event Stormings für Migrationen so wertvoll sind. Dann haben wir noch gezeigt, warum wir parallel ein Glossar einführen und auch eine Context Description erstellen.
Man mag versucht sein, nun gleich in Architekturfragestellungen abzutauchen oder gar die Entwicklung zu starten. Aber …
Halt, einen habe ich noch!
Bevor wir nun für jeden unserer identifizierten Kontexte in die Architekturkonzeption oder gar direkt in die Entwicklung gehen – und dabei vielleicht noch “Microservices” mit einer gewissen Euphorie im Gesicht murmeln –, sind aus meiner Sicht noch Fragen offen und damit auch weitere Todos und Arbeitsschritte.
Blenden wir kurz die Euphorie über ein mögliches „neues System“ aus, dann sehen wir immer noch eine bereits bestehende Applikation, die wir nicht mehr oder weniger ungepflegt weiterlaufen lassen können, während man mehrere Jahre parallel eine neue Lösung entwickelt.
In der Praxis sind die eigenen Entwickler mit aller Kraft beschäftigt, dass Altsystem (noch) am Leben zu erhalten und das Management kann und will eine Modernisierung bzw. Neuentwicklung, nur finanzieren, wenn diese möglichst schnell wertschöpfend ist, was ebenfalls verständlich ist.
Dieses Dilemma lässt sich nur auflösen, wenn wir uns intensiv Gedanken über eine Migrationsstrategie machen:
- Wie löse ich Teile aus der Bestandsapplikation raus, wie verknüpfe ich die neuen Teile mit der bestehenden Funktionalität der Altapplikation?
- Muss ich ggf. erst sogar Teile der Altapplikation verbessern, bevor ich sie dann neu realisieren und ablösen kann?
- Wo fange ich an, damit das Management schnell auch fachliche und wirtschaftliche Erfolge sieht?
- Wie sieht meine Zielarchitektur aus?
- Wie bekomme ich das Vorhaben überhaupt organisatorisch gestemmt?
Das sind Fragen, die wir uns stellen sollten.
Natürlich soll es möglichst schnell gehen – denn eine Migration bedeutet Stress für die ganze Organisation. Daher wollen wir vermutlich mit mehreren Teams parallel an verschiedenen Kontexten arbeiten. Aber welche Teams? Wie groß sollten sie sein? Und wie schaffe ich es, dass zwei Teams in der Praxis tatsächlich doppelt so viel Arbeit schaffen, wie ein Team – statt andauernd aufeinander zu warten oder gemeinsam in Meetings sitzen?
Die Lösung heißt Context Mapping.
Was macht Context Mapping?
Um die Fragen zu beantworten und die oben genannten Entscheidungen treffen zu können, brauchen wir mehr Fakten. Deshalb empfehle ich den Kunden, mit denen ich zusammenarbeite, im Anschluss an das Event Storming mit einem Context Mapping Workshop weiter zu machen.
In diesem Workshop geht es um zwei wesentliche Fragestellungen:
- Wie beeinflussen sich Modelle?
- Wie kommunizieren Teams?
Im DDD bezeichnet ein Bounded Context den Geltungsbereich eines Modells, also der Begriffe und Regeln. Aber innerhalb einer Organisation und in einem System wird ein einzelner Bounded Context selten isoliert existieren. Er hat Schnittstellen zu anderen Systemen und Kontexten. Und der Name verrät es: Eine Schnittstelle „schneidet“ und verletzt damit eine Grenze. Wie bei einem Schnitt in den Daumen, entsteht eine Wunde. Ich könnte es so sagen: Entweder blutet etwas heraus (in dem Fall aus dem Modell) oder aber es dringen Schmutz und Bakterien in die offene Stelle.
Zurück zur Methode: Beim Context Mapping geht es darum, zu identifizieren, welchen Einfluss das Modell eines Kontexts auf andere hat.
Wir gehen an dieser Stelle davon aus, dass die Methode Context Mapping sowie die zugehörigen Muster grundsätzlich bekannt sind. Für das Verständnis des Textes wiederholen wir hier aber dennoch kurz die gängigen Kollaborationsmuster:
Daneben werden noch folgende Beziehungsformen definiert, von den „Upstream/Downstream“ am häufigsten explizit modelliert wird:
Daneben werden noch folgende Beziehungsformen definiert, von den „Upstream/Downstream“ am häufigsten explizit modelliert wird:
Context Mapping ist bei der IT-Modernisierung nur der erste Schritt
Im Kontext von Modernisierungsprojekten reicht es nicht, den Context Mapping Workshop zu machen und gut. Hier müssen weitere Schritte folgen. Meiner Idee nach wären es insgesamt diese vier:
- Context-Mapping durchführen (Schritt 1)
- Das Ergebnis formal auswerten
- Schnittstellen validieren und ggf. noch einmal ändern
- Weitere Erkenntnisse bzgl. der Struktur der Lösung, der Reihenfolge der Migrationsschritte, sowie möglicher Organisationsstrukturen gewinnen
Schritt 1: Durchführung Context Mapping
Das Context Mapping wird, wie allgemein dokumentiert (zum Einstieg siehe DDD-Crew), durchgeführt. Man betrachtet die ein- und ausgehenden Schnittstellen jeweils eines Kontextes (diese hat man ja im vorherigem Event Storming identifiziert) und weist den jeweiligen Schnittstellen und Schnittstellenpartnern die entsprechenden Beziehungsformen und Patterns zu.
Im Modernisierungskontext ist hierbei zu klären, inwieweit die finale Zielarchitektur oder nur die ersten Modernisierungsschritte betrachtet werden sollen. Ich empfehle im Rahmen der Modernisierung auf jeden Fall ein Mapping mit dem Scope der ersten Migrationsschritte durchzuführen.
Input für das Mappings sind dabei:
- Der Einfluss, den der jeweilige Kontext auf die Schnittstelle hat. Auch hier können Organisationsstrukturen, Business-Treiber vs. Commodity, Vertragssituation o.ä. relevant werden. Das Maß an fachlich nötiger Kopplung wird so pro Schnittstelle bestimmt.
- Die technische Form der Schnittstelle, wenn z. B. durch ein externes System bereits vorgegeben.
In Summe ist das Ergebnis des Mapping dabei eine “Map”, die Kontexte, Schnittstellen, sowie Kommunikationsmuster und Beziehungstypen zwischen den Schnittstellenpartnern identifiziert. Die Muster geben also entweder (verschiedene) Namen für die jeweiligen Beziehungsseiten vor oder „nur“ einen Namen für die „Beziehung“ an sich an.
Hinweis: Beim Konsolidieren der Information pro Kontext in die Map bitte immer abgleichen und sicherstellen, dass die Eigenschaften einer Schnittstelle über alle beteiligten Kontexte konsistent ist.
Damit ist das Mapping formal abgeschlossen. Tatsächlich hat das Mapping aber weitere Ebenen, die im Kontext eines ggf. stattfindenden Folgeworkshops mitberücksichtigt werden sollten.
Schritt 2: Formale Konsistenz zwischen den gewählten Mustern herstellen
Leider ist es nicht so, dass alle Muster konzeptionell gleichwertig nutzbar sind und in beliebiger Kombination eingesetzt werden können. Die Muster sind ursprünglich meist aus der konkreten Beobachtung entstanden. Deshalb folgen sie keinem systematischen Ansatz. Einige definieren beide Beziehungsseiten (Partnership, Customer/Supplier, Shared-Kernel, Published Language), einige nur die Beziehung für eine Seite (Conformist, Open-Horst-Service) und andere sind additiv (Anticorruption-Layer). Dieser systemische Mangel hat mich lange gestört, eine Bereinigung hat sich aber als nicht trivial herausgestellt 😉
Beispiele:
- Conformist und Anticorruption Layer an einer Beziehung machen wenig Sinn, da die Intentionen beider Seiten immer widersprüchlich sein werden. Beim Conformist wollen wir aus verschiedenen Gründen das Modell übernehmen, beim Anticorruption Layer wollen wir unser eigenes Modell schützen und auf keinen Fall das Schnittstellenmodell nutzen.
- Beide Seiten einer Schnittstelle können nicht Downstream
Mehr Struktur und Systematik bekommen wir, wenn wir die Schnittstellen nach verschiedenen Kriterien kategorisieren. So lassen sich auch Regeln aufbauen, die dabei helfen, die Sinnhaftigkeit und Umsetzbarkeit der Map weiter zu überprüfen.
Tabelle 3 zeigt, einen Anfang dafür. Sie zeigt die Betrachtung des Kriteriums der (logischen) Kardinalität der Kommunikationspartner. Da es um die Anzahl der Kommunikationspartner geht, wurde Separate Ways hier weggelassen:
Wir sehen, dass Open-Host-Service, Conformist, Shared-Kernel, Supplier und Partner keine höheren Kardinalitäten erlauben oder diese zumindest wenig sinnvoll sind. Ebenso ist Customer/Supplier zu hinterfragen, wenn auf Dauer genau ein Customer existiert.
Das nächste Kriterium wäre “Kontrolle”. Welche Muster machen Sinn, wenn wir in einem bestimmten Maß Einfluss auf die Schnittstelle und den Schnittstellenpartner haben. Teilweise Einfluss entspräche dabei in der Regel dem Beziehungstyp Mutually Dependent, während andernfalls eine Upstream/Downstream Beziehung vorliegt.
Ein Anticorruption Layer kommt in der Praxis eher auf der Kommunikationsseite vor, die entweder keinen Einfluss oder nur teilweise Einfluss hat.
Dies führt zu folgender Tabelle:
Hinweis: In den obigen Tabellen habe ich die semantischen Regeln von Context Mapper berücksichtigt, siehe hierzu auch https://ContextMapper.org. Context Mapper erlaubt eine Modellierung von Kontexten und Beziehung mittels einer Domain-specific Language (DSL) und realisieren darüber hinaus entsprechende Prüfungen.
In der Praxis begegnen wir meist folgenden gängigen Kombinationen:
Wie geht es jetzt weiter?
Gut, jetzt haben wir eine Context Map und damit noch mehr über unser System gelernt. Können wir dann jetzt … Microservices? Nein! Aber wir können mit Schritt 3 und 4 aus den gesammelten Informationen noch mehr für unser Modernisierungsprojekt herausziehen.
Mehr dazu in Teil 3 …
Die ganze Serie lesen:
Teil 1: Mehr als eine Wand voll Post-its – Wie Event Storming & Co das Neue beflügeln
Teil 2: Die Teile dahin legen, wo sie passen könnten – Context Mapping und seine Bausteine
Teil 4: Wie Sie Context Mapping nicht machen sollten … – Negativbeispiele und ihre Lösung
