Architektur vs. Agile Software-Entwicklung

Liebe Leser,

angespornt durch einige Aussagen von Kollegen und Branchengrößen möchte ich meine Gedanken zur vermeintlichen Kontroverse von Software-Architektur und agiler Software-Entwicklung zum Besten geben.

Architektur
Mein generelles Verständnis zur Definition von Software Architektur habe ich bereits in einem früheren Blogpost beschrieben.

Agile Software-Entwicklung
Unter agiler Software-Entwicklung verstehe ich kein konkretes Vorgehensmodell. Ich bin der Überzeugung, dass man Agilität auf unterschiedlichste Art und Weise in der Praxis ausleben kann. Sei dies in Form von XP, Scrum, Kanban, einem weniger verbreiteten Modell oder einfach nur der individuellen Mixtur aus mehreren davon. Persönlich kann ich jedem der namentlich genannten Vorgehensmodelle etwas abgewinnen. Wie schon oft zitiert ist das Agile Manifesto die Wurzel all dieser Ausprägungen.

Die beiden Extreme
Zwei extreme Einstellungen sind in Bezug auf diese Kontroverse durchaus verbreitet:

1) Wir arbeiten agil und können daher keine Architektur vorhab festlegen.
2) Wir legen unsere Architektur vorab fest und können daher nicht agil arbeiten.

Diese Extreme sind meiner Ansicht nach schlicht weg falsch! Natürlich sind beide Themen unter einen Hut zu bringen. Eine einfach klingende Regel, die allerdings nicht so leicht in die Praxis umzusetzen ist, sollte lauten: So wenig Architektur wie möglich und so viel wie nötig.

Wie kommt es zu diesen Extremen?
Warum glauben dennoch viele Agilisten, dass Architektur nicht zur Agilen Software-Entwicklung passt? Ich denke, dies ist fälschlichen Interpretationen geschuldet. Kent Beck hat in seinem Buch "Extreme Programming Explained: Embrace Change" den Begriff "YAGNI" geprägt. YAGNI steht für "You aren't / ain't gonna need it" und bedeutet, dass man nicht alle Möglichkeiten und Varianten vorab berücksichten, sondern lediglich die vorhanden Anforderungen umsetzen soll. Dies vor dem Hintergrund, da nicht bekannt ist wie sich ein System - basierend auf ändernden Anforderungen - in Zukunft entwickeln wird. So wie auch viele das agile Manifest fälschlich interpretieren (aber das ist eine andere Geschichte), so wird auch dieser Begriff meiner Meinung nach oft zu hart ausgelegt. Das YAGNI-Prinzip hat in der Feature-Entwicklung seine Berechtigung, darf aber nicht auf den gesamten Software-Entwicklungsprozess umgelegt werden.

Meiner Ansicht nach sind die grundlegende System-Architektur und die notwendigen Design-Entscheidungen vorab festzulegen und können nicht laufend anhand von Anforderungen angepasst werden. Die Betonung liegt hier auf dem Wort "grundlegend". Ein gewisses Maß an Flexibilität ist durchaus wünschenswert und gerade durch eine vorab durchdachte Architektur gewährleistet. Ein einfaches Beispiel soll die Notwendigkeit von Architektur und Design-Entscheidungen veranschaulichen:

Bei der Umsetzung einer konkreten Anforderung wird festgestellt, dass gewisse Daten persistiert werden müssen. Ohne zuvor festgelegte Architektur bzw. grundlegende Design-Entscheidungen kann es nun sehr schnell passieren, dass ein momentan passend wirkender Datenspeicher - nehmen wir eine relationale Datenbank an - eingeführt wird. Die Persistenz wird, weil es gerade zur Anforderung passt, als Active Record Pattern umgesetzt. Im Zuge der späteren Entwicklung stellt das Team fest, dass die aktuellen Persistenzobjekte besser als Domain Entities konzipiert gewesen wären und für die Datenpersistenz ein Repository Pattern Ansatz auch brauchbarer wäre. Ich wage zu behaupten, dass man in diesem Fall vor einem nicht unwesentlichen und aufwändigen Refactoring stünde, welches die Grundfesten des gesamten Systems erschüttern würde.

Warum glauben Architektur Hardliner, dass agile Vorgehen nicht anwendbar sind? Einerseits vermute ich, dass dies einem Umkehrschluss aus der agilen Extremeinstellung zuzuschreiben ist (Architektur passt nicht zu einem agilen Vorgehen - s.o.). Andererseits kann am Beispiel von Scrum auch wieder eine Misinterpretation oder zu strikte Auslegung des Vorgehensmodells zu dieser Ansicht führen. Scrum gibt einen Rahmen vor, welcher natürlich absichtlich sehr offen gehalten ist. Es gibt defacto keine Design-Phase. Warum sollte man dennoch nicht in der ersten Iteration auch die Architektur gestalten? Auch wenn es in der Scrum-Community eine Diskussion zu "Sprint Zero" gibt, ist es in meinen Augen alternativ durchaus legitim eine Initialisierung vorab der Featureimplementierung in einer eigenen Iteration auf Basis des bekannten Product Backlogs durchzuführen. Man sollte ausserdem nicht vergessen, dass Scrum-Projekte mit Planning Meetings beginnen in denen nicht ausschließlich die Anforderungen besprochen werden, sondern auch die gesamte Vision im Mittelpunkt steht. Auf Basis der Anforderungen und der Produktvision kann man auch eine Architektur(vision) ableiten.

Mein Fazit
Die Ära der voll durchgeplanten und bis ins letzte Detail designten Software-Systeme ist vorbei. BDUF (Bug Design Up Front) sollte vermieden werden. Software-Architektur darf allerdings auch in einer zunehmend agilen Software-Entwicklungswelt dennoch nicht zu locker gesehen oder gar gänzlich vernachlässigt werden, da einem sonst die vermeintlich günstig erkaufte Flexibilität schnell sehr teuer kommen kann. Der Weg liegt wie so oft in der Mitte und diesen zu finden ist mitunter Aufgabe von agil denkenden Software-Architekten. Ob die Rolle des Architekten nun im Team gemeinschaftlich wahrgenommen wird, ein Teammitglied dazu auserkoren wird oder ein konsultierender Architekt dem Team zu Beginn zur Verfügung gestellt wird soll an dieser Stelle nicht weiter behandelt werden. Software-Architektur ist auf jeden Fall weiterhin ein wichtiger Bestandteil in der Software-Entwicklung, auch wenn sich die Umwelt durch agile Vorgehensmodelle geändert hat.

Euer,
JL@coopXarch

These zur mangelnden Investitionsbereitschaft in Software Qualität betrieblicher Informationssysteme

Liebe Leser!

Sperriger Titel, aber folgender Gedanke beschlich mich beim morgendlichen Zähneputzen:

These:

Investitionsbereitschaft in Software Qualität ist reziprok proportional zum zeitlichen Abstand des Eintritts eines - kausal auf ein Qualitätsproblem folgendes - negativen Ereignisses, dessen Eintrittswahrscheinlichkeit und dessen Auswirkung.

Argumentation anhand von Beispielen (die angeführten Zahlen sind meine persönlichen Annahmen):

Softwareversagen im Bereich Avionik:

Zeitlicher Abstand -> wenige Minuten

Negatives Ereignis -> Absturz

Eintrittswahrscheinlichkeit -> nahezu 100%

Auswirkung -> Multiple Todesfälle nahezu 100%

Softwareversagen im Bereich Automotive:

Zeitlicher Abstand -> wenige Sekunden

Negatives Ereignis -> Unfall

Eintrittswahrscheinlichkeit -> ca. 50%

Auswirkung -> Tod zu 40%, Verletzung zu 60%

Softwareversagen im Bereich betrieblicher Informationssysteme:

Zeitlicher Abstand -> Stunden, Tage, Monate, Jahre

Negatives Ereignis -> Fehler, verletzte Datenintegrität und Konsistenz, Datenverlust, Finanzieller Verlust, überproportional steigende Wartungskosten

Eintrittswahrscheinlichkeit -> ca. 99%

Auswirkung -> Imageschaden, finanzieller Schaden, Kundenunzufriedenheit, Haftungen (bis hin zur Haftstrafe)

Interpretation:

Trotz hoher Eintrittswahrscheinlichkeit eines negativen Ereignisses ist der zeitliche Abstand in vielen Fällen derart groß, dass eine Investitionsbereitschaft stark gebremst wird, noch dazu, wo die Auswirkungen nicht als lebensbedrohlich gewertet werden und Folgen wie mögliche Haftungen oft nicht transparent sind.

Ergo: 

Um die Investitionsbereitschaft zu steigern, müssen die möglichen Auswirkungen transparenter dargestellt werden, um Entscheidungsträger nach dem Kosten-Nutzen Prinzip geeignet aufzuklären. Eine Darstellung des Ablaufs im Zeitraffer ist anzuraten, um dem Gefühl der „Sicherheit aufgrund eines ausreichenden zeitlichen Puffers“ entgegen zu wirken. Geeignete Simulationsmodelle sind auszuarbeiten.

Einen sonnigen Juni wünscht

Euer 

JWR@coopXarch.