Architekturentscheidungen in agilen Projekten

Was mache ich als Architekt in einem agilen Team, wenn wir im Sprint 1 vor der Entscheidung stehen, welches Architekturmuster oder welche Technologien wir einsetzen und wir innerhalb des Sprints entscheiden wollen? Einfach machen und dann refactoren? Und wenn es verschiedene Ansichten gibt, wie wir es machen können?

Das fiktive Projekt

Als Fallstudie wird ein fiktives Projekt betrachtet. Das Unternehmen ist eine Bank, die Ihren Kunden in stärkerem Maße digitale Prozesse anbieten möchte und deswegen das Projekt „Digitale Darlehensbeantragung” aufgesetzt hat. Das Ziel ist eine digitale Antragsstrecke für den Endkunden, über den Privatkredite bis zu einer gewissen Höhe voll automatisiert beantragt und bewilligt werden können. Das Projekt soll agil mit der Scrum-Methode durchgeführt werden. Zum Projektteam gehört auch ein Software-Architekt, der die Entwickler zu Technologien, Architekturmustern und Anwendungsdesign beratend unterstützen soll.

Sprint 1

In einem vorgeschalteten Kickoff[1] tauscht sich das Team über die fachlichen Skills aus und benennt diverse Technologien, die es beherrscht, um die Stories umzusetzen. Das Team legt sich darauf fest, alle Entscheidungen einstimmig zu treffen. Der Product-Owner erläutert die Vision und hat im Vorfeld ein initiales Backlog angelegt. Er startet am ersten Tag des ersten Sprints im Planning mit der Erläuterung der ersten Story, die eine erste rudimentäre Maske für den Kunden zum Ziel hat, mit der ein Darlehensantrag nur mit Feldern für die Darlehenshöhe, die Rückzahlungsdauer, Vor- und Nachname des Kunden angelegt werden kann. Schnell kommt eine Diskussion auf, was die Anlage im technischen Sinne bedeutet und ob die eingegebenen Daten bereits in einer Datenbank gespeichert werden sollen? Und wenn ja, in welcher? Und überhaupt, mit welchem Framework soll die Oberfläche entwickelt werden, da vom Team mehrere Technologien wie Angular oder Vaadin beherrscht werden. „Wir sollten aber lieber auf React setzen, das ist die Zukunft”, äußert sich ein Entwickler, woraufhin der Nächste einhakt mit: „Nein, Vue.js ist viel besser, auf der JCON habe ich einen super Vortrag dazu gehört.” Da die Fachbereichsvertreter im cross-funktionalen Team nur böhmische Dörfer verstehen, versuchen Sie die Diskussion auf die Inhalte zu lenken und werfen ein: „Mit nur drei Feldern können wir keinen Antrag aufnehmen, mindestens das Geburtsdatum fehlt da noch. Und die Adresse. Und noch diverse Angaben zur Risikoeinschätzung”. Dadurch fühlt sich der Business-Analyst angesprochen und weist darauf hin, dass man zuerst ein Datenmodell entwerfen müsse. Vorher stellt sich die Technologiefrage noch gar nicht.

Glücklicherweise hat das Team einen agilen Coach zur Seite, der interveniert und erklärt, dass die erste Story bewusst ein schmaler Durchstich sein soll, der sich mit minimalen Inhalten dem ersten Teil des Gesamtprozesses annähert. Er moderiert die gemeinsame Klärung im Team, wie viele Datenfelder die Story umfasst: nämlich vier. Außerdem ergänzt er gemeinsam mit dem Team zwei Akzeptanzkriterien, dass die eingegebenen Daten in einer beliebigen Form dauerhaft gespeichert werden sollen und dass die Story an dem Punkt im Prozess endet und keine weitere Verarbeitung der Daten beinhaltet. Ein Datenmodell kann ein Ergebnis sein, wenn das Team der Meinung ist, dass es für die kleine Menge von Feldern sinnvoll ist. Zur Auswahl der Technologien weist er auf die Kompetenz des Teams und den festgelegten Entscheidungsprozess hin, mit der Anmerkung, dass für Nichttechniker eine Enthaltung durchaus akzeptabel ist. Dann leitet er zur ersten Schätzrunde im Planning-Poker über, da keine Verständnisfragen mehr zum Inhalt der Story auftauchen.

