Bessere Softwareentwicklung mit einer Architektur-Vision: So klappt’s

(Foto: Shutterstock)
Unter Big Design Up Front versteht man eine ausführliche Architektur-Phase, die vollständig und detailliert die zu erstellende Software in Papierform oder in Modellen dokumentiert, bevor die Umsetzung startet. Die Erfahrung zeigt, dass dieser Ansatz in den meisten Fällen nicht funktioniert. Die Ursachen dafür liegen bei unterschiedlichen Faktoren. Die zeitliche und personelle Trennung der Tätigkeiten führt zu einer unzureichenden Kommunikation zwischen Architekten und Entwicklern. Sowohl bei den Architekten, die später nicht an der Umsetzung beteiligt sind, als auch bei den Entwicklern, die die Architektur vorgesetzt bekommen, entsteht eine mangelnde Einbindung. Ein weiterer nicht zu unterschätzender Faktor ist die schwere Anpassbarkeit des mit viel Aufwand erstellten Architektur-Konzeptes an die tatsächlichen Anforderungen, die oft erst während der Umsetzung vollständig verstanden werden.

Ein guter Bauplan ist auch bei der Software-Architektur wichtig – Big Design Up Front muss es aber nicht immer sein. (Foto: Shutterstock)
Im Gegensatz dazu gibt es agile Teams, die sich ab dem ersten Sprint auf die Anforderungen stürzen und nach einigen Iterationen feststellen, dass es immer schwieriger und aufwändiger wird, das System zu erweitern. Bei dieser Vorgehensweise wird, als anderes Extrem, komplett auf Architekturarbeit verzichtet. Die Folgen sind ähnlich. Es fehlt an Kommunikation und Selbstbetroffenheit, denn über Architektur wurde gar nicht oder viel zu wenig geredet. Jeder Entwickler trifft seine Entscheidungen für sich und fokussiert sich auf die rasche Umsetzung der aktuellen Anforderungen. Auch hier ist es schwer, Änderungen an der Software-Architektur durchzuführen, da mit der Zeit ein schwer zu überschauendes Software-Konstrukt entsteht.
Konzipiere eine Architektur-Vision
Da stellt sich die Frage, wieviel Architekturarbeit geleistet werden muss? Und die Antwort lautet „gerade genug.“ Aber was ist gerade genug und wie gliedert sich dies in den Projektablauf ein?
Das Ziel von agiler Architekturarbeit ist es, sie aus dem Elfenbeinturm heraus in die Entwicklerteams zu tragen und diese dazu zu befähigen, sich regelmäßig um die Architektur zu kümmern. In Softwareprojekten gilt es, ständig Architekturentscheidungen zu erkennen und anschließend auch zu treffen. Dies kann nicht im Vorfeld außerhalb des Teams erfolgen. Dennoch bedarf es einer ersten grundlegenden Betrachtung der Architektur. Egal ob Neuentwicklung oder größere Erweiterung, eine Phase Null stellt den geeigneten Zeitraum für den Beginn der Architekturarbeit dar. Die ersten Ideen fließen in die Architektur-Vision ein und dienen als Startpunkt für die Entwicklung.
Die Architektur-Vision ist gekennzeichnet durch drei wesentliche Merkmale:
- Kurz: Die Architektur-Vision konzentriert sich auf das Wesentliche, gibt die Richtung vor und lässt Spielraum für Entscheidungen, die erst später getroffen werden müssen.
- Verständlich: Die Sichten der unterschiedlichen Zielgruppen werden berücksichtig (Entwicklung, Betrieb, QA, Product Owner …).
- Akzeptiert: Die Stakeholder stehen hinter der Vision. Dies erreicht man durch frühe Einbindung und am besten durch einen gemeinsamen Visions-Workshop.
Inhaltliche Bestandteile einer Architektur-Vision sind:
- Die Systemidee, die die Kernaufgabe, die Nutzung und Schnittstellen, das heißt den Kontext des zu erstellenden Systems aufzeigt.
- Einflussfaktoren und Randbedingungen, wie funktionale und nicht-funktionale Anforderungen, organisatorische und technische Einflüsse.
- Lösungsstrategien halten die ersten Entscheidungen, wesentliche Architektur-Muster und Konzepte fest.
- Erste Architektursichten können entstehen, um die Lösungsstrategien zu verdeutlichen.
Architektur-Visionen entstehen nicht im stillen Kämmerchen, sondern in Workshops mit Architekt(en), Entwicklern und den Stakeholdern. Dementsprechend entstehen die Ideen oft auf Flipcharts und Pinnwänden. Diese Materialien eigenen sich hervorragend, später im Teamraum aufgehängt zu werden. Dort können sie den Startpunkt für eine Architekturwand bilden, die im Projektverlauf ergänzt und aktuell gehalten werden. Natürlich ist es vor allem in größeren Projekten auch sinnvoll, die Informationen nachhaltiger in einer Architektur-Dokumentation festzuhalten. Ein wichtiger Aspekt ist jedoch auch hierbei, sich auf die wesentlichen Grundsätze und Prinzipien zu fokussieren. Diese ändern sich eher selten und halten damit den Pflegeaufwand niedrig, was letztendlich vor allem auch der Aktualität der Dokumentation dient.
Architektur-Kata als Trainingsform

Ist keine komplette Neuentwicklung möglich, bietet sich ein Architektur-Kata an. (Grafik: Roland Mast)
Leider bietet sich nicht allzu oft die Möglichkeit, Systeme komplett neu zu gestalten und wenn doch, dann sollte möglichst nichts schief gehen. Wie du dich darauf vorbereiten kannst? Dazu bietet sich eine Architektur-Kata an. Mit Hilfe einer kompakten Systembeschreibung wird in Kleingruppen eine Architektur-Vision in mehreren Iterationen erstellt. Die Ergebnisse werden nach jeder Runde gegenseitig präsentiert, um Feedback und neue Impulse zu erhalten. Hierbei wird ein Visions-Workshop zu Trainingszwecken nachgestellt und die Fertigkeiten und Vorgehensweisen trainiert. Dies sollte in einer möglichst cross-funktionalen Zusammensetzung erfolgen. Wichtig ist dabei, die Rolle des Produktverantwortlichen, der die Anforderungsseite vertritt. Damit wird nebenbei auch die wichtige Kommunikation und Auseinandersetzung mit den Fachabteilungen beziehungsweise Kunden trainiert.
Im Rahmen einer Speed-Kata am 22. Juni, um 11:45 Uhr auf der DWX 2016 kannst du deine eigene Erfahrung mit der Erstellung einer Architektur-Vision machen.
Über den Autoren
Roland Mast ist Software-Architekt und Entwickler bei der Sybit GmbH. Er beschäftigt sich hauptsächlich mit der Entwicklung von großen Web-Applikationen und E-Commerce-Lösungen. Dabei liegen ihm agile Werte und eine nachhaltige Architektur am Herzen.
„oftware“ – Erstes Wort im Subtitle. Kommentar kann dann gelöscht werden.