Anschub für IT-Modernisierung – Teil 3: Wie hilft Context Mapping, die Modernisierung erfolgreich aufzusetzen?

Im letzten, 2. Teil dieser Serie haben wir mit dem Kunden gemeinsam eine Context Map erstellt. In diesem 3. Teil der Serie geht es ins Detail: Das heißt, du erfährst, was uns die Inhalte der Context Map sagen wollen, und was die dort dokumentierten Abhängigkeiten und Kopplungen für unser Modernisierungsprojekt wertvoll macht.

Du steigst gerade erst ein? Hier kannst du Teil 1 und Teil 2 dieser Serie 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

Aber jetzt auf zu Teil 3!

Warum helfen Context Maps?

Wie in Teil 1 angesprochen gilt es, vor allem diese Herausforderungen im Kontext einer Modernisierung zu lösen:

• Die Modernisierung darf Pflege und Weiterbetrieb des Bestandssystems nicht über die Maßen behindern.
• Die Migration oder Neuentwicklung selbst darf aber auch nicht zu sehr behindert werden.
• Die Migration soll möglichst schnell wertschöpfend werden.
• Die Migration muss zügig vonstattengehen und organisatorisch skalieren.
• Die Migration lindert die dringendsten Probleme zuerst.
• Die Organisation des Modernisierungsprojektes muss „passend“ sein. Speziell sollte jedem Kontext ein Team zugeordnet werden.
• Das Team muss zum Kontext passen. D. h. es muss „fähig“ sein oder entsprechend „befähigt“ werden. Ebenso sollte das für den Kontext erforderliche Maß an Agilität zur Arbeitsweise des Teams passen.

Du kannst dir sicher vorstellen, wie wichtig Beziehungstypen und Kollaborationsmuster zwischen den Kontexten einer möglichen Neuentwicklung aber auch zum Bestandsystem und anderen umliegenden Systemen hierbei sind. Ihr Einfluss ist nicht zu unterschätzen, wenn es darum geht,  inwieweit und wie gut obige Ziele erreicht werden können!

Erfahrungsgemäß zeigt die Context Map anfänglich eher eine Lösung auf Basis der Ist-Organisation und deren Kommunikationsbeziehungen auf. Es wird eher versucht, die Modernisierung in das Bestehende zu integrieren oder bestehende Strukturen zu ergänzen.

Aus der resultierenden Context Map ist in Konsequenz erkennbar, wie dies auf die Migration wirken wird. Hier gilt Conway’s Law, das besagt, dass die bestehenden Kommunikationsbeziehungen die technische Struktur vorgeben. Hintergründe der initialen Modellierung sind dabei in der Regel Einschätzungen bzgl. Wirtschaftlichkeit („Alternative viel zu aufwändig“), gefühlte Komplexität („Puh, das wird sonst zu kompliziert”) oder eben die Ist-Organisation („an der Teamstruktur des Altsystems wollen wir nichts ändern“).

Ein Beispiel

Was aber, wenn beim Context Mapping mit obigen Ansätzen im Zuge einer Migrationsbetrachtung herauskommt, dass die Teams Schnittstellen zum Bestandssystem benötigen? Im Rahmen einer Migration ist das sicherlich nicht ungewöhnlich.

Allerdings wird diese Context Map in diesem Fall aufzeigen, dass die „Neu-Kontexte“ und damit deren Umsetzungsteams in mehr oder weniger starker organisatorischer Abhängigkeit zu den Teams des „Bestandssystems“ stehen. Hinweise wären hier „Downstream“, „Conformist“, „Partnership“ auf Seiten der „Neu-Kontexte“. Ebenso könnten entsprechende Modell-Abhängigkeiten sichtbar werden – erkennbar durch „Shared Kernel“ oder „Open-Host-System“.

Was heißt das für den Erfolg der Modernisierung?

Zu befürchten ist, dass so der Fortschritt der „Neu-Kontexte“ für die Modernisierung bei mangelnder Priorität, Zeit und Kapazität aufseiten des Bestandssystems durch dieses behindert wird. Die Modernisierung steht still, wenn die Teams des Bestandssystems diese nicht explizit ausreichend unterstützen. Es ist klar, dass dies nicht passieren darf!

Wie lässt sich das Problem lösen?

Wie so oft hilft der Blick über den Tellerrand: In der Regel sind die technischen und organisatorischen Abhängigkeiten zwischen den beteiligten Systemen, Teams und einzelnen Person sowie die System-Architektur die entscheidenden Faktoren. Diese sind daher bzgl. der Modernisierung zu optimieren und speziell initial identifizierte Constraints oder Entscheidungen zu hinterfragen. Kosten und Komplexität sind z.B. nicht für jeden Kontext einzeln, sondern über das Gesamtsystem und aus den Blick des Erfolgs des Modernisierungsprojektes zu betrachten.

Wenn die Organisation den Gesamtkontext begreift, kann sie Strukturen und bestimmte Patterns vorgeben. Auf diese Weise lassen sich Beziehungs- und Kommunikationsmuster ändern und sogar Einfluss auf die Architektur nehmen. Aber vor allem lassen sich organisatorische Ziele erreichbar gestalten.

Dies hat weitere Vorteile: Resultierende Architektur und Kommunikation wirkt im Sinne des „Inverse Conway Maneuvers” verstärkend und positiv. Das heißt, die Kommunikationsstruktur des Systems prägt die organisatorische Struktur.

Hierfür besitzt die Context Map die richtige Abstraktionsebene und die richtigen Inhalte und ist somit ein geeignetes Modell. Mit ihr können wir einfach die fachliche und technische, aber eben auch speziell die organisatorische Machbarkeit einer Migration  prüfen und frühzeitig Risiken zu erkennen und die Lösungsidee iterativ so anzupassen, dass sie nicht nur „passt“, sondern eben auch im Sinne der Migration tatsächlich „funktioniert“.

