Architektur und Agilität – wo könnte der Widerspruch liegen?

Architektur und Agilität – wo könnte der Widerspruch liegen?

Agile Architektur ist die Art, wie Unternehmensarchitekten, Systemarchitekten und / oder Softwarearchitekten die architektonische Praxis in der agilen Softwareentwicklung anwenden. Eine Reihe von Kommentatoren hat ein Spannungsverhältnis zwischen traditioneller Softwarearchitektur und agilen Methoden entlang der Achse von Anpassung (Aufschieben von Architekturentscheidungen bis zum letztmöglichen Zeitpunkt) und Antizipation (Planung im Voraus) festgestellt.

Das Spannungsverhältnis besteht zwischen einem zu geringen Zeitaufwand für die Planung einer Architektur im Vorfeld, die das Risiko dieser architekturellen Anpassung erhöht, und einem zu hohen Zeitaufwand, der sich negativ auf die Bereitstellung von Mehrwert für den Kunden auswirkt.

Agile Architektur wird insbesondere durch folgende sechs Dinge beeinträchtigt:

• Instabilität der Anforderungen
• technisches Schulden
• zu frühe Wertschöpfung
• Teamkultur
• Kundenagilität
• Erfahrung

Zu diesen gibt es Maßnahmen, sodass diese zu keinem Problem werden:

• Reagieren auf Veränderungen
• Risikobewältigung
• emergente Architektur
• Big Design im Vorfeld
• Verwendung von Rahmenwerken und Architekturvorlagen.

In der klassischen Softwareentwicklung war es üblich, nach der Spezifikation der fachlichen Anforderungen, im „Design“ Schritt, also während des Designs der Software, die notwendigen Anpassungen an der Architektur zu definieren und zu dokumentieren. Der „Design“ Schritt wird bei agiler oder iterativer Arbeit für jedes Arbeitselement innerhalb der Iteration oder des Sprints durchlaufen. Selbstverständlich können hier entsprechend proportional kleinere Änderungen an Architektur definiert werden. Aus der Erfahrung heraus ist es jedoch schwierig, in dieser Zeit größere Abstimmungen in Architekturboards oder Freigaben in solchen zu erwirken, um also Architekturanpassungen zu dokumentieren, gilt es an diesen Stellen Verzögerungen und Übergaben zu reduzieren. Mehr dazu später unter „Best Practices für Agilität aus Frameworks“. Man könnte auch annehmen, es reiche, Intentional Architektur nicht mehr zu verfolgen. Das agile Manifest sagt, „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“

Nicht für alle Systeme lässt sich dieses Prinzip so anwenden, weshalb für agile Architektur erweiternde Prinzipien entwickelt wurden:

Evolutionäre Zusammenarbeit statt Blaupause

Anstatt wie in der klassischen Softwareentwicklung ein Architekturdesign mit langer Lebensdauer zu entwickeln, kann man versuchen, Architektur als ein Produkt im Rahmen der Entwicklung zu sehen. Demnach ist Architekturdesign ein inkrementell erweiterbares Artefakt, das später in der Entwicklung genutzt werden kann.

Kommunikation statt Perfektion

Passend zum agilen Manifest und zum Pareto-Prinzip, bietet sich an, architekturelle Dokumentation und Anforderungen nach dem Pareto-Prinzip nicht zu perfektionieren, sondern auf die Kommunikation zwischen den Teammitgliedern und den Verantwortlichen für Architektur bauen.

 

Aktive Beteiligung der Stakeholder

Teil des architekturellen Designs ist die Ableitung nichtfunktionaler Anforderungen aus den Vorstellungen des / der Stakeholder. Um die Architektur zu verbessern, ist es somit hilfreich, Stakeholder eng einzubinden.

Unternehmensarchitekten sind aktive Teilnehmer in Entwicklungsteams

Im Sinne von Scrum, werden Teams so gestaltet, dass sie alle notwendigen Kompetenzen haben, die notwendig sind, um ein Stück eines Produkts zu designen, zu entwickeln, zu testen und an Kund:innen auszuliefern. Da der Schitt „Design“ auch architekturelles Design enthält, ist es demnach notwendig, auch Architekt:innen in das Team zu integrieren.

Befähigung statt Inspektion

Verzögerungen aufgrund von Übergaben finden insbesondere dann statt, wenn Expertise nicht innerhalb eines Entwicklungsteams aufgebaut wird. Daher ist es hilfreich, zur Dezentralisierung von Entscheidungsfindung, Teammitglieder zu befähigen, anstatt ihre Vorschläge ausschließlich zu inspizieren und zu bwerten.

 

Abstraktion von Modellen

Analog zur Anwendung von „Adaption statt Perfektion“, ist es auch hilfreich, das architekturelle Design in geringerem Detail zu entwickeln, je komplizierter die betrachtete Komponente wird.

Erfassen von Details mit funktionierendem Code

Getreu dem agilen Prinzip „Funktionierende Software über vollumfängliche Dokumentation“, sollte nach diesem Prinzip architekturelle Spezifikation ebenfalls in Code oder Pseudocode erfolgen.

Schlanke Leitplanken ohne bürokratische Verfahren

Der Fokus auf Mehrwert für Nutzer:innen oder Kund:innen erfordert, dass man sich auch in der Architekturarbeit nicht auf die Produktion von Dokumentation und bürokratischem Overhead einlässt. In dem Sinne gilt es, Verzögerungen und Übergaben zu reduzieren. Auch hier wird dann mit dezentralisierten Entscheidungen gearbeitet.

