Evolutionäre Architektur in dynamischen Umfeldern mit selbstorganisierten Teams
SOURCE:Heise Online
Eine evolutionäre Architekturstrategie sorgt für schnelle Reaktionen auf unvorhergesehene Ereignisse. Autonom handelnde Teams treffen fundierte Entscheidungen.
Softwareentwicklerinnen und -entwickler werden oft von unerwarteten Ereignissen überrascht: User verwenden neue Features auf unvorhergesehene Weise, was zu einer unerwarteten Last auf den Servern führt; eine Fremdbibliothek loggt nach einem Update plötzlich personenbezogene Daten, was gegen die Datenschutzrichtlinien verstößt; der Fallback-Mechanismus führt bei besonders datenintensiven Bausteinen unerwarteterweise zum Volllaufen des Caches. Jede Softwarearchitektin und jeder Softwarearchitekt kennt viele weitere Beispiele.
Alexander Kaserbacher ist Berater mit Fokus auf Softwarearchitektur. Zur Zeit beschäftigt er sich intensiv mit Evolutionärer Architektur und Platform Engineering.
Zu Beginn eines Projekts waren diese Ereignisse Unknown Unknowns, von denen vorher niemand wusste, dass er sie nicht weiß. Sie sind typisch für komplexe Probleme wie die in der Softwareentwicklung und führen insbesondere in einer Organisationsstruktur mit verteilten Teams zu Problemen. In solchen Strukturen existieren meist übergreifende Governance-Vorgaben etwa hinsichtlich Technologien, Programmiersprachen, Mustern und Schnittstellen. Um deren Definition kümmern sich zentrale Architekturteams. Strikte zentrale Vorgaben dieser Art stören aber oft eine effektive Reaktion auf Unknown Unknowns, wofür es mehrere Gründe gibt:
Die Vorgaben zielen meist auf Qualitätsaspekte der Software ab, wie Sicherheit, Wartbarkeit oder Zuverlässigkeit. Zentrale Einheiten müssen dabei einschätzen, wie die Teams die Vorgaben auf verschiedenen Abstraktionsebenen anwenden. Außerdem müssen sie im Voraus wissen, ob die vorgesehene Umsetzung die gewünschten Qualitätsansprüche überhaupt erfüllen kann.
Vereinheitlichung macht Softwareentwicklung langsamer, da für viele Entscheidungen die zentralen Einheiten zuständig sind, was ständige Abstimmungen aller Teams mit diesen erfordert. Das führt oft zu Engpässen.
Die Vorgaben nehmen den Entwicklungsteams Verantwortung, sodass sie sich für extern festgelegte Themen nicht zuständig fühlen.
Innovation wird erschwert, weil Entwicklungsteams sich strikt an Vorgaben halten und nicht davon abweichen. Dadurch fehlt das Feedback, ob sie tatsächlich geeignet sind oder ob es bessere Alternativen gibt.
Problemlösung in dynamischen Umfeldern
Da in einem dynamischen Umfeld passende Lösungen für überraschende Probleme oft nicht vorhersehbar und planbar sind, müssen sich die Akteure einer guten Antwort schrittweise nähern. Ähnliche Herausforderungen gibt es in der Wissenschaft, wo Forscherinnen und Forscher neue Erkenntnisse durch Hypothesen gewinnen. Experimente und formale Beweise bestätigen oder widerlegen diese Hypothesen, sodass die Annäherung an neue Erkenntnisse schrittweise erfolgt. Je mehr Unknown Unknowns in einem Softwareprojekt versteckt sein könnten, desto stärker profitieren die Entwicklerinnen und Entwickler von kleinen Schritten (Hypothesen), die regelmäßig durch Feedback validiert werden. Abbildung 1 veranschaulicht diesen Prozess.
Eine Hypothese wird durch Feedback-Mechanismen validiert (Abb. 1).
Entwicklungsteams betrachten jedes Release als Hypothese. Unabhängig davon, ob es um die Wahl von Messaging-Technologie und Datenbanken für hohen Durchsatz geht oder um einen Failover-Mechanismus zur Verbesserung der Verfügbarkeit – anstatt zentralen Vorgaben zu folgen, entscheiden sich Entwicklungsteams selbst für einen passenden Ansatz und setzen ihn in ihrem Verantwortungsbereich um. Diesen Ansatz validieren sie dann schnellstmöglich durch effektives Feedback. Sind beispielsweise der Durchsatz und die dazugehörige Geschwindigkeit ein wichtiges Ziel, bieten Performance-Messungen am laufenden System eine wertvolle Rückmeldung. Ziele wie Verfügbarkeit sind ebenfalls direkt messbar, während sich Wartbarkeit oft anhand von Metriken wie Kopplung oder zyklomatische Komplexität (Kontrollflussgraph eines Programms) ableiten lässt.
Die Feedback-Mechanismen zeigen den Entwicklungsteams Verbesserungsmöglichkeiten, die sie dann in neuen Hypothesen umsetzen. Das ähnelt dem evolutionären Prozess in der Biologie, bei dem genetische Variation lokal und dezentral entsteht, während die natürliche Selektion schlechte Varianten aussortiert.
Im IT-Kontext entsteht Variation in den Arbeitsergebnissen selbstorganisierter Teams, während Feedback-Mechanismen (Selektion) unpassende Teile schnell aufdecken. In Anlehnung an die Biologie nennt sich dieses Konzept Evolutionäre Architektur. Sie beschreibt eine Produktentwicklung, die durch inkrementelle, emergente Praktiken und regelmäßiges, qualitatives Feedback in komplexen Umfeldern dynamisch agiert.
Die Wechselwirkung zwischen Hypothesen und Feedback sollte dabei rasch und kleinteilig erfolgen. Empirische Daten wie die Four Key Metrics verdeutlichen diese Dynamik (Forsgren, N. u.a.: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations; 2018). Sie definieren wichtige Metriken, über die sich High-Performing Teams von anderen unterscheiden:
Deployment Frequency stellt dar, wie oft Entwicklungsteams den Zyklus aus Abbildung 1 durchlaufen.
Lead Time for Changes zeigt, wie schnell Entwicklungsteams diesen Zyklus durchlaufen.
Time to Restore Service und Change Failure Rate beschreiben das Risiko, das mit dem Deployment von möglicherweise fehlerhaften Hypothesen verbunden ist.
Damit sich Entwicklungsteams möglichst effektiv einem zufriedenstellenden Ergebnis nähern, sind kleine und häufige Deployments mit geringem Schadenspotenzial entscheidend. Klassische Governance-Ansätze (siehe Kasten „So entstehen klassische Governance-Ansätze“) stehen dem oft im Weg, denn manuelle Freigabe- und Kontrollprozesse verlängern die Deployment Frequency und Lead Time for Changes.
Softwaresysteme setzen sich aus mehreren Bausteinen zusammen: Module, Services, Applikationen – je nach Kontext und Detaillierungsgrad können sie anders bezeichnet sein. Gemeinsam bilden sie ein größeres System, sei es ein einzelnes Softwareprodukt oder die gesamte IT-Struktur eines Unternehmens. Softwarearchitektinnen und -architekten teilen die Bausteine häufig nach fachlichen Kriterien auf, insbesondere durch Techniken wie Domain-driven Design oder durch Architekturmuster wie Microservices. Ein Beispiel dafür ist ein Onlineshop, der aus Bausteinen wie Produktkatalog, Suche und Warenkorb besteht.
Wenn solche Systeme so umfangreich werden, dass ein einzelnes Team sie nicht betreuen und weiterentwickeln kann, splitten viele Organisationen die Verantwortung auf und weisen einzelne Bausteine jeweils einem eigenen Team zu. Eines könnte beispielsweise speziell für den Warenkorb-Baustein zuständig sein.
Sobald die Anzahl der Bausteine und Teams wächst, stehen Organisationen vor der Herausforderung, die zunehmende Komplexität zu bewältigen. Typische Probleme wie ein Wildwuchs an Technologien führen zu dem Wunsch nach übergreifenden Regeln und Vorgaben. Zentrale Architekturteams kümmern sich dann um die Definition allgemein gültiger Standards. So entstehen etwa Regeln hinsichtlich Technologien, Programmiersprachen, Muster und Schnittstellen sowie spezifische Strukturierungsvorgaben.
Die Hoffnung dabei ist, durch Standardisierung und Vereinheitlichung die Effizienz zu steigern. Entwicklungsteams sollten schneller arbeiten können, wenn sie sich an Vorgaben halten, statt selbst langwierig Entscheidungen zu treffen und Alternativen zu prüfen und abzuwägen. Einmal entwickelte Bausteine ließen sich wiederverwenden, auch teamübergreifend. Operation Teams wären effizienter, weil sie nur genau eine standardisierte Zielumgebung betreuen müssten.
Diese klassischen Ansätze versprechen auf den ersten Blick zwar Effizienzsteigerung, führen aber langfristig oft zu Problemen in der Verantwortungsübernahme und zu Innovationsstau.