Wie bewerten wir die Abhängigkeiten?

Bevor wir sie bewerten, sollten wir uns die Frage stellen: Wie und warum entstehen Abhängigkeiten zwischen Teams, die sich dann auch entsprechend auf die gemeinsamen Schnittstellen auswirken?

Die Antwort lautet: Abhängigkeiten zwischen Kontexten und Teams entstehen durch eine entsprechende Kopplung. In folgender Tabelle zeige wir möglichen Arten der Kopplung auf.

Aus obiger Betrachtung und Argumentation heraus interessieren wir uns in diesem Schritt hauptsächlich für die organisatorische Kopplung, die in der Regel aus der Kopplung über die Domäne oder entsprechende Prozesse resultiert.

Leider geben die Muster nur bedingt Hinweise über Details wie Ursache und Maß der organisatorischen Kopplung. Mit „Upstream“ und „Downstream“ gibt es in Rahmen der Context Map eine weitere Modellierungsmöglichkeit. Allerdings gibt es hier mehrere abweichende bzw. unklare Definitionen:

Wir empfehlen daher zwar, mit Upstream und Downstream zu arbeiten, aber sich vorab entweder explizit auf eine der obigen Definitionen zu einigen oder eine alternative Definition zu nutzen.

Reichen Upstream und Downstream aus?

Upstream und Downstream sind aus unserer Sicht allerdings nicht ausreichend, um die Abhängigkeitsbeziehung weiter zu konkretisieren und zu bewerten und damit obige Fragestellungen zu klären. Bei Upstream und Downstream geht es ja um die Frage, von wo nach wo die Modelle Einfluss haben. Das kann mit organisatorischem Einfluss korrelieren, muss es aber nicht. Denn Upstream und Downstream können je nach Schnittstelle zwischen zwei Teams unterschiedlich verteilt sein, aber organisatorisch kann es zwischen Teams eigentlich nur eine Power-Beziehung geben.

Ein starker gestalterischer Einfluss (Upstream) kann sich z. B. aus folgenden Gründen ergeben – mit einem entsprechend unscharfen Mapping auf Upstream und Downstream:

Eine reine Sachebene gibt es nicht

Wir haben die Einflüsse, die wir im Rahmen der Modellierung auf der Sachebene für relevant halten, in der Tabelle mit einem Unterstrich markiert. Es handelt sich um die Einflüsse „Vertrag“, „Spezifikation“ und „Business Value“. Entscheidungen aufgrund der „Organisationstruktur” sind natürlich nicht grundsätzlich falsch, sie ignorieren aber die Tatsache, dass die Struktur ja änderbar ist.

Wir halten es im Rahmen einer Modernisierung außerdem für sinnvoll, „Termin” und „Innovation“ als weitere, temporäre Gründe heranzuziehen – im Bewusstsein, dass sich Schnittstellen und die Map hierbei später noch einmal ändern können.

Eine neutrale, gleichgewichtige Kopplung ergäbe sich nur, wenn rein auf der Sachebene diskutiert würde, sich beide Seiten in einer einfachen Win-Win-Situation befänden und obige Aspekte vollständig ausgeklammert werden könnten:

In der Realität gibt es über die Sachebene hinaus allerdings „Interessen“. Eine Context Map, die viele Schnittstellen mit dem Muster Partnership definiert, ist daher zu hinterfragen. Sie bildet oft eher einen frommen Wunsch  des Managements ab. Nach dem Motto: „die Teams werden sich schon sinnvoll einigen!“. Was mit hoher Wahrscheinlichkeit nicht der zukünftigen Projekt-Realität entspricht.

Für die faktisch aus den Durchsetzung der „Interessen“ entestehende „schwache“ Seite ergeben sich in der Regel nur noch folgende Optionen, Einfluss zu nehmen:

Veto und Widerstand

Hier möchten wir speziell auf die nicht-konstruktiven Verhaltensweisen „Veto“ und „Stiller Widerstand“ hinweisen, die in der Praxis nicht selten auftreten. Sollte man vermeiden! Aber wie?

Bei der Kommunikation innerhalb der Organisation ist „Wechsel“ vermutlich auch nicht realistisch und ein „Separate Ways“ wäre eher überraschend.

Daher empfehle ich beim Context Mapping, die jeweilige Beziehung – soweit wir sie schon kennen – über zusätzliche Eigenschaften expliziter zu erfassen. Denn damit können wir die reale oder modellierte Beziehung besser verstehen:

Für die nachfolgende dritte Sicht (nächster Artikel der Serie) kann es auch sinnvoll sein, folgende weitere Eigenschaften in einer ersten Einschätzung mit zu erfassen:

Wie geht es jetzt weiter?

In diesem Teil haben uns detailliert mit den Informationen befasst, die in der Context Map enthalten sind. Wir haben gelernt, wie und warum Abhängigkeiten entstehen können und erfahren, dass es wichtig ist, weitere Informationen über Schnittstellen zu erfassen. Grundsätzlich können wir festhalten, dass die Context Map und deren Bewertung und Anpassung ein entscheidender Baustein für den Erfolg unserer Migration sein können.

Im 4. und letzten Teil wollen wir uns Negativbeispiele ansehen, und damit eine weitere, finale Sicht auf die Context Map kennenlernen.

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 3: Erkennen, was wie voneinander abhängt – Wie hilft Context Mapping, die Modernisierung erfolgreich aufzusetzen?

Teil 4: Wie Sie Context Mapping nicht machen sollten … – Negativbeispiele und ihre Lösung