Die Schätzungen weichen extrem voneinander ab, gehen von 2 bis 40 Punkten und es gibt auch mehrere Teammitglieder, die keine Schätzung abgeben können. Nach einer kurzen Diskussion wird klar, dass vor allem die Entwickler eine sehr hohe Unsicherheit bezüglich der Umsetzung verspüren, da noch keine Architektur festgelegt wurde. Moderiert durch den Architekten arbeitet das Team das Schichtendiagramm (Abb. 1) heraus, in dem die potenziellen Technologien aufgeführt sind, die das Team beherrscht oder für gute Kandidaten hält. Dabei treten verschiedene Ansichten durch die unterschiedlichen Skills zutage. Es wird schnell klar, dass die Konsensbildung zur Architektur und Technologieauswahl in dem neu zusammengestellten Team nicht innerhalb des Plannings möglich ist. Begleitet von großen Bedenken einigt sich das Team auf eine Schätzung von 8 Story-Points und darauf, dass nur diese erste Story für den Sprint 1 ausgewählt wird, um Raum für die Basisarbeiten und sorgfältig getroffene Entscheidungen zu lassen.

Schichtendiagramm mit möglichen Technologien. (Abb. 1)

Zurück zu Sprint 0?

Ernüchtert von der geschilderten Erfahrung im Sprint 1 der Fallstudie mag das Bedürfnis aufkommen, die Architektur bereits im Vorfeld im Rahmen eines sogenannten Sprint 0 oder einer Vorstudie festzulegen. Es gibt in der Literatur beschriebene Verfahren zur Architekturbewertung wie die Architecture-Tradeoff-Analysis-Method (ATAM)[2], die in einem detaillierten Prozess die Geschäfts- und Architekturziele in Einklang bringen sollen. Dazu werden unter Einbeziehung der Stakeholder konkrete Qualitätsmerkmale definiert und die Architektur hinsichtlich praktischer Szenarien analysiert und qualitativ bewertet.

Unabhängig davon, ob man der beschriebenen Methode folgt oder nach eigenen Ansätzen arbeitet, tritt bei Vorstudien häufig das Problem auf, dass eine Gesamtarchitektur für den gesamten Projektverlauf festgelegt werden soll, obwohl die Anforderungen gerade den Entwicklern zu diesem Zeitpunkt so gut wie gar nicht bekannt sind. Es gibt einen großen Entscheidungsspielraum und viel Unschärfe, die erst im Projektverlauf abnehmen. Die tatsächliche Lösung am Projektende weicht häufig deutlich von der geplanten Lösung zu Projektbeginn ab (Abb. 2). Schnell kommen dabei auch Fragen zur Priorisierung der Anforderungen auf, die im Vorfeld des Projekts nur getroffen werden können, wenn der agile Wert „Reagieren auf Veränderung”[3] verletzt wird. Für ein agiles Projekt kann eine Vorstudie nicht empfohlen werden, die ein größeres Ziel verfolgt, als alle technischen Fragen zur Umsetzung der Stories im Sprint 1 zu klären. Die Vorstudie wird zwar sicherlich Ergebnisse für einen Teil der Fragestellungen liefern, aber ob diese Ergebnisse in den ersten Sprints überhaupt relevant werden, ist nicht sichergestellt. Genauso wenig, wie die Qualität der Ergebnisse ohne den inhaltlichen Austausch über die Anforderungen in einem cross-funktionalen Team gewährleistet werden kann. In der agilen Softwareentwicklung ist es ein Trugschluss zu glauben, man könne ex ante die komplette Architektur eines Systems am Reißbrett entwerfen und damit den gewünschten Funktionsumfang vollständig abdecken[4].

Entscheidungsspielraum und Unschärfe in Projekten[5]. (Abb. 2)

Es gibt verschiedene Möglichkeiten der Problemstellung zu begegnen, dass die Architektur begleitend zum System aufgebaut wird. Um der fachlichen Priorisierung zu entsprechen, können die Architekturanalysen oder Technologieentscheidungen auf den spätestmöglichen Zeitpunkt verschoben werden, sobald die Notwendigkeit zur Umsetzung in einer Story gegeben ist. Dann werden die Analysen und Entscheidungen in eine passende fachliche User-Story integriert. Bei Entscheidungen mit größerer Tragweite ist eine Architektur-Bugwelle[6] empfehlenswert, die alles zusammenfasst, was für die Spitze des Backlogs in den nächsten Sprints relevant ist. Die entsprechenden Aufgaben können bei skaliert agilen Projekten durch ein eigenes Architekturteam[7] bearbeitet werden. Allerdings sind auch temporär gebildete Task-Forces aus Mitgliedern mehrerer Scrum-Teams durchaus empfehlenswert, da die getroffenen Entscheidungen Auswirkungen auf alle oder zumindest mehrere Teams haben. Im Rahmen der Bugwelle kann dann vorbereitete Forschung und Entwicklung stattfinden, welche Optionen zur Umsetzung der Stories zur Verfügung stehen, die idealerweise durch einen Prototypen nachgewiesen werden. Jeder Prototyp sollte dabei groß genug sein, um aussagekräftig zu sein, aber auch klein genug, damit die investierten Aufwände bei einer anderen Entscheidung keinen Hemmschuh aufgrund des Effekts der versunkenen Kosten darstellen.

