Architekturrolle im Wandel

Viele Organisationen richten ihre Wertschöpfung auf „Digitale Services“ oder „Digitale Ökosysteme“ aus und starten damit eine langfristig angelegte Reise (=Digitale Transformation). Die Ausrichtung der Geschäftsstrategie ist in diesem Kontext – zum Beispiel auch wegen der Kopplung zu vom Kunden erwünschten Innovationen im Technologieumfeld – zunehmend von den Attributen Volatilität, Unsicherheit, Mehrdeutigkeit und Komplexität betroffen (vgl. [Wiki-VUCA]). Mehr Kollaboration zwischen Menschen mit verschiedenen Sichtweisen, Ideen und Erfahrungswerten aus technischen und fachlichen Disziplinen steigert in diesen komplexen Umgebungen die Chance auf aussichtsreiche Lösungswege. Eine enge Zusammenarbeit an strategischen Zielen ermöglicht häufig eine schnellere Reaktionszeit bei iterativen Nachjustierungen (systemische Schleifen) und verteilt die damit einhergehende Verantwortung auf mehrere Schultern. Architekturverantwortliche spielen in diesem Kollektiv eine zunehmend wichtige Rolle als Facilitator und Übersetzer, um gemeinsam mit Product-Ownern, disziplinarischen Führungskräften, strategischen Managementrollen, Querschnittsfunktionen und den häufig interdisziplinären Product-Teams die richtigen zukunftsweisenden Experimente zu definieren.

Klassische Architekturarbeit als Fundament

Wenn man sich an der gegenwärtigen Architekturlehre und beispielsweise auch an Bausteinen des Standards arc42 (vgl.[ARC42]) orientiert, dann bestehen die klassischen Aufgaben aus:

• Kommunikation mit Stakeholdern und Dokumentation der Zielsetzung,
• Beschreibung des Problem-Lösungsraums unter anderem durch Beschreibung von Systembestandteilen (Komponenten) und deren Abhängigkeiten zueinander,
• Ableitung von Architekturmaßnahmen zur Erreichung von nicht-funktionalen Qualitätszielen in softwarebasierten Systemen,
• Beweis der gesamten Architekturvision und der Qualitäten durch messbare Szenarien und aussagekräftige Experimente,
• Management der technischen Hypotheken und Risiken.

Der Architekt als Facilitator im Transformationskontext

• Die Architekturarbeit im Transformations- und Modernisierungskontext hat neue beziehungsweise zusätzliche Aspekte im Sichtfeld. In Organisationen mit zunehmend digitalen Wertschöpfungsketten ist häufig ein bewusster Umgang mit den Erkenntnissen aus Conways Gesetz (vgl. [Wiki-Conw]) und die Umsetzung strategischer Domain-Driven Design (DDD)-Maßnahmen äußerst hilfreich, um realitätsnahe Modelle für Veränderungsexperimente abzuleiten. Als Konsequenz daraus wirken Architekturmaßnahmen sehr häufig auf viele Aufgabenbereiche der klassischen Führung einer Organisation ein. Exemplarisch folgt eine Auflistung von zusätzlichen Handlungsfeldern, in denen Architekturverantwortliche in einer aktiven Rolle bei der Identifikation von Veränderungsmaßnahmen in der Organisation beteiligt sind:
  
• Strategisches Design von Systemen nach DDD mit Auswirkung auf die Organisation und Prozesse,
• Strategischer Portfoliowandel und Ableitung von Evolutionsmaßnahmen,
• Optimierung der Ablauforganisation und Aufbauorganisation auf nichtfunktionale Anforderungen von digitalen Services,
• Bestimmung von Personalbedarf, Personalstrategie und Definition von benötigten Kompetenzprofilen,
• Begleitung des Kulturwandels hinsichtlich End-to-End-Verantwortung von Product-Teams,
• Unterstützung der Führungs- und Querschnittsbereiche beim Auflösen von prozessbedingten Flaschenhälsen,
• Evolution der Architektur auf Basis sich stetig ändernder Ziele und Rahmenbedingungen.

Das Spielbrett in einer digitalen Transformation