Verfügen Sie über ein engagiertes Team von erfahrenen Unternehmensarchitekten

Zu guter Letzt darf man nicht vergessen, dass Arbeit am besten funktioniert, wenn man engagierte und erfahrene Teams aufbaut.

Architekturanforderungen für Produkte in einer VUCA-Welt sind auch VUCA.

Agile Arbeitsmodelle wurden entwickelt, um Produkte in einer VUCA-Welt zur Verfügung zu stellen. Dabei stellt sich die Frage: Ist Architektur etwas, das überhaupt agil entwickelt werden sollte? Ist es im komplexen Problemhorizont? Oder im komplizierten (siehe Cynefin)?

Auch Architektur befindet sich in einem VUCA-Umfeld, denn unsere Architektur muss sich ggf. ändern, weil sich…

…technische Grundlagen ändern

Forschung und Entwicklung ermöglichen schnellere Änderung von technischen Komponenten (Hardware oder Software), oft auch nicht abwärtskompatibel.

…Kundenbedürfnisse verändern

Die Bedürfnisse von Kund:innen verändern sich aus der Folge neuer Konkurrenz oder neuer technischer Möglichkeiten.

…Neue Konkurrenz auftaucht

In einem freien Markt haben Kunden grundsätzlich freie Wahl des Anbieters / der Anbiterein ihrer Produkte. Sollten sich durch neue Konkurrent:innen Möglichkeiten ergeben, kann das schlechte Auswirkungen auf eine Organisation haben.

Best Practices für Agilität aus Frameworks

Einige agile Skalierungsframeworks bieten Möglichkeiten, Agilität strukturiert in die agile Zusammenarbeit einfließen zu lassen. Ein Beispiel hierfür ist das Scaled Agile Framework (SAFe), das folgende Modelle zur Abbildung architektureller Anforderungen bietet:

Architekturelle Startbahn (Architectural Runway)

Der Architectural Runway besteht zum Großteil aus existierendem Code sowie Komponenten und der entsprechenden Infrastruktur, welche dafür nötig sind, um Funktionen schnell, aber in ausreichender Qualität, zu implementieren. Laut SAFe ist sie daher nötig für die Continuous Delivery Pipeline, da sie den kontinuierlichen Wertfluss zu ermöglicht.

Intentional Architecture beschreibt, alles proaktiv zu verbessern, was Kunden an einem System oder Produkt bewegt. Von der Gestaltung der Systeme beim direkten Kundenkontakt, bis auf die Grundlagen der Design-Strategien, auf deren Basis das Produkt oder System entwickelt wird.

Emergent Design ermöglicht es, bestehendes Design aktuell zu halten, sich aber trotzdem anpassen zu können, wenn die Kunden oder Kundenwünsche sich verändern.

Architekturarten

Bei der Betrachtung von Architektur in einer agilen Organisation, darf nicht vergessen werden, dass Architektur auf verschiedenen Ebenen passiert. So gibt es beispielsweise Organisationsarchitektur, Businessarchitektur, Gebäudearchitektur und natürlich auch IT-Architektur. Letztere lässt sich sogar noch weiter aufteilen.

Wenn man architekturelle Ziele verfolgt, sollte man diese Arten von Architektur gleichermaßen betrachten, auch wenn eine Architectural Runway in manchen Fällen schwierig zu erahnen ist (zum Beispiel Gebäudearchitektur).

Architectural Enabler

Zur Umsetzung des Intentional Designs, gibt es in SAFe das Konzept der Enabler. Enabler machen Arbeit an der Architectural Runway transparent, indem sie auf jeder Ebene der Artefakte (Story, Feature,…) existieren und eine Maßnahme der Verbesserung der Architectural Runway.

Video Skript:

In letzter Zeit haben sich mehr und mehr Unternehmen und Organisationen damit beschäftigt, ihre Zusammenarbeitsmodelle an die Anforderungen der aktuellen Umwelt (VUCA-Welt) anzupassen. Die sichtbar häufigeren und stärkeren Veränderungen der Nachragen- und Angebotsprofile der internationalen Märkte machen diese Anpassungen notwendig. Im Kontrast dazu stehen Entscheidungen, die von langer Lebensdauer sind. Ein Beispiel dafür ist die Ziel-Architektur eines Softwaresystems. So teilt man IT Architektur grundlegend in zwei Teile auf: Intentional Architecture, also die vor der Entwicklung spezifizierte Zielarchitektur und das Emergent Design, also die während der Entwicklung stattfinden architekturellen Entscheidungen. Wenn man also in einer agilen Arbeitsweise Pläne in Iterationen schmiedet und ggf. auch anpassen möchte, wie passt das zum Konzept der „Intentional Architecture“? Glücklicherweise haben die bekanntesten agilen Skalierungsframeworks einen Ansatz, wie man diese konträren Sichtweisen auf Produktentwicklung vereinen kann. In der Regel werden dazu architekturelle Aufgaben und Verantwortlichkeiten auf mehrere Personen in verschiedenen Teams aufgeteilt. Möglich ist so beispielsweise das Modell eines Architekturagenten je Team oder je Thema, sodass Architekturaufgaben in einem bestimmten Kontext an eine Person abgegeben werden kann, die die gestellte Herausforderung am besten bearbeiten kann. Viele Herausforderungen im Bereich Intentional Architecture werden durch die Anwendung einer Definition of Done (DoD) abgedeckt. Die größten Teile der Intentional Architecture werden dabei in der DoD abgebildet. Auf diese Art finden die Vorgaben der Intentional Architecture in jeder Story Anwendung.