Anschub für IT-Modernisierung – Teil 4: Negativbeispiele und ihre Lösung
Ich hatte es versprochen: Nach den eher theoretischen Überlegungen des dritten Teils dieser Blogserie, präsentiere ich euch zum Abschluss ein paar Negativbeispiele. Damit nehmen wir einen weiteren Betrachtungswinkel ein, der uns hilft, IT-Modernisierung „gut“ anzugehen und aus Event Storming und Context Mapping das Maximale „herauszuholen“.
Du steigst gerade erst ein? Hier kannst du die vorangegangenen Teile dieser Blogserie nachlesen:
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
Nun aber weiter zu Teil 4:
Last Steps
Starten wir mit einem kurzen Recap: Im zweiten Teil dieser Blogserie ging es um die Bausteine des Context Mappings. Dabei wurde deutlich: Mit dem einfachen Erstellen der Context Map alleine ist es nicht getan! Den Weg, der notwendig ist, um Modernisierungsprojekte auch mittels Context Mapping anzuschieben, hatte ich in vier Schritten skizziert:
1. Schritt: Erstellung einer gemeinsamen, formal sauberen Context Map.
2. Schritt: Inhaltliche Korrektheit sicherstellen.
3. Schritt: Abhängigkeiten zwischen Kontexten bewerten.
4. Schritt: Im finalen Schritt die Context Map bezüglich struktureller Anti-Patterns bewerten.
Um den finalen vierten Schritt geht es in diesem Teil der Blogserie. Dafür schauen wir uns aus verschiedenen Blickwinkeln eine Reihe fiktiver Context Maps auf der Suche nach Anti-Patterns an. Bitte nicht wundern: Die Context Maps habe ich bzgl. der dargestellten Situation vereinfacht und überspitzt skizziert, damit das Anti-Pattern offensichtlicher wird.
Szenario: Angemessene Autonomie
Die zugrundeliegende Fragestellung ist: Hat der Kontext über die Summe seiner Schnittstellen ausreichend Autonomie, um sein Ziel und damit das allgemeine Migrationsziel zu erreichen? Um diese Frage zu klären, schauen wir uns ein Negativbeispiel an, das so auch im Rahmen einer Migration grundsätzlich vorkommen könnte:
Wir sehen hier, dass bei der Kommunikation mit „Bestandsystem_A“ eine bestehende Schnittstelle des Systems für den Datenaustausch genutzt wird. Bei „Bestandsystem_B“ wird kollaborativ („müssen wir uns gemeinsam anschauen“) eine neue Schnittstelle entstehen. Und hinter dem Shared Kernel mit „Bestandsysytem_C“ steht aus „historischen Gründen“ ein direkter Zugriff auf die Datenbank des Systems. Bei „Externes_System“ handelt es sich um einen Zugriff auf ein externes System, welches im Rahmen der Migration initial eingebunden werden soll.
Wie wir in diesem Beispiel sehen, ist unser „Neuer_Kontext“ bei allen Schnittstellen entweder Downstream – hat also eingeschränkten Gestaltungsspielraum – oder muss explizit stark mittels „Partnership“ und „Shared Kernel“ mit den Altsystemen kollaborieren.
Grundsätzlich bedingt eine Migration (oft auch schmerzhafte) Kompromisse, aber in dieser Konstellation ist zu befürchten, dass die zahlreichen technischen und organisatorischen Abhängigkeiten einen offensichtlichen negativen Einfluss auf den eigenen Projektfortschritt haben. Die neue Lösung kämpft mit zu vielen Altlasten und zusätzlich mit der Anbindung neuen Schnittstellen. Der Projekterfolg ist daher möglicherweise in Gefahr.
Mit diesen Optionen können wir das verhindern:
- Prüfung der Anpassbarkeit der Kollaboration, um einen sinnvollen und realistischen Zuwachs an Autonomie zu erreichen. Kann z. B. das Team „Neuer_Kontext“ die Schnittstelle zu „Bestandssystem_B“ selbst erstellen?
- Anpassung der Projektprioritäten und Timeline. So wird ggf. die Realisierung einiger Schnittstellen geschoben und stattdessen initial mit einem Mock und Testdaten gearbeitet.
Hier zeigt sich die Relevanz der Informationen aus dem Context Mapping für das Migrations-Setup und das Projekt-Management der Migration. Die Context Map macht es beispielsweise möglich, gemeinsam mit anderen Kriterien an der Tafel entsprechende Planspiele durchzuführen, auf der Grundlage guter, objektiver Bewertungskriterien.
Szenario: Akzeptabler Kommunikationsbedarf
Fragestellung: Ist der Kommunikationsbedarf für das verantwortliche Team noch zu handhaben? Hierzu ein weiteres fiktives Negativszenario:
In diesem Fall ist der Kontext „Neues_System_A“ Downstream eines externen Systems „Customer/Supplier“ und gleichzeitig selbst Upstream für ein „Externes_System_B“ ebenfalls „Customer/Supplier“. Es besitzt jeweils eine „Partnership“ zu zwei weiteren „eigenen“ Kontexten „Neues_System_B“ und „Neues_System_C„. Zusätzlich besteht noch eine „Shared-Kernel“-Beziehung zum „Bestandssystem“.
Das Bild lässt befürchten, dass der Kontext und das entsprechende Team mit der Koordination der Schnittstellen und den hier notwendigen Anpassungen ausgelastet oder möglicherweise sogar überlastet ist. – Speziell dann, wenn für die eigene Customer/Supplier-Schnittstelle weitere Customer hinzukommen. Vor meinem inneren Auge sehe ich Projektverantwortliche und Entwickler:innen von einem Abstimmungstermin zum nächsten laufen, um die Migration ans Laufen zu bekommen. Parallel versucht das Team vermutlich fieberhaft mit internen und externen Schnittstellenpartnern zu kollaborieren. Priorisierungskonflikte sind da vorprogrammiert.
Stellt sich wieder die Frage: Was können die Beteiligten tun, um ihren Kontext in den Griff zu bekommen?
Diese Optionen könnten helfen:
- Weiteres Zerlegen des Kontextes. Dieser könnte gegebenenfalls auf mehrere Teams verteilt werden.
- Anpassung der Kommunikationsmuster einzelner Schnittstellen.
- Anpassung von Prioritäten und Timeline.
- Trennen der Verantwortlichkeit für interne und externe Schnittstellenpartner. Dies kann zwischen den Verantwortlichen wiederum zu mehr Kommunikationsbedarf führen.
Szenario: Passende Schnittstellen
Fragestellung: Passen die Schnittstellen zu den aktuellen Herausforderungen meiner Organisation?
Die Abbildung zeigt ein „Batch_System„, das Daten aus einer bestimmten Quelle („Batch_Quelle„) verarbeitet und das Ergebnis – vermutlich eine Berechnung oder eine Transformation – an zwei nachfolgende Kontexte („Batch_Senke_1“ und „Batch_Senke_2„) weiterreicht.
Auf Grund eines „speziellen Wunsches“ – es könnte sich um ein spezifisches Kontroll- und Reporting-Bedürfnis des Managements, einen strategischen Wunsch der Fachseite oder den dringenden Wunsch eines wichtigen Kunden handeln – soll nun zusätzlich mit einer „High Traffic UI“ kommuniziert werden. Diese UI könnte z. B. die Visualisierung eines aktuellen Datenstandes im „Batch_System“ ermöglichen. Auf Grund des Termindrucks wird dabei das Team, welches die UI realisieren soll, als organisatorisch führend aufgehängt („Task Force“).
Unser neuer Kontext wäre damit Downstream (im Sinne des Datenflusses und der Kollaboration) seiner Datenquelle (fachliche Core-Domäne), sowie (organisatorisch) Downstream der „High Traffic UI“ und (zumindest Datenfluss-technisch) Upstream zweier Datensenken („Batch_Senke_1“ und „Batch_Senke_2„). Dabei fordert die „High Traffic UI“ einen hohen SLA. Dies würden wir über entsprechende Eigenschaftswerte im Rahmen des Context Mappings erfassen.
Herausforderungen gibt es auf mehreren Ebenen:
- Fachliche Ebene: Es gibt Potenzial für einen Zielkonflikt. Wäre beispielsweise die zeitnahe Abarbeitung des Batches wichtiger oder die Reaktivität der UI?
- Betriebsebene: Hier sehen wir uns mit zwei gegensätzlichen SLAs konfrontiert: Zum einen einem relativ entspannten SLA für das Batching mit hoher Laststabilität. Nur langsame Skalierung ist notwendig, kleinere Ausfallzeiten sind unkritisch. Auf der anderen Seite ein „hoch interaktiver“ SLA für das Frontend mit ggf. starken Lastschwankungen, dynamischer Skalierung, Near-Zero-Ausfallzeit etc.
- Technologische Ebene: Wir stehen vor technischen Herausforderungen, um die unterschiedlichen Anforderungen der beiden Upstream-Systeme in einem Service zu realisieren.
Letztendlich bedeutet diese Konstellation vermutlich, dass in der Umsetzung der technische Aufwand durch das Frontend getrieben wird, obwohl Batching eigentlich die führende Aufgabe ist. Das verantwortliche Team wird dadurch möglicherweise gezwungen, zeitnah nicht unerhebliche Änderung an seinem System durchzuführen. Es ist mit Qualitätsproblemen zu rechnen. Das Team für „High Traffic UI“ wird erheblich Druck ausüben. Konflikte sind vorprogrammiert. Die Ziele von „Batch_System“ und „High Traffic UI“ wären in Gefahr.
Zwei Optionen können hier weiterhelfen:
- Technisch entkoppeln: Zum Beispiel Zerlegung des Kontexts und Replikation der Daten, die für die UI relevant sind, über in einen zweiten Kontext. Dieser Kontext kann die Anfragen der UI über das Replikat lokal bedienen, auf Kosten der Aktualität der Daten.
- Anpassung von Prioritäten und SLAs. Klärung der Zielkonflikte.
Szenario: Transitivität
Auch Transitivität ist ein wichtiger Aspekt, wenn man holistischer auf die gesamte Context Map schaut. Nehmen wir dafür die folgende Context Map an, um zu sehen, wie man es nicht machen sollte:
„Service_A“ hat eine „Customer/Supplier“-Schnittstelle zu einem externen System. Da der Einfluss der Schnittstelle überschaubar ist, wurde auf einen „Anti-Corruption-Layer“ verzichtet. Gleichzeitig ist „Service_A“ aber ein „Open-Host-Service“ für „Service_B“ und dieser wiederum für „Service_C„, ohne dass diese sich mittels eines Anti-Corruption-Layer isolieren. Im Gegenteil: Die Modelle werden im Sinne des Conformist 1:1 übernommen. Damit ist zu befürchten, dass Teile des Modells von „Externes_System“ an alle anderen Kontexte weitergereicht werden.
Eine Änderung in der Schnittstelle zu „Externes_System“ oder ein Austausch des Schnittstellenpartners kann so zu notwendigen und aufwändig zu koordinierenden Anpassungen in allen Kontexten führen. Noch unangenehmer würde es, wenn „Service_A„, „Service_B“ und „Service_C“ nicht zum gleichen Bounded Context gehören würden und Teile des Modells von „Externes_System“ in eine andere Domäne diffundierten. Möglicherweise ist dieser Sachverhalt der anderen Domäne noch nicht einmal bewusst.
Was bleibt zu tun?
- Gerade an System- und Domänengrenzen muss sichergestellt werden, dass Modelle der Außenwelt oder einer anderen Domäne nicht ins 1:1 ins Innere weitergeleitet werden. Dafür wäre unter anderen ein Anti-Corruption-Layer auf Seiten des „Service_A“ sinnvoll.
- Das Weiterreichen von Modellen muss für die komplette Context Map geprüft werden. Transitive Strecken über mehr als zwei Kontexte sind zu prüfen und im Zweifel durch entsprechende Anpassungen und die Einführung eines Anti-Corruption-Layers zu unterbinden.
Zusammenfassung
Hoffentlich konnte ich mit meinen Beschreibungen, Erklärungen und Beispielen zeigen, wie mächtig die Kombination aus Event Storming, Context Exploration und Definition, Glossar und Context Mapping sind. Wenn ich zumindest andeute konnte, wie dieser Handwerkskasten helfen kann, in Modernisierungsprojekten schnell wichtige Klärungen herbeizuführen und damit konkrete Migrationsschritte vorzubereiten, wäre für mich persönlich schon ein wichtiges Ziel erreicht.
Aus meiner Sicht ist obige Kombination der perfekte „Knotenlöser“ für lange Diskussionen und Abstimmungsmeetings!
Hierzu die wichtigsten Argumente nochmals auf einen Blick:
- Event Storming ist nicht nur eine leichtgewichtige Methode, um sich explorativ die Zielkontexte und Zielprozesse des modernisierten oder gar neuen Systems zu erarbeiten. Die Methode zwingt die Beteiligten auch, einen Konsens bezogen auf Vision, Geschäft und Arbeitsweise zu schließen. Es liefert die relevante Fachbegriffe für ein Glossar und damit erste Bausteine für eine bessere Verständigung über eine gemeinsamen domänen-spezifischen Sprache.
- Mit dem Ausfüllen der Context Description während oder nach dem Big Picture Event Storming erreichen wir eine gemeinsame Definition der Aufgaben des Kontextes. Diese führt zu einer gemeinsamen Einschätzung des Wertbeitrags des Kontextes und seiner strategischen Bedeutung und liefert wichtige Informationen für die folgende Erstellung der Context Map.
- Über die Bewertung der Schnittstellen der einzelnen Kontexte entsteht mithilfe der Context Map ein Modell der fachlichen und technischen Kommunikation im jeweiligen System. Daraus kann auch ein Bild entstehen über die organisatorische Kommunikation, die im Projekt zwischen den Teams notwendig wäre. So wird es möglich, die organisatorischen, technischen und fachlichen Ebenen in Einklang zu bringen – dies effizient durch entsprechende Anpassungen an Context Map und Planung. Ein besonders wichtiger Punkt in Modernisierungsprojekten!
- Gemeinsamkeit und Konsens führen unterm Strich zu Ergebnissen, die belastbar und robust sind. Die Folge sind Risikoreduzierung und Sicherheit.
- Zu guter Letzt können die leichtgewichtigen Modelle und Modellierungsansätze auch im weiteren Projektverlauf herangezogen werden, um zusammen an Wand, Tafel oder Board über Details zu sprechend und Anpassungen zu diskutieren.
So ist Event Storming – wie Anfangs versprochen – nicht nur Zettel kleben, die Context Definition nicht nur ein Formular, das Glossar nicht nur eine Verstichwortung und die Context Map keine statische Abbildung technischer Schnittstellen.
Ich hoffe, ich konnte euch überzeugen!? Welche Erfahrungen habt ihr gemacht? Ich freue mich auf weitere Diskussion!
* Die Context Map Diagramme wurden mit den Visual Studio Code Plugin für ContextMapper erstellt. Mehr zu ContextMapper findest du unter https://contextmapper.org
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