Architekturen mit der SWOT-Analyse bewerten

Um verschiedene Optionen für die Architektur zu bewerten und die Architekturentscheidung zu treffen und zu begründen, kann die SWOT-Analyse als Methode zur Unterstützung herangezogen werden, die Stärken (strengths), Schwächen (weaknesses), Chancen (opportunities) und Risiken (threats) der Architekturoptionen expliziert. Die SWOT-Analyse ist ursprünglich ein Instrument der strategischen Planung und dient der Positionsbestimmung und der Strategieentwicklung von Unternehmen sowie anderer Organisationen[8].

Beispiel einer SWOT-Analyse für eine Sandburg. (Abb. 3)

Angewendet auf Architektur – in (Abb. 3) am Beispiel einer Sandburg am Strand – entsprechen die Stärken, wie z.B. die flexible Bauweise, objektiv positiven, inhärenten Eigenschaften einer Sandburg. Demgegenüber stehen die Schwächen, die manch eifriger Sandburgenbauer am eigenen Leib erfahren musste, dessen Burg vom Winde verweht wurde. Bei den Chancen und Risiken geht der Blick über den Tellerrand, d.h. über die Eigenschaften der Sandburg selbst hinaus. Diese externen Faktoren schließen die Umwelt ein und entsprechen möglicherweise eintretenden Ereignissen, wie einem ständigen Ausbau im positiven Fall bei gutem Wetter, oder der Zerstörung durch eine unerwartet hohe Flutwelle im negativen Fall.

Im Gegensatz zu einfachen Vergleichen mit Positiv-/Negativlisten trennt die SWOT-Analyse zwischen einer (Team-/Unternehmens-)internen Analyse und externen Faktoren. Die internen Stärken und Schwächen entsprechen durch Erfahrung belegte Fakten, die das Team gut einschätzen kann. Demgegenüber basieren die Chancen und Risiken der externen Analyse sehr stark auf Annahmen, die durch Ausprobieren der Architekturoption validiert werden müssen. Diese beiden Aspekte zu trennen erleichtert die Bewertung durch das Team und die Erläuterung und Begründung für den Product-Owner oder die Stakeholder und vermeidet eine Vermischung von Fakten und Annahmen. Als Nebeneffekt kann ein klarer Auftrag abgeleitet werden, welche Chancen oder Risiken in einem der nächsten Sprints konkret untersucht werden sollen. Bei den Kriterien zur Bewertung der Architektur sollte man sich in erster Linie an den nichtfunktionalen Eigenschaften oder Qualitätsmerkmalen wie Bedienbarkeit, Performanz, Flexibilität und Wartbarkeit orientieren. Dadurch bekommen oft langwierige Architekturdiskussionen einen klaren Fokus.

Die SWOT-Analyse stiftet darüber hinaus einen sozialen Nutzen für das Team, sofern sie gemeinsam erarbeitet wird. Die Erstellung der Analyse fördert den Wissensaustausch und die Konsensbildung im Team und am Ende steht (hoffentlich) eine gemeinsame Teamentscheidung, bei der einzelne Meinungen sowohl als Chance oder auch Risiken Einfluss auf das Ergebnis haben. Diese Art der Entscheidungsfindung im Gegensatz zur einsamen Entscheidung eines Architekten ist zwar anstrengend, aber langfristig wertvoll für die Akzeptanz im Team und die Selbstorganisation des Teams.

SWOT-Analyse zur Entscheidung zwischen Varianten

Für die Fallstudie der Darlehensbeantragung haben sich die Entwickler und der Architekt im Scrum-Team direkt nach dem Planning für einen Workshop zurückgezogen und zwei Varianten für den grundlegenden Architekturansatz erarbeitet. Das Team besteht ausschließlich aus Java-Entwicklern, die überwiegend mit Spring und Java-EE gearbeitet haben und nur rudimentäre Kenntnisse in JavaScript-Frontends und Microservice-Technologien besitzen. Die beiden Varianten in Form eines Java-Monolithen und einer Microservice-Architektur mit JavaScript-Frontend und Java-Backend sind in (Abb. 4) dargestellt. Für beide Varianten erstellt das Team gemeinsam eine SWOT-Analyse, siehe (Abb. 5) und (Abb. 6).

