Im agilen Umfeld ändern sich nicht nur die Softwareentwicklung und das Projektmanagement, sondern auch die Art, Architekturarbeit zu leisten. Veraltete Vorstellungen müssen dabei über Bord gehen und neuen Aufgaben weichen.
“Softwarearchitektur ist etwas sehr Geplantes und Vorausschauendes. Lange müssen sich kluge Köpfe einschließen, um schlussendlich mit detailliert durchgearbeiteten Plänen zu erscheinen und den Teams die Architektur zu erklären.” - So oder so ähnlich stellt man sich häufig Architekturarbeit vor. Die Wirklichkeit könnte und sollte nicht weiter von einer solchen Äußerung entfernt sein.
Die Anwendung agiler Methoden beschränkt sich leider oft auf zwischenmenschliche oder Projektmanagement-Themen und lässt oft die technischen Errungenschaften, zum Beispiel aus dem Extreme Programming, außen vor. Dabei sind diese wichtige Punkte für moderne Softwareentwicklung. Auch moderne Softwarearchitektur folgt wie selbstverständlich dem agilen Wandel und arbeitet oft erst hinterher an einem Abbau von technischen Schulden oder wie ich es lieber bezeichnen würde, einem Schärfen der Architektur. Häufig ist es nämlich bereits so, dass die Mikroarchitektur, früher herablassend Architektur-im-Kleinen genannt, bereits sehr gute Ansätze enthält und somit die Makroarchitektur gut angepasst werden kann, also die Architektur, die sich um das große Ganze kümmert. So entsteht Architektur mehr durch ein Hand-in-Hand-Arbeiten anstatt von oben herab.
Wie kann dies nun in der Praxis funktionieren? Darauf möchte ich in diesem Artikel aus verschiedenen Blickwinkeln eingehen. Dies soll sich aber immer auf die zeitlichen oder sich verändernden Aspekte beziehen, da das Thema aus statischer Sicht schon sehr gut durch die Hexagonale Architektur von Alistair Cockburn oder der Onion Architecture von Jeffrey Palermo abgedeckt wird. Diese stellen ein Grundgerüst für die Flexibilität der Weiterentwicklung dar.
Veränderung
Was sind denn Treiber, die zu einer Veränderung der Architektur führen? Normalerweise sind dies Kosten oder neue Anforderungen, seien sie funktionaler, wie z.B. neue Features, oder nicht-funktionaler Art, wie z.B. mehr Benutzer auf der Plattform. Dann kommen noch viele andere Themen dazu, wie z.B. Änderungen des Personals oder gesetzliche Änderungen, die für Architekten überhaupt nicht beeinflussbar sind. All dies sind Beispiele für Veränderung von außen, also nicht aus dem Entwicklungs- oder Architektenteam.
Die Zeitmaschine
Um bestmöglich mit diesen Veränderungen zurechtzukommen, bietet es sich an, sich zu jedem Zeitpunkt an eines der beiden oben genannten Architekturmuster Hexagonal, bzw. Onion-Architecture anzunähern. Dies ist allerdings in der Realität kaum möglich und greift außerdem für die eigentliche Architekturarbeit viel zu kurz, da dies hauptsächlich der Wartbarkeit, bzw. Weiterentwickelbarkeit nützen würde, aber nicht den evtl. anderen anzunähernden Architekurzielen. So gibt es für Architekten viel mehr und vielschichtigere Architekturarbeit zu tun. Gregor Hohpe beschreibt es im Kontext der Enterprise-Architektur als Aufzugfahren. Man wechselt ständig zwischen den Ebenen der Fachexperten, der Entwickler und dem Management. Diesem sehr nützlichen Bild möchte ich noch zwei weitere hinzufügen. Das erste ist das Bild der Zeitmaschine. Ständig wechselt man hin- und her zwischen verschiedenen Möglichkeiten der Zukunft, dem aktuellen Zustand und evtl. sogar der Vergangenheit, wenn Ursachenforschung betrieben wird. So muss evtl. für den Vorstand eine Vision der Architektur vermittelt und zwischendurch die Ursache für eine zurückliegende Downtime erklärt werden. Sämtliche Konzepte mit den jeweiligen Begründungen sind an der richtigen Stelle im passenden Detailgrad zu erklären. Dabei ist eine gute nach arc42-Struktur aufgebaute Dokumentation sehr hilfreich. Mindestens sollten jedoch Architekturentscheidungen verschriftlicht werden, damit zugesichert werden kann, dass die Entscheidungen bewusst getroffen wurden.
Der Kostümverleih
Das zweite Bild ist ein Kostümverleih. Hier kann sich jemand für die Architekturarbeit unterschiedliche Kostüme ausleihen und sich dementsprechend in Meetings, Workshops oder Einzeltreffen verhalten. Im passenden Kostüm verwandelt man sich in die geeignete Rolle wie ein Scrum-Master bei den 8 stances of a scrum-master und weiß sich passend zur Situation und dem jeweiligen Nutzen in verschiedenen Rollen auszudrücken:
- Ein Coach kann Entwickelnden oder anderen, an der Architektur arbeitenden Stakeholdern, Tipps zu Methoden geben und an der richtigen Stelle, die richtigen Fragen stellen um die Leute voranzubringen.
- Ein Servant Leader nimmt sich selbst und manchmal auch die Architektur zurück, um das Team oder das Produkt nach vorne zu bringen und die Geschäftsziele bestmöglich zu unterstützen. Dabei werden auch manchmal unangenehme oder lästige Aufgaben übernommen, wie die Klärung von Konflikten.
- Eine Lehrer*in lehrt Technologien, Architekturen.
- Ein Facilitator setzt den Rahmen für die Architektur, ermöglicht Diskussion, stellt Kommunikation her und organisiert Workshops.
- Eine Manager*in plant voraus, verteilt Aufgaben und prüft, ob alles so läuft, wie es soll.
- Eine Archäolog*in gräbt sich durch Millionen Zeilen von Code oder Logfiles und entdeckt die Nadel im Heuhaufen.
- Zu guter letzt hält eine BürokratIn die Dokumentation zusammen und prüft, ob alle Vorgaben eingehalten werden.
Diese unterschiedlichen Rollen können gut dafür genutzt werden, die Aufgaben einer ArchitektIn auszuüben. Im Foundation-Lehrplan des iSAQB sind diese Aufgaben gut erklärt. Allerdings möchte ich hier die permanente Kommunikation und Vermittlung zwischen den verschiedenen Stakeholdern, insbesondere Anforderern, Entwicklern, Testern und Betrieb in den Vordergrund stellen. Dem agilen Manifest nach sollte man zu jeder Zeit die Interaktion und die Menschen untereinander wichtig nehmen und in passenden, am besten zeitlich begrenzten, Terminen behandeln. Wenn die Kommunikation offen und ehrlich geführt wird, dann werden Themen wie Qualität oder Entwickelbarkeit automatisch zu viel diskutierten Themen und erhalten somit die sonst oft fehlende Priorität. Als ArchitektIn im agilen Umfeld hat man also neben Scrum-Master, agilen Coach oder Product-Owner ebenfalls die Aufgabe, Kommunikation herzustellen und Wissen zu streuen.
Das Wachsen
Ähnlich wie im Sprichwort wächst die Architektur an den Herausforderungen. Wenn man als ArchitektIn dabei bleibt und regelmäßig die eigenen Entschlüsse und Vorgehensweisen hinterfragt, kann man daran mitarbeiten, eine Architektur wachsen zu lassen. Dabei ist es wichtig, auf die oben erwähnte Flexibilität der Architektur zu achten, damit man auch weiterhin auf Änderungen reagieren kann. Wenn dies alles erfüllt wird, kann es trotzdem vorkommen, dass eine Architektur den Anforderungen nicht mehr gerecht wird, weil sie beispielsweise in der Entwicklung nicht mehr skaliert und somit ein Team nicht mehr schnell genug neue Features implementieren kann. Wenn sich dann die Arbeitslast auch nicht gut auf mehrere Teams verlagern lässt, sollte man evtl. das System zerschneiden. Dafür bietet das Domain Driven Design gute und erprobte Methoden.
Wenn die Infrastruktur, oder besser: die Produktivumgebung, performancemäßig nicht mehr ausreicht, müssen andere Themen überdacht werden. Wenn am Anfang die richtigen Weichen gestellt wurden, wie z.B. eine Unabhängigkeit von der Datenbank, dann wird es nicht so schwer, eine komplette Infrastruktur auszutauschen. Dies kann unter Umständen in wenigen Wochen geschehen, indem z.B. eine LAMP-Applikation auf Docker migriert, in AWS EKS (gemanagter Kubernetesdienst) betrieben und an eine AWS Aurora (gemanagter Datenbankdienst auf Basis von MySQL oder PostgreSQL) gesetzt wird. Wenn man allerdings beispielsweise auf die Änderbarkeit des Dateisystems zum Speichern von Bildern gesetzt hat, kommt man hier in Bedrängnis, da man sich erst einmal Gedanken um ein alternatives Speichermedium machen muss, weil die virtuellen Container erst einmal kein dauerhaftes Dateisystem besitzen, welches über Neustarts hinweg Änderungen behält. Ein Grundsatz, den man dazu im Kopf behalten kann, ist die Anzahl von nicht revidierbaren Entscheidungen möglichst zu minimieren. Also sollte man, vereinfacht gesagt, möglichst immer einen Plan B in der Tasche haben. Wenn man z.B. bereits eine Lösung in der Tasche hat, die obigen Dateien in AWS S3 (Cloud Objekt- oder Dateispeicher) oder in einem anderen Speicher zu hinterlegen, hat man die Entscheidung für ein persistentes Dateisystem aufgeweicht oder umgangen. Dieser Plan B kann auch bedeuten, dass Themen, die bislang Teil der Mikroarchitektur waren, zu einem Thema der Makroarchitektur werden und somit weitreichendere Konsequenzen haben, wie z.B. personeller Natur. Deshalb ist es wichtig, regelmäßig einen Schritt zurück zu gehen, sich die Szenerie in einem Review anzuschauen und gegebenenfalls zu handeln. Um beim Beispiel der Dateien zu bleiben: es wäre sicherlich sinnvoll, eine Entscheidung für AWS S3 in die Makroarchitektur zu überführen, wenn mehrere Dienste, die von verschiedenen Teams bearbeitet werden, Dateien speichern müssen, und dieser Dateipool dann wiederum von einer dritten Partei, nämlich dem Infrastruktur-Betrieb, verwaltet werden soll. Eine einfache Regel dafür wäre zum Beispiel, dass alle Themen, die mehr als zwei Teams in ihrer Arbeit betreffen, Kandidaten für die Makroarchitektur sein könnten.
Das Warum
Die Frage nach dem “Warum?” ist an dieser Stelle eventuell schon überflüssig. Trotzdem möchte ich hier nochmal kurz auf die Gründe eingehen. Wir möchten die Weiterentwicklung unterstützen und damit natürlich das Entwicklungsteam. Dafür bieten sich die unterschiedlichen Rollen einer ArchitektIn an, um das Team an der richtigen Stelle weiterzubringen. Zu diesen Stellen gehören neben der eigentlichen Architektur selbstverständlich auch die Qualität, die Entwickelbarkeit des Quellcodes, aber auch die Entwicklungskosten und die Produktionsumgebung.
Fazit
Auch in der Softwarearchitektur halten agile Methoden Einzug und stellen das traditionelle Rollenbild auf den Kopf. Statt ständig planerisch tätig zu sein, wechseln agile SoftwarearchitektInnen zwischen verschiedenen Rollenbildern hin- und her und kommunizieren mit allen Projektbeteiligten auf unterschiedliche Art und Weise, gehen Herausforderungen auf verschiedene Weisen an und erfüllen somit Ihren Teil, um die jeweiligen Produkte nach vorne zu bringen.