Braucht Agile Architektur, um erfolgreich zu sein?
Bei einer kürzlich besuchten Agile-Konferenz eröffnete einer der Referenten seinen Vortrag mit den Worten: „Agile ohne Plan ist nur Chaos“. Es sähe ganz so aus, dass Agile ohne effektive Architektur letztendlich zu Chaos führen wird, insbesondere dann, wenn Organisationen versuchen, ihre Agile Praxis ohne irgendeinen Orientierungsrahmen zu skalieren.
Wir versuchen alle innerhalb von teilweise gegebenen Beschränkungen zu operieren, die in ihrer Natur kundenorientiert, finanziell, regulatorisch, technisch oder kompetitiv sein können. Während agile Praktiken traditionell auf die Softwareentwicklung beschränkt waren, wird von Unternehmen, insbesondere im Enterprise-Bereich, ein erheblicher Druck ausgeübt, agile Praktiken zur Verwaltung traditioneller Geschäftsfunktionen einzusetzen. Dieser neue Trend wird euphemistisch als „New Ways of Working“ bezeichnet. Die Vorteile der Nutzung agiler Praktiken sind vielfältig, mit dem grundlegenden Vorteil, dass Unternehmen agile Praktiken als eine Möglichkeit sehen, ihren Kunden und Interessengruppen bessere Ergebnisse zu liefern – schneller, effizienter und konsequenter. Dies kann nur dann funktionieren, wenn grundsätzliche Enterprise-Architektur-Elemente definiert sind und ein Rahmen vorgegeben wird, der agile Vorgehensweisen unterstützt.
Der Einsatz eines als altmodisch wahrgenommenen Architektur-Rahmenwerks wie z.B. TOGAF® scheint in direktem Gegensatz zur agilen und schlanken Weltanschauung zu stehen. Es ist äußerst detailliert mit zahlreichen Frameworks, Techniken und Vorlagen, die in einem ziemlich sterilen Handbuch beschrieben sind, welches fast 700 Seiten umfasst. Dies passt nicht gut zu dem agilen Fokus auf die Bevorzugung funktionierender Software gegenüber Dokumentation.
Es gibt hier einen kulturellen Unterschied wie bei allem. Agile setzt sich für uneingeschränkte Teams ein und fördert die direkte Zusammenarbeit, während die Welt von TOGAF als Architektur-Boards und sorgfältig indizierten Dokumenten-Repositories wahrgenommen wird.
Es ist wichtig zu beachten, dass TOGAF Lieferobjekte erfasst, die in einer großen Organisation sowieso erstellt und benötigt werden, unabhängig davon, ob sie als Teil eines Frameworks ausgeführt werden. Sie sollten alle eine Art von architektonischer Vision haben, die an einer Geschäftsstrategie ausgerichtet ist. Es müssen gemeinsame Vereinbarungen über die Vorgehensweise getroffen und sichergestellt werden, dass die Entscheidungen fair und transparent sind. Sie müssen ihr Anwendungsportfolio nachverfolgen, Wirtschaftlichkeitsrechnungen durchführen, Architekturentscheidungen treffen, unnötige Wiederholungen reduzieren, Prozesse dokumentieren, eine gemeinsame Einigung über die Vorgehensweise ermöglichen und sicherstellen, dass Entscheidungen fair und transparent sind. Gleichzeitig können die TOGAF-Artefakte wie Listen, Matrizen und Modelle in anderen Organisationen, wie z.B. im Qualitätsmanagement, Geschäftsprozessmanagement, ISO-Zertifizierungsdokumentationen etc, wiederverwendet werden. Neue Ansätze in der Low-Code-Anwendungsentwicklung erlauben die direkte Wiederverwendung von z.B. während der Architekturarbeit erstellten BPMN 2.0 Modellen in Werkzeugen wie APPIAN für die agile Entwicklung von Anwendungen mit minimalem Programmieraufwand.
TOGAF ist kein starrer Rahmen, der genauestens befolgt werden muss. Vielmehr soll es die Praktiker aktiv ermutigen, das Anwendungsmodell den Umständen anzupassen und zu modifizieren. Dies bedeutet, dass die verschiedenen Teile von TOGAF an die agile Entwicklung angepasst werden können. Viele glauben, dass TOGAF einen Wasserfall-Ansatz impliziert – und genau das ist nicht ganz richtig.
SAFe
Die meisten agilen Frameworks, die versuchen, Scrum für große Organisationen einzuführen, haben immer einen Platzhalter für Architektur. Der Hauptunterschied besteht darin, dass sie in der Regel auf Zusammenarbeit, Einfachheit und dezentrale Governance Wert legen. Das kann in seiner vollen Schönheit in der Capability Architektur im Rahmen der Strategischen und Segment Architektur stattfinden.
Das SAFe (Scaled Agile Framework) Framework hat am meisten dazu beigetragen, die Rolle der Architektur in einer agilen Umgebung zu identifizieren. Wie bei allen Dingen rund um Agile geht es darum, einen konsistenten Wert zu schaffen, und Architektur ist nicht anders.
Die Architecture Domains in SAFe sind decken sich mit den Architecture Domains in TOGAF, was die Zuordnung sehr vereinfacht.
Emergent Design
Emergent Design bietet die technische Grundlage für die Entwicklung und die schrittweise Umsetzung von Initiativen. Es hilft Designern und Architekten, auf sich ändernde Kunden- und Stakeholderbedürfnisse zu reagieren, um sicherzustellen, dass die Initiative kontinuierlich Wert schafft. Auf dieser Ebene sehen die SAFe-Praktiker die Architektur als eine gemeinschaftliche und interaktive Übung, durch die das Designelement entstehen kann.
Intentionelle Architektur
Intentionelle Architektur ist ein strukturierterer Ansatz und orientiert sich mehr an dem, was viele als traditionelle Architektur bezeichnen würden, d.h. an einer Reihe von definierten und geplanten Architekturinitiativen, die die Leistung und Benutzerfreundlichkeit der Initiative unterstützen und verbessern sollen. In der Tat ist Intentional Architecture eine klare Erkenntnis, dass wir alle innerhalb bestimmter Einschränkungen wie der Wahl der Architekturvorgaben, Technologieplattform, des Finanzbudgets usw. operieren müssen. Wenn diese Einschränkungen identifiziert und in die Initiative integriert werden können, steigt die Wahrscheinlichkeit, dass die Initiative erfolgreich ist und Wert liefert, oder die Ergebnisse werden im Rahmen des Architecture-Change-Management Architekturanpassungen auslösen.
SAFe-Praktiker behaupten, dass durch die Balance von Emergent Design und Intentionalität Agile Praktiken skaliert werden können, um Lösungen auf Unternehmensebene zu liefern. In Safe wird diese Kombination auf die Architectural Runway bezogen, die die technische Grundlage für die Schaffung von Geschäftswert bietet, was in völliger Übereinstimmung mit den traditionellen Ansichten der Architektur steht.
Der Schlüssel zum Erfolg dieses Ansatzes liegt in der Abstraktionsebene, auf der die Balance von Enterprise-Architecture, Emergent Design und Intentional Architecture stattfindet.
Auch in einer agilen Welt bleibt die Rolle des Architekten eine Schlüsselrolle. Die Ausbildung und allenfalls eine Zertifizierung in einem der Frameworks, wie z.B. TOGAF, ist sinnvoll und wirkungsvoll. Einige Architekten müssen auch Kenntnisse, Fähigkeiten und Erfahrung in Agile, SAFe und SCRUM haben. Alle Teammitglieder müssen verstanden haben, wie Enterprise-Architektur und Agile zusammenpassen.
Die Fähigkeit zur Zusammenarbeit ist hier eine der benötigten Schlüsselfähigkeiten. Architekten müssen in der Lage sein, produktiv mit Agile Teams zusammenzuarbeiten, um schnelle und lokale Unterstützung bei der Anwendung von Emergent Design zu bieten und gleichzeitig Agile Teams dabei zu unterstützen, die durch die Intentionelle Architektur definierten Einschränkungen zu erkennen und zu steuern. Eines der wichtigsten Merkmale von Agile Practices ist die Tatsache, dass Agile Teams ermutigt werden, ihren Interessengruppen ständig Feedback zu geben. Bei der Entwicklung neuer Entwürfe können Architekten diese Informationen nutzen, um die Intentionelle Architektur anzupassen und zu entwickeln, um sicherzustellen, dass sich die Gesamtarchitektur des Unternehmens mittel- bis langfristig mit der Organisation weiterentwickelt.