Varianten für den grundlegenden Architekturansatz. (Abb. 4)

SWOT-Analyse für den Java-Monolithen. (Abb. 5)

SWOT-Analyse für die Microservice-Architektur (Abb. 6)

Die Ergebnisse der SWOT-Analysen erheben keinen Anspruch auf universelle Gültigkeit für die beiden Architekturansätze – ganz im Gegenteil wird jedes Team zu einer eigenen Bewertung kommen. Insbesondere die qualitative Bewertung im Rahmen der Abwägung zwischen Stärken und Schwächen sowie Chancen und Risiken kann nur jedes Team angewandt auf seine eigene Situation zielgerichtet durchführen. Gerade bei den Risiken der Microservice-Architektur fällt auf, dass diese ausschließlich auf den fehlenden Erfahrungen des Teams mit Microservice-Technologien resultieren. Aus der SWOT-Analyse lässt sich kein direktes Ergebnis für eine der beiden Varianten ablesen, sondern die Entscheidung muss vom Team durch die Bewertung der einzelnen Einträge in der SWOT-Matrix getroffen werden. Dabei sind die Stärken der einen Variante oft die Schwächen und Risiken der anderen Variante und umgekehrt. Die Methode kann, wie alle anderen Methoden auch, keine Entscheidung fällen, sondern nur die Entscheidungsfindung erleichtern. Als weiterer Mehrwert können die Chancen und Risiken zur Formulierung von Prüfaufträgen zur retrospektiven Bewertung der Architekturentscheidung nach Abschluss eines Prototypen oder nach mehreren Sprints genutzt werden.

In der fiktiven Fallstudie entscheidet sich das Team für den Java-Monolithen, da sowohl für die Schwächen als auch die Risiken von einer sehr geringen Eintrittswahrscheinlichkeit ausgegangen wird und die Chancen der hohen Entwicklungsgeschwindigkeit zu Beginn den Wunsch der Stakeholder nach schnellen Erfolgen unterstützt. Am Ende der ersten beiden Sprints, nachdem der erste Durchstich als Prototyp mit der gewählten Architektur umgesetzt ist, führt das Team eine dedizierte Architekturretrospektive zur Überprüfung der SWOT-Analyse durch. Da die Chancen realisiert werden konnten und die Risiken nicht eingetreten sind oder durch entsprechende Gegenmaßnahmen adressiert wurden, wird an der gewählten Architektur festgehalten.

SWOT-Analyse zur Bewertung neuer Optionen

Ein paar Sprints später ist die Darlehensbeantragung für die wichtigsten Anwendungsfälle implementiert und das Team hat angefangen, die Darlehensbewilligung umzusetzen. Im ersten Schritt wurde die Bewilligung als manueller Prozess im Java-Monolithen umgesetzt. Im Backlog-Refinement stellt der Product-Owner die Bonitätsprüfung des Kunden als ersten automatisierten Schritt der Bewilligung als eine der nächsten Stories vor. Die Bonitätsprüfung soll einerseits intern bestehend auf gesammelten Daten des Kunden mit Künstlicher Intelligenz und andererseits durch Anfragen bei externen Bonitätsdienstleistern erfolgen. Schnell entsteht eine technische Diskussion, welche Technologie für die Integration einer Künstlichen Intelligenz (KI) die Richtige ist, da zwei Teammitglieder erste Erfahrungen mit der API von H2O[9] und der Integration KI in Geschäftsprozesse mit bpmn.ai[10] gesammelt haben. Auch über die Anbindung der REST-Services externer Dienstleister und die richtige Architektur und Technologie dafür wird fleißig diskutiert. Das Team einigt sich darauf, die Stories erstmal zurückzustellen und zuerst eine SWOT-Analyse für die Architektur der Bonitätsprüfung durchzuführen.

Architekturskizze für die Bonitätsprüfung. (Abb. 7)