Das Spielbrett in einer Transformation hat also viele Facetten (siehe Abbildung 1). Um an diesem großen Spieltisch einen Beitrag leisten zu können, werden daher nachvollziehbare Handlungsempfehlungen für alle Stakeholder benötigt. Die Handlungsempfehlungen eines Architekten sind häufig beeinflusst durch den Wunsch der Vermeidung von technischen Hypotheken. Dieses Ziel steht aber oft im Konflikt mit organisatorischen Vermächtnissen und (Alt-)Lasten, wie erodierte Mitarbeiterkompetenzen, mangelndes Budget, fehlende Zeit, Abhängigkeit von Lieferanten, niedrige Erfolgsraten in der Personalbeschaffung, fehlende Strategien und Taktiken, Doppelbelastung der Mitarbeiter durch Neu-/Bestandswelt usw. Diese organisatorischen Hypotheken führen häufig zu technischen Hypotheken im Architekturzielbild. Architekturverantwortliche müssen im Transformationsalltag einen Beitrag leisten, um diese beiden Schuldenkategorien gemeinsam mit anderen Führungskräften in Balance zu halten beziehungsweise stetig abzubauen.

Kollaboration mit Spaß = „Spielen“

In diesem Artikel möchte ich Wege zeigen, wie man interdisziplinär, spielerisch und kollaborativ an diesen Fragestellungen arbeiten und als Softwarearchitekt wertvoll zur Entscheidungsfindung beitragen kann. In meiner Herkunftsregion nennen wir diese Form der Kollaboration „auskarteln“ (angelehnt an „gemeinsam Karten spielen“). Während vieler Transformationsprojekte hat sich bei mir allerdings der Begriff „Gläserrücken“ (auch „Ouija“ genannt; vgl. [WIKI-Gl]) etabliert. Hierbei handelt es sich um ein Spiel, bei dem mehrere Teilnehmer eine Hand an einem Glas auf einem Spielbrett mit Buchstaben platzieren. Durch die Dynamik der Gruppe – und diverse psychologische Effekte – entstehen Wörter und Antworten auf Fragestellungen, ohne dass die Bewegung des Glases einzelnen Individuen zugeordnet werden kann. Ich persönlich bin seit langer Zeit immer auf der Suche nach neuen Methoden, die sowohl kollaborative als auch iterativ/ inkrementelle Elemente haben und sich im Alltag ähnlich anfühlen wie „Gläserrücken“. Lust zu spielen? Dann sehen wir uns im Folgenden ein paar dieser Methoden an!

Strategisches DDD mit Event Storming

Event Storming ist eine kollaborative Methodik von Alberto Brandolini [Bra] zur Erfassung und Optimierung von Prozessen. Der Lernprozess steht hier im Vordergrund. Die analysierten und reflektierten Prozesse sind in der Regel:

• interne Abläufe zwischen Organisationseinheiten sowie
• digitalisierte Geschäftsprozesse in softwarebasierten Systemen.

Das Ziel von Event Storming ist vorrangig, dass Menschen mit unterschiedlichen Perspektiven während eines Prozesses aufeinandertreffen und sich ein Modell der Realität erarbeiten. Menschen mit fachlichem Hintergrund und Silowissen treffen gegebenenfalls auf Techniker. Im Vordergrund stehen die Ziele:

• Reihenfolge der Abläufe und Zusammenhänge verstehen,
• gemeinsame Sprache identifizieren (z. B. für ein Glossar),
• Unklarheiten eliminieren.

Nach der Erschließung der Abläufe in zeitlicher Abfolge ist es relativ einfach, durch Auflösung des linearen Zeitstrahls und Gruppierung nach Bounded Contexts ein modulares System inklusive User Interfaces, synchroner und asynchroner Schnittstellen (Event-Driven Architecture) sowie benötigter externer Systeme zu erarbeiten. Oder kurz gesagt: Ein Entwurf für ein rein fachlich getriebenes Architekturmodell, das gegebenenfalls in späteren Schritten in Anlehnung an technische, organisatorische und prozessuale Stolpersteine weiterentwickelt werden kann. Die Erkenntnisse aus einer Event Storming Session sind auch ein guter Startpunkt für die Erstellung eines Glossars. Tatsächlich hat sich Event Storming allerdings auch fernab vom Thema „DDD“ als hilfreich erwiesen, um Abläufe zwischen Organisationseinheiten zu analysieren, Klarheit über kritische Prozessschritte, zyklische Abläufe, Upstream/ Downstream-Abhängigkeiten und Flaschenhälse zu bekommen beziehungsweise Optimierungsmaßnahmen abzuleiten. In der Praxis verwende ich Event Storming um ein Vielfaches häufiger für kollaborative Prozess-Analysen und verhältnismäßig selten für Systementwürfe (Anmerkung: Wie oft hat man schon den Luxus, auf der grünen Wiese beginnen zu dürfen, im Vergleich zum Wunsch, Alltagsprobleme aus dem Weg zu räumen?).

Critical to Quality Tree

CTQ ist ein Ansatz, wie man Qualitätsziele eines Systems in einer Baumstruktur beschreibt, greifbare und messbare Qualitätsszenarien definiert und davon nachvollziehbare und logische Maßnahmen ableitet. Die Ergebnisse aus einem Event Storming oder anderen an DDD orientierten Vorgehensmodellen haben sich in der Praxis als ideale „Eingabeparameter“ für dieses Spiel erwiesen. Der Ablauf dieser Methodik ist relativ einfach zu beschreiben:

• Zuerst werden die 5 bis 7 wichtigsten Qualitätsziele herausgearbeitet. Beispielsweise Begriffe aus ISO 9126 oder ISO 25000.
• Nachdem die primären Qualitätsziele vereinbart sind, leitet man von jedem Ziel entsprechende Szenarien in einer Baumstruktur ab.
• Für jedes Szenario wird eine Sammlung von Maßnahmen definiert, die ergriffen werden sollen, um die Metriken im Szenario zu erfüllen.

Abbildung 3 zeigt ein Beispiel mit einer ausgearbeiteten Qualitätsanforderung bezüglich „Elastizität“ eines Dienstes. Das Qualitätsziel wurde dort anhand zweier Szenarien messbar gemacht (z. B. Zeitfenster von 30 Sekunden für eine Laststeigerung durch Anfragen von „5 pro Sekunde“ auf „100000 pro Sekunde“) und es wurden konkrete Maßnahmen abgeleitet (Cloud-Infrastruktur, Caching, Horizontal Autoscaling). Mithilfe von automatisierten Tests (z. B. Architectural Fitness Functions und Lasttests) kann nun zum Beispiel auf einer Test-Umgebung vor jedem Produktiv-Deployment geprüft werden, ob die Qualität auch nach einer Änderung am System weiterhin erreicht werden kann. Entsprechende Metriken und Alerts in Monitoring-Werkzeugen sollten ebenfalls diese Szenarien abbilden.

Wardley Mapping

Wardley Mapping ist ein Ansatz, um eine Geschäftsstrategie und taktische Maßnahmen zur Evolution einzelner Geschäftsfähigkeiten oder ganzer Zusammenhänge zu beschreiben. Alle Maßnahmen werden dabei mithilfe von aktuellen oder zukünftig erwarteten Kundenwünschen hergeleitet. Einen guten Einstieg in diese Methodik findet man unter [Leawm].

Abbildung 4 zeigt beispielhaft eine Wardley Map. Der Vorgang zur Erstellung kann ebenfalls iterativ/inkrementell durchgeführt werden. Im Folgenden wird eine stark vereinfachte Reihenfolge der Schritte beschrieben:
1. Verknüpfung der Kunden und Kundenwünsche (=Needs) mit Top-Level-Fähigkeiten (=Capabilities) der Organisation,
2. Identifizierung von Abhängigkeiten zwischen den Fähigkeiten und Bewertung der einzelnen Fähigkeiten bezüglich Sichtbarkeit beim Kunden/Konsumenten innerhalb der Wertschöpfungskette (vertikal, z. B. vom User Interface bis runter zur Steckdose im Rechenzentrum),
3. Kategorisierung der Fähigkeiten in Reifegrade (horizontal eingeteilt in die Reifegrade Genesis, Custom Built, Product, Commodity/Industrialized),
4. Verbesserung einzelner Fähigkeiten (siehe Abbildung 4: roter Pfeil) in Anlehnung an den Reifegrad des Kundenwunsches durch Identifikation von Barrieren (siehe Abbildung 4: schwarzer Block) und notwendigen Evolutionsmaßnahmen.

Man erahnt vielleicht bereits, dass ein strategischer DDD-Entwurf inklusive Informationen aus einer Kontextabgrenzung der ideale Input für diese Methodik ist. Auch eine Diskussion über „Core Domains“, „Supporting Domains“ und „Generic Domains“ aus DDD ist ein guter Startpunkt für Outsourcing- und Modernisierungsmaßnahmen.
Fähigkeiten im Quadranten links oben von Abbildung 4 sind in der Wertschöpfung beim Konsumenten stark sichtbar, meist wettbewerbsrelevant und einem sich stetig ändernden Kundenwunsch unterworfen. In der Regel ist es sinnvoll, möglichst viele seiner eigenen Mitarbeiter hier zu bündeln und mit einem agilen Mindset und Endto-End-Verantwortung überzeugende Services für den Endkunden zu realisieren. Hier finden in der Regel auch die meisten Maßnahmen bezüglich Transformation, Kulturwandel, Employer-Branding, Fortbildungsmaßnahmen, Recruiting, organisatorische Bündelung usw. statt.
Fähigkeiten in der rechten Hälfte lassen sich gegebenenfalls schon durch Standardlösungen ersetzen beziehungsweise vollständig mit entsprechenden SLAs an Dienstleister, Cloud-Anbieter oder diverse Service-Provider (z. B. über externe APIs) auslagern, während man Fähigkeiten in der linken Hälfte in der Regel aufgrund fehlender Standardlösungen selbst verantworten muss (abhängig von der Sichtbarkeit/Werthaltigkeit beim Konsumenten meist durch Inhouse-Entwicklung oder mithilfe von Softwarelieferanten). Eine Wardley Mapping-Sitzung erzeugt ein kollektives Verständnis am Strategiespieltisch bezüglich notwendiger Taktiken, Roadmaps und Visionen, die auch die Entwicklung der Teil- beziehungsweise Gesamtorganisation betreffen. Die hier identifizierten Maßnahmen sind vielfältig und betreffen Bereiche wie Personalstrategie, Kulturwandel, technologische Modernisierung, Kompetenzentwicklung und sogar Outsourcing-Strategien.

Team Topologies

Wie gelingt der Sprung von modularen Systementwürfen, Qualitätsmaßnahmen und strategischen Evolutionsplanungen zu tatsächlichen Teamstrukturen und Interaktionsmodellen in der Organisation? Man könnte sich nun an Erfolgsgeschichten von Netflix und Spotify orientieren und Cargo-Kult betreiben, oder sich tatsächlich auch wieder methodisch im Kollektiv darüber Gedanken machen, welche Aufgabenstellungen man in einem Team bewusst sehen oder nicht sehen möchte, wie groß die Teams sind und in welcher Art und Kopplungsweise sie miteinander interagieren.

Dank der Autoren Matthew Skelton und Manuel Pais (beide sind seit Langem in der DevOps-Community mit ihren Schaubildern bezüglich DevOps-Patterns und -Antipatterns bekannt) gibt es mit „Team Topologies“ [SkPa19] nun sowohl eine Lektüre als auch einen einfach anwendbaren Baukasten, um sich Gedanken über die Organisation (inkl. Interaktionsmuster) zu machen.
Ergebnisse aus vorangegangen Event Storming Sessions (DDD/interne Prozesse) sind ein guter Startpunkt, um den Ist-Zustand zu skizzieren. Team Topologies ermöglicht einen Zoom in die Soll-Perspektive beziehungsweise in diverse Zwischenstufen.
Im Kontext von Team Topologies überlegt man sich, welche vom eigentlichen Ziel ablenkenden Aufgabenstellungen (im Sinne extern beeinflusster, ablenkender kognitiver Belastungsfaktoren) man zum Wohle der wertstromorientierten Teams (Value Streams) an zentrale Plattformteams, Enabling-Teams oder Complicated-Subsystem-Teams auslagern sollte. Forschungsergebnisse zum Thema „kognitive Belastung“ (intrinsisch, irrelevant, relevant) spielen in dieser Methodik eine essenzielle Rolle.
Gleichzeitig wird in dieser Methodik auch diskutiert, welche nicht alltäglichen Enabling-Tätigkeiten zur Unterstützung der wertstromorientierten Teams notwendig sind. Vor allem belastend ist beispielsweise das Erlernen neuer Technologien oder die Integration in komplexe IT-Prozesse.
Enabling Teams (oder Communities) sind hierfür gegebenenfalls die passende Antwort, um zum Beispiel interdisziplinäre Generalisten-Teams (T-Shaped Professionals) zu unterstützen. Neben der Kategorisierung der Teams legt Team Topologies den Fokus auch auf Interaktionsmodelle zwischen diesen Strukturen. Die Interaktionsmodelle sind ausgerichtet an Zielsetzungen bezüglich der zu erreichenden Skalierung und Geschwindigkeit. Je nach Skalierungsanforderung an die Teams entscheidet man sich für eins der in Tabelle 1 aufgeführten Interaktionsmodelle (siehe Abbildung 6). In diesem Spiel können also – ausgehend von einer Architekturvision – die zukünftige Zielorganisation und die internen Interaktionsmodelle (inkl. Zwischenstufen) spielerisch geplant werden.

Impact Mapping

In nahezu allen Transformationsreisen spielt der Faktor Mensch beziehungsweise das Verhalten von unterschiedlichen Gruppen in der Interaktion miteinander eine wesentliche Rolle. Beispielsweise sind folgende Kulturbewegungen sehr häufig im Transformationskontext anzutreffen: DevOps-Kulturwandel, Agile Organisation, Feedbackkultur, Fehlerkultur, lebenslanges Lernen und viele weitere. Aber wie lassen sich Ziele für einen systemischen Wandel bestimmen und die resultierenden Kulturbewegungen mit motivierenden Maßnahmen oder Interventionen unterstützen? An dieser Stelle ist Impact Mapping (vgl. [Impac01]) eine sehr nützliche Herangehensweise. Die Methodik basiert wieder auf einer Baumstruktur und ist vergleichbar mit den Spielregeln, die wir bei den Critical to Quality Trees (CTQ) bereits diskutiert haben. Auch hier erarbeitet man sich die Ideen wieder in drei Stufen iterativ/inkrementell und widmet sich folgenden Themenstellungen (siehe Abbildung 7):

• Goal: Was ist die messbare Zielsetzung, die mit allen Organisationsmitgliedern erreicht werden soll?
• Actor: Welche Menschen/Stakeholder/ Gruppen/Akteure werden benötigt beziehungsweise müssen mitwirken, um dieses Ziel zu erreichen?
• Impact: Welches Verhalten beziehungsweise welche Verhaltensänderungen eines Akteurs braucht es, um das Ziel zu erreichen?
• Deliverable: Welche Maßnahmen müssen ergriffen werden, um das gewünschte Verhalten beziehungsweise eine Verhaltensänderung zu motivieren?
  

Ganz wichtig ist bei dieser Methodik, dass sie nicht zum Zweck der Manipulation von Menschen verwendet werden sollte. Sie dient als kollaboratives Spiel ausschließlich dem Erkenntnisgewinn und man sollte die dabei identifizierten Modelle mit den einzelnen Stakeholder-Zielgruppen diskutieren und nachjustieren. Kulturwandel gelingt nur aus freiwilligen Schritten. Oder anders beschrieben: Kulturwandel gelingt nicht durch disziplinarische Anweisung oder Manipulation! Es braucht die richtigen Anreize und aktive Mitsprache für diese Form der Veränderung.

Fazit

