Am 13. Februar 2001 unterschrieben in einem Ski-Resort im US-Bundesstaat Utah 17 Menschen das Agile Manifest und lösten damit eine Welle aus, die bis heute viele Organisationen erfasst hat. Das Vorgehensmodell Scrum gewann massiv an Popularität und wird oft (fälschlicherweise) synonym mit Agilität verwendet. Heutzutage gibt es kaum eine größere Organisation, die sich nicht mit agiler Softwareentwicklung, Scrum oder schwergewichtigen Frameworks wie SAFe beschäftigt. Ziel ist dabei das Ideal von langlebigen selbstorganisierten Teams, welche in direkter Zusammenarbeit mit Kunden Wert für diesen in kurzen Feedbackzyklen erzeugt.
Zerrbild von Agilität
In der Realität sieht es leider oft anders aus. Viele Organisationen sahen die Umstellung auf agiles Arbeiten als eine primäre Umstellung der Vorgehensweise. Rituale wir Daily Scrum, Reviews und Retrospektiven wurden in die Arbeitsweise mit aufgenommen. Neue Rollen wie Scrum Master oder Product Owner ersetzten oder ergänzten existierende Rollen in den Teams. Das Umfeld dieser Teams blieb jedoch größtenteils konstant: Die existierende Organisation und Architektur blieben im Wesentlichen unverändert. Es ist nun mal einfacher, ein paar Whiteboards und Klebezettel zu erwerben, als tiefgreifende Änderungen in einer Organisation durchzuführen.
Problematisch ist in vielen Organisationen, dass der existierende fachliche und organisatorische Schnitt nicht auf das selbstorganisierte Arbeiten ausgelegt ist. Abhängigkeiten in der Organisation und der fachlichen und technischen Architektur führen dazu, dass Teams auf sich allein gestellt keinen Wert erzeugen können. Erst in der Zusammenarbeit mit anderen Teams entsteht Wert für Kunden und die Organisation selbst [Ker19]. Um Wert erzeugen zu können, müssen die Backlogs der beteiligten Teams eng synchronisiert werden. Gemeinsame Integrationstests stellen am Ende eines Inkrements sicher, dass alle benötigten Puzzleteile zusammenpassen. Vom Ideal eines agilen, selbstorganisierten Teams, das seine Anforderungen aus Gesprächen mit seinen Kunden eigenständig erhebt, ist diese Art der Zusammenarbeit weit entfernt. Dies erzeugt ein Zerrbild von Agilität und schadet der Akzeptanz von agilen Vorgehensweisen innerhalb der Organisation.
Was tun?
Ein wichtiger und oft diskutierter Punkt in der agilen Transformation ist die Auflösung von funktionalen Silos. Funktionale Silos innerhalb einer Organisation zielen darauf, die Fähigkeiten für eine bestimmte Funktion – oft Technologien oder spezialisierte Rollen wie Testexpertinnen und -experten – organisatorisch zu zentralisieren. Spezialisierte Frontend-Teams, Integrationstest-Teams, Datenbank-Teams sollten die Arbeit in den jeweiligen Disziplinen professionalisieren. Über einen Planungsprozess werden diese Spezialistinnen und Spezialisten (oft wenig wertschätzend als „Ressourcen“ bezeichnet) den entsprechenden Vorhaben allokiert. Die in den jeweiligen funktionalen Silos erstellten Arbeitsergebnisse müssen aufwendig an die anderen Teams übergeben werden (siehe Abbildung 1).
Abb. 1: Funktionale Silos unterbrechen den Entwicklungsstrom zum Nutzer
Durch die Übergaben zwischen den Teams geht wertvolles Wissen verloren. Häufig werden einzelne Teams dann zum Flaschenhals in der Organisation. In stark von Legacy-Host-Anwendungen geprägten Organisationen gibt es zum Beispiel oft ein oder mehrere Webanwendungsteams, welche die Weboberflächen für die unterschiedlichen Hostsysteme entwickeln. In Zeiten digitaler Self-Services werden diese Teams schnell zum Engpass für neue Anforderungen. Die Teams sind selbst nicht autark: Sie erhalten ihre Anforderungen von externen Anforderern, aber nur selten vom Kunden selbst.
Das weitgehende Auflösen dieser funktionalen Silos und die Schaffung von cross-funktionalen Teams ist daher ein wichtiger Bestandteil für eine gelungene agile Transformation. Cross-funktionale Teams enthalten alle benötigten technischen und fachlichen Fähigkeiten, um Wert für Nutzer zu schaffen. Aufwendige Übergaben und Planungen können vermieden werden.
Für eine funktionierende agile Transformation ist die Architektur der zweite wichtige Hebel, der aber häufig vernachlässigt wird. In [For18] betonen die Autoren, dass eine lose gekoppelte Architektur der wichtigste Faktor für eine hohe Leistungsfähigkeit der Softwarebereitstellung ist. Ohne eine Architektur, welche den Teams ermöglicht, eigenständig Wert für ihre Nutzer zu erzeugen, bleiben die Vorteile der agilen Transformation hinter den Erwartungen zurück.
Inverse Conway Maneuver
Doch wie lässt sich eine Architektur entwerfen, die Agilität unterstützt? Ein in diesem Zusammenhang etabliertes Vorgehen ist das sogenannte "Inverse Conway Maneuver". Der Name des Vorgehens spielt auf das Gesetz von Conway [Con68] an. Melvin Conway, nach dem dieses Gesetz benannt wurde, hatte 1968 beschrieben, dass von Organisationen erstellte Systeme die Kommunikationsstrukturen dieser Organisationen abbilden. Die Idee vom Inverse Conway Maneuver ist es, sich dieses Gesetz zunutze zu machen und anhand einer gewünschten Facharchitektur eine ideale Organisationsstruktur zu entwickeln. Diese Organisationsstruktur wird auf Basis des Gesetzes von Conway eine Systemarchitektur ergeben, die nun an der gewünschten Facharchitektur ausgerichtet ist (siehe Abbildung 2).
Abb. 2: Idealisierter Weg von der Geschäftsstrategie zur IT-Architektur
Modellierung der Facharchitektur
Die Facharchitektur beschreibt die fachliche Struktur eines Unternehmens. Sie kann als Ist- oder Soll-Architektur beschrieben werden. Ein dafür häufig in der Enterprise-Architektur benutztes Werkzeug ist die Business Capability Map [Sco09], in der die Wertschöpfung des Unternehmens in Business Domains und Business Capabilitys (zu dt.: "Geschäftsfunktion" oder "Fachfunktion") strukturiert wird (siehe Abbildung 3).
Abb. 3: Vereinfachtes Beispiel einer Business Capability Map für ein Kino
Eine Business Capability beschreibt das "Was", welches zur Ausführung der Geschäftsstrategie benötigt wird. Sie erzeugt ein fachliches Ergebnis, welches Wert stiftet. Business Capabilitys lassen sich in feingranularere Capabilitys zerlegen. Üblich ist eine hierarchische Darstellung. Grundsätzlich können Business Capabilitys aber auch als Netzwerk dargestellt werden, falls eine Capability als Teilfunktionalität mehrerer anderer Capabilitys benötigt wird.
Im Domain-Driven Design (DDD) [Eva03] wird mit der Subdomäne ein vergleichbares Konzept verwendet. Im DDD wird der Problemraum in möglichst unabhängige Teilprobleme (Subdomänen) unterteilt. Auch hier lassen sich Subdomänen in weitere Subdomänen zerlegen.
In der Praxis verwenden wir die Begriffe "Business Domain", "Business Capability" und "Subdomäne" synonym, je nachdem ob wir mit eher DDD-nahen Entwicklungsteams oder mit Kolleginnen und Kollegen aus der Enterprise-Architektur sprechen. Während der Begriff "Subdomäne" das zu lösende Problem beziehungsweise Nutzerbedürfnis in den Vordergrund stellt, beschreibt "Business Capability" die bereitgestellte Lösung – letztlich ist es eine Frage der Perspektive. Nick Tune beschreibt in [Tun], dass Konzepte wie Business Capability oder Subdomäne unscharf sind und sich nicht deterministisch bestimmen lassen.
Heuristiken für die Strukturierung der Fachlichkeit
Aufgrund dieser Unschärfe lässt sich die Facharchitektur nach unterschiedlichen Kriterien strukturieren. Dieser Artikel fokussiert auf die folgenden beiden Kriterien, die unmittelbar für eine gelungene agile Transformation essenziell sind:
- Strukturierung nach operationellen Wertströmen, das heißt, ausgehend von der Nutzersicht [SAFe],
- Strukturierung gemäß Änderungsfluss (engl. „Flow of Change“, Entwicklungswertstrom) [Ske19].
Die Identifikation von operationellen Wertströmen ist der erste Schritt für einen gelungenen fachlichen Schnitt. Operationelle Wertströme beschreiben eine Sequenz von notwendigen Aktivitäten, um ausgehend von einem Nutzerbedürfnis Wert für den Nutzer oder das Unternehmen zu erzeugen. Die Strategie der Organisation bestimmt dabei die Nutzergruppe und die zu erfüllenden Bedürfnisse. Innerhalb einer Organisation existieren viele Wertströme, welche unterschiedliche Bedürfnisse der verschiedenen Stakeholder wie zum Beispiel unterschiedliche Kundengruppen, Aufsichtsbehörden oder Eigentümer erfüllen. Zusammen bilden sie ein Netzwerk aus Wertströmen, die fachlich miteinander interagieren (siehe Abbildung 4).
Abb. 4: Wertströme unterschiedlicher Nutzergruppen und -bedürfnisse bilden ein Netzwerk
In dem in der Abbildung gezeigten Kinobeispiel liefert ein Eisverkäufer im Kinosaal Wert für den Zuschauer – dieser Wertstrom interagiert mit dem Wertstrom der Filmvorführung. Die Kinowerbung liefert Wert für das werbende Unternehmen, wie zum Beispiel einen erhöhten Bekanntheitsgrad in der gewünschten Zielgruppe. Jeder dieser Wertströme ist für sich gesehen wieder eine Quelle für Wert: Der Speiseeishersteller liefert Wert für das Kino, in dem es die für den Eisverkauf notwendigen Produkte anbietet, für die Kinowerbung erstellen spezialisierte Medienunternehmen entsprechende Werbespots usw. Eine leichtgewichtige Methode zur Analyse von Wertströmen ist das von Alberto Brandolini entwickelte Event Storming [Bra]. In einem Event Storming modelliert eine Gruppe – in einem Brain Storming ähnlichen Vorgehen – den Prozess durch Aneinanderketten von fachlich relevanten Ereignissen. Kollaborativ identifiziert die Gruppe dabei auch herausragende Ereignisse (engl. „pivotal events“), welche bereits einen guten Hinweis für die Entstehung von Wert darstellen und damit eine Grenze für einen möglichen fachlichen Schnitt liefern (siehe Abbildung 5).
Abb. 5: Wertströme anhand von Event Stormings analysieren
In dem hier gezeigten Kinobeispiel erzeugt die Buchungsbestätigung bereits Wert für den Kunden – sie erfüllt dessen Bedürfnis nach Sicherheit bezüglich der Verfügbarkeit eines Sitzplatzes.
Um einen sinnvollen fachlichen Schnitt zu definieren, bedarf es eines zweiten Kriteriums: der Änderungsfluss innerhalb der Fachlichkeit. Der Änderungsfluss zeigt, welche Teile der Fachlichkeit aufgrund fachlicher Abhängigkeiten meist gemeinsam geändert werden müssen. Müssen nun unterschiedliche Wertströme häufig gemeinsam geändert werden, dann bietet sich eine Zusammenlegung dieser Wertströme in einer Subdomäne an. Diese Teile der Fachlichkeit aufzuteilen und auf unterschiedliche Teams zu übertragen, würde zu einer starken Kopplung der Teams führen und damit die Möglichkeit zur Selbstorganisation einschränken. Durch die Kombination beider Kriterien wird die Fachlichkeit in Subdomänen aufgeteilt, in denen Teams mit minimalen Abhängigkeiten Wert für ihre Nutzer maximieren können.
In dem Kinobeispiel könnte festgestellt werden, dass die Anpassung des Prozesses für die Ticketbuchung meist gemeinsam mit der Anpassung des Buchungsänderungsprozesses erfolgt. In diesem sehr einfachen Beispiel wäre daher eine Zusammenlegung der Prozesse in einer gemeinsamen Subdomäne sinnvoll. Eine hilfreiche Checkliste von den Autoren von Team Topologies zur Validierung beider Aspekte und ergänzender Heuristiken findet sich in [ISH]. Diese enthalten auch weitere Heuristiken, die jedoch nur eine mittelbare Wirkung auf die Agilität der Organisation haben.
Wechselwirkung zwischen Organisation und fachlichem Schnitt
Viele Architekten sind in der Erhebung der Ist-Facharchitektur bemüht, die „pure“ Fachlichkeit abzubilden. Dabei verzichten sie bewusst darauf, die existierende Organisationsstruktur und Systemarchitektur zu berücksichtigen. Eine häufige Begründung dahinter ist, dass sich die Organisation in der Regel oft ändert, aber die Fachlichkeit selbst stabil ist. Dies ignoriert, dass bereits mit der Gestaltung der Organisation ein fachlicher Schnitt durchgeführt wird. Ist die Organisation beispielsweise in unterschiedliche Sparten gegliedert, dann hat die Organisation eine facharchitekturelle Entscheidung zur Trennung eben dieser Sparten getroffen. Um als Instrument für strategische Diskussionen wirksam zu sein, muss die Facharchitektur diese Entscheidung auch abbilden. Andernfalls klafft zwischen der Facharchitektur und der Realität innerhalb der Organisation eine zu starke Lücke.
Im Brown Field kommt zusätzliche Komplexität dazu. Die IT-Architektur mit der zugehörigen IT-Organisation und die Facharchitektur mit der dazugehörigen Geschäftsorganisation sind häufig separiert und nicht aufeinander abgestimmt (siehe Abbildung 6).
Abb. 6: Unabgestimmte Fach- und IT-Organisation im Brown Field
Unterschiedliche Fachabteilungen teilen sich die IT-Systeme, die häufig nach technologischen Aspekten geschnitten sind. Der fachliche Schnitt wird dadurch diffus, was oft in unklare Zuständigkeiten resultiert.
Auch aus regulatorischer Sicht führt dies zu Problemen. In der Finanzindustrie fordert beispielsweise die BaFin über ihre Anforderungen an die IT für Banken (siehe [BAIT] sowie ihre äquivalenten Anforderungen an Versicherungen, Kapitalverwaltungsgesellschaften und Zahlungsdienstleister) eine eindeutige Eigentümerschaft von Informationen bei den Fachbereichen – unklare Zuständigkeiten sind da kontraproduktiv.
Bei der Erstellung einer Facharchitektur führt die fehlende Abstimmung zwischen Geschäfts- und IT-Organisation unweigerlich zu Konflikten. Lösen lassen sich diese Konflikte durch eine Annäherung der Geschäfts- und IT-Organisation und schrittweise Transformation in eine Soll-Architektur – bis hin zu einer Verschmelzung in cross-funktionale Teams, wie bereits am Anfang dieses Artikels erwähnt. Die Anpassung der Organisation bringt gemäß Conways Gesetz aber auch eine Anpassung der zugehörigen IT-Systeme mit sich.
Wechselwirkung zwischen IT und fachlichem Schnitt
Auch die IT hat durch die aus ihr hervorgebrachten Innovationen einen direkten Einfluss auf den fachlichen Schnitt. Neue Technologien vereinfachen Prozesse oder erschließen neue Geschäftsfelder. Bisher existierende Probleme lösen sich auf, und neue Probleme entstehen. Dies kann zu neuen oder veränderten Business Capabilitys führen. Existierende Business Capabilitys können obsolet werden. Video-Streaming hat beispielsweise den klassischen Filmverleih über Videotheken obsolet gemacht, dafür aber neue Möglichkeiten für Kunden geschaffen.
Eine weitere Wechselwirkung ergibt sich aus der Verwendung von Standardlösungen. Diese bringen ihr eigenes Modell der Fachlichkeit mit sich. Organisation müssen sich beim Einsatz von Standardlösungen an diese anpassen – auch in der Art wie die Fachlichkeit geschnitten wird.
Detaillierung bis auf Teamebene
Doch wie weit sollte die Fachlichkeit ausmodelliert werden? In [Ske19] empfehlen die Autoren einen teamzentrischen Ansatz unter Berücksichtigung der maximalen Teamgröße und kognitiven Last. Kognitive Last [CLT] bezeichnet dabei das von den Teammitgliedern benötigte Arbeitsgedächtnis zur Erfüllung ihrer Aufgaben. Ist die kognitive Last zu hoch, sinkt die Produktivität des Teams und Flaschenhälse können entstehen. Die Modellierung der Facharchitektur muss daher detailliert genug sein, um ein Team innerhalb dieser klar zu verorten (siehe Abbildung 7) beziehungsweise den Zuständigkeitsbereich des Teams zu definieren, ohne dessen kognitive Teamkapazität zu überschreiten.
Abb. 7: Business Capability Map mit Teamzuordnung
Konsequenzen für die agile Transformation
Zum Start einer agilen Transformation empfiehlt es sich, den erwarteten Umfang der Transformation entsprechend der Facharchitektur und existierenden IT-Architektur zu definieren. Falls beispielsweise eine agile Transformation im Rahmen der Ablösung eines Altsystems vorgesehen ist, sollten die existierenden fachlichen Schnitte kritisch hinterfragt und der geplante Umfang der Ablösung entsprechend angepasst werden.
Bei bereits laufenden Transformationen sollte ebenfalls kritisch auf die existierenden fachlichen Schnitte geblickt werden. In der Praxis werden unvorteilhafte Schnitte von den Teams oft achselzuckend hingenommen. Gerade zu Beginn einer agilen Transformation fehlt oft die Sensibilität innerhalb der Teams für störende Abhängigkeiten. Eine bewusste Analyse der Facharchitektur hilft auch hier, Schwachpunkte transparent zu machen und ein gemeinsames Transformationsbild zu entwickeln.
Fazit
Agile Transformationen setzen hohe Anforderungen an die fachliche Architektur als Treiber für die Organisation und der daraus resultierenden IT-Architektur. Organisationen, die eine agile Transformation beabsichtigen oder sich bereits mitten in der Transformation befinden, sollten sich daher möglichst früh mit der Facharchitektur beschäftigen, um kritische Schwachstellen hinsichtlich der agilen Transformation zu identifizieren. Neben der Schaffung von cross-funktionale Teams sollte ein besonderes Augenmerk auf sinnvolle fachliche Schnitte gelegt werden, welche die Selbstorganisation der von der Transformation betroffenen Teams ermöglicht. Wesentliche Heuristiken dafür sind die operativen Wertströme und die Änderungsflüsse innerhalb der Organisation.
Die Fachlichkeit zu schneiden, ist auch ein Optimierungsproblem: Es gibt nicht den einen, perfekten Schnitt, sondern wie in allen Architekturdisziplinen eine Abwägungsentscheidung unterschiedlicher Faktoren. Ohne Anpassung der bestehenden Organisation und der daraus resultierenden Investitionen in die IT-Architektur kann eine agile Transformation nicht gelingen.
Weitere Informationen
[BAIT] Rundschreiben 10/2017 (BA) – Bankaufsichtliche Anforderungen an die IT (BAIT), siehe: https://www.bafin.de/SharedDocs/Downloads/DE/Rundschreiben/dl_rs_1710_ba_BAIT.html
[Bra] A. Brandolini, Introducing EventStorming, Leanpub, siehe:
https://leanpub.com/introducing_eventstorming
[CLT] Cognitive Load Theory, siehe: https://de.wikipedia.org/wiki/Cognitive_Load_Theory
[Con68] M. Conway, How Do Committees Invent?, in: F. D. Thompson Publications, Inc. (Hrsg.): Datamation, Band 14, Nr. 5, 1968
[Eva03] E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Pearson International, 2003
[For18] N. Forsgren, J. Humble, G. Kim, Accelerate – Building and Scaling High Performing Technology Organizations, IT Revolution, 2018
[ISH] Independent Service Heuristics, siehe:
https://github.com/TeamTopologies/Independent-Service-Heuristics
[Ker19] M. Kersten, Project to Product – How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, IT Revolution, 2018
[SAFe] Operational Value Streams, siehe:
https://scaledagileframework.com/operational-value-streams/
[Sco09] J. Scott, Business Capability Maps: The Missing Link Between Business Strategy and IT Action, in: Iasa Global, Architecture and Governance Magazine, Vol. 5, No. 9, 2009
[Ske19] M. Skelton, M. Pais, Team Topologies – Organizing Business and Technology Teams for Fast Flow, IT Revolution 2019
[Tun] N. Tune, Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined, siehe:
https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c