Als Vorbereitung erstellt das Team erneut eine Architekturskizze, um ein gemeinsames Verständnis herzustellen und eine Ausgangsbasis für die Bewertung zu haben (Abb. 7). Dabei entsteht schnell der Ansatz, die Prüfung der Bonität und die Abfrage bei externen Dienstleistern als REST-Services zu kapseln, die im Bewilligungsprozess eingebunden werden können. Für die Implementierung der KI wird die Integration der H2O-API favorisiert, da diese am Markt etabliert ist und die fachlichen Anforderungen gut abdeckt. Da keine direkten Alternativen in der Diskussion entstehen und die Grundidee von allen geteilt wird, geht das Team direkt zur Bewertung des skizzierten Architekturentwurfs über (Abb. 8) und verständigt sich darauf, erst bei der Identifikation hoher Risiken über weitere Optionen nachzudenken. Da die Risiken beherrschbar erscheinen und für das Team weniger stark ins Gewicht fallen als die Stärken und Chancen, fällt die Entscheidung für den skizzierten Ansatz der Microservices für die Bonitätsprüfung. Als Gegenmaßnahme für die Risiken verständigt sich das Team auf einen eintägigen Hackathon, um die API der KI-Technologie auszutesten und das Wissen im gesamten Team zu verteilen. Die Gegenmaßnahme wird in Abstimmung mit dem PO als Akzeptanzkriterium für die Stories formuliert.

SWOT-Analyse für die Bonitätsprüfung. (Abb. 8)

Fazit

Die SWOT-Analyse ist eine geeignete Methode, um Architekturoptionen zu bewerten, bevor eine Entscheidung getroffen wird. Aufgrund ihres allgemeinen Charakters skaliert sie für Entscheidungen zwischen zwei Personen für eine konkrete Technologie bis zu ganzen Teams für den übergreifenden Architekturstil. Die Trennung zwischen einer internen und externen Analyse lässt sich für Architekturfragestellungen auf die Dimensionen bekannter Fakten basierend auf gemachten Erfahrungen und Annahmen, die validiert werden müssen, umdeuten. Damit strukturiert die SWOT-Analyse die Einschätzungen im Team und öffnet neue Perspektiven. Trotz alledem kann die Methodik der SWOT-Analyse den kreativen Prozess in einem agilen Team nur unterstützen. Architektur ist eine Herausforderung mit vielen Grautönen und die Entscheidung muss das Team treffen. Das Analyseergebnis dient einerseits als Begründung für den Product-Owner und die Stakeholder und hilft andererseits, die Chancen und Risiken explizit zu machen, die durch Prototypen validiert werden sollten. Dabei sollte das Team auch den Mut zur richtigen Reaktion auf Veränderungen zeigen, wenn z.B. die Chancen überschätzt wurden, und die getroffenen Entscheidungen hinterfragen und bei Bedarf revidieren.

Und schließlich sollten agile Teams einen gesunden Pragmatismus an den Tag legen, da Architektur manchmal in den Rang einer exakten Geheimwissenschaft erhoben wird, die nur wenige Auserwählte perfekt beherrschen. Tatsächlich beschreibt der Tweet „Warum nennen wir es eigentlich Softwarearchitektur und nicht „Permanenter Kompromisszwang unter verschieden großen Übeln mit langzeitiger Kollektivschuldübernahme?“[11] viel besser die Realität in der Entscheidungsfindung zur Architektur vieler Anwendungen, die unter ständigem Kosten- und Zeitdruck permanent weiterentwickelt werden. Durch die Anwendung der SWOT-Analyse zur Unterstützung der Entscheidung kann aber trotzdem die nötige Professionalität an den Tag gelegt werden, die Übel zu bewerten und die Kompromisse explizit zu machen.

Links/Quellen/Verweise:

1. Nicole Neunhöffer, Kay Hildebrand: “viadee Tutorial #1: Kickoff für Scrum-Teams”, https://blog.viadee.de/kickoff-fuer-scrum-teams
2. Gernot Starke: “Effektive Softwarearchitekturen”, Hanser, 2014
3. Kent Beck et al.: “Manifest für Agile Softwareentwicklung”, https://agilemanifesto.org/iso/de/manifesto.html
4. Kay F. Hildebrand, Tobias Voß: „Der agile Architekt ist ein Bauingenieur“, ObjektSpektrum 6/2017.
5. Übernommen aus Gernot Starke: “Effektive Softwarearchitekturen”, Hanser, 2014
6. Scaled Agile Framework (SAFe): „Architectural Runway“, https://www.scaledagileframework.com/architectural-runway/
7. Scrum Nexus Framework: „The Nexus Integration Team“, https://www.scrum.org/resources/nexus-integration-team
8. Wikipedia: „SWOT-Analyse“, https://de.wikipedia.org/wiki/SWOT-Analyse
9. https://www.h2o.ai
10. https://www.bpmn.ai
11. Stefan Pfeiffer, https://twitter.com/spfeiffr/status/1065639195685867520