In einer von digitalen Geschäftsfähigkeiten geprägten Organisation ist die Architekturvision in fast allen Methoden ein Eingabeparameter, der auf die restlichen Entscheidungsfelder eine massive Auswirkung hat. Die Architekturrolle sollte daher in diesen strategischen Spielrunden mindestens als Teilnehmer präsent sein. Im Optimalfall kann sie auch als Facilitator den kompletten roten Faden im Strategieprozess begleiten und als Übersetzer für alle involvierten Stakeholder die Tücken der digitalen Welt verständlich machen, um die richtige Wahl der Maßnahmen zu unterstützen.
Abbildung 8 visualisiert die Zusammenhänge und mögliche Wege, die man je nach benötigtem Output (rote Hinweise an den Pfeilen) bestreiten kann, um in der vollen Transformationsbandbreite (Portfolio, Struktur, Prozesse, Kultur, Architektur, Technologie) passende Lösungswege zu finden.

Am Ende sind die hier genannten Ergebnisse dieser Methoden aber nur Modelle und Visionen. Die eingesetzten Werkzeuge sind daher nur Mittel zum Zweck, um mit vielen Mitspielern einen 360°-Blick auf die Zielsetzung beziehungsweise strategische Ausrichtung und Wahl von harmonierenden Taktiken zu bekommen. Die Realität hingegen ist wesentlich komplexer, als man es mit ein paar Kästchen und Bäumen abbilden kann. Daher können die Ergebnisse dieser Methoden eigentlich nur als ein Startpunkt für die Priorisierung von Experimenten (inklusive psychologisch geschützter Umgebung für Führungskräfte und umsetzende Teams) dienen. Nach den erfolgten Experimenten ist es sinnvoll, mit einem Teil-Ausschnitt der Vision gegebenenfalls erneut auf einem weißen Blatt Papier anzufangen. Die gezeigten Methoden weisen sehr viele Synergien auf. Mit diesem breiten Werkzeugkoffer ist es möglich, sich in einer Gruppe verschiedene Perspektiven auf die neue Realität zu erarbeiten. Je mehr unterschiedliche Spieler von Beginn an beteiligt waren, desto realistischer ist es, dass Zusammenhänge und Sinn der Maßnahmen auch Freunden, Kollegen und Mitstreitern in der Organisation verständlich erklärt werden können. Dies steigert wiederum die Chancen darauf, dass alle mit Spaß und Freude an der Realisierung dieser Visionen aktiv mitwirken.

Weitere Informationen

[ARC42] arcv42-Übersicht, siehe:
https://arc42.org/overview/

[Bra] A. Brandolini, Introducing Event Storming, siehe:
https://leanpub.com/introducing_eventstorming

[Devops] DevOps Topologies, DevOps Patterns and Antipatterns, siehe:
https://web.devopstopologies.com/

[EveSt] Event Storming, siehe:
https://www.eventstorming.com/
[Garde] Blog Simon Wardley, Introduction to Wardley Mapping, siehe:
https://blog.gardeviance.org/2015/02/an-introduction-to-wardley-value-chain.html

[Impac-01] Impact Mapping, siehe
https://www.impactmapping.org/

[Impac-02] Impact Mapping, siehe
https://www.impactmapping.org/example.html

[Leawm] Learn Wardley Mapping, siehe:
https://learnwardleymapping.com

[SkPa19] M. Skelton, M. Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT-Revolution, 2019
[Team-01] Team Topologies, siehe:
https://teamtopologies.com/

[Team-02] Team Topologies, siehe:
https://teamtopologies.com/key-concepts

[Twitt-SW] Twitter, Simon Wardley, siehe:
https://twitter.com/swardley

[Wiki-Conw] Wikipedia, Conway’s Law, siehe:
https://de.wikipedia.org/wiki/Gesetz_von_Conway

[Wiki-Gl] Wikipedia, Gläserrücken, siehe:
https://de.wikipedia.org/wiki/Gläserrücken

[Wiki-Q1], Wikipedia, ISO 9126, siehe:
https://de.wikipedia.org/wiki/ISO/IEC_9126

[Wiki-VUCA] Wikipedia, VUCA, siehe
https://de.wikipedia.org/wiki/VUCA