Alexander Kaserbacher
16.11.2022
Software-Entwickler:innen und -Architekt:innen arbeiten oft lange an ein und demselben System. Wie lässt sich Softwarearchitektur effektiv üben?
Vor seinem Durchbruch war Benjamin Franklin ein eher durchschnittlicher Schriftsteller. Selbst einer der bedeutendsten US-amerikanischen Autoren musste hart arbeiten, um in der Lage zu sein, Werke wie den “Poor Richard’s Almanack” oder “The Art of Virtue” zu verfassen. Um in seiner Fähigkeit, Artikel zu schreiben, besser zu werden, sammelte Benjamin Franklin Ausgaben der Zeitschrift “The Spectator”, die von 1711 bis 1712 von Joseph Addison und Richard Steele herausgegeben wurden und sich großer Beliebtheit erfreuten. Franklin nahm sich Artikel vor und fertigte detaillierte Notizen dazu an. Danach versuchte er, Artikel im Stil der Autoren nachzuschreiben und verglich seine Ausgabe mit dem Original. Das Ziel dieser Übung war, seinen Stil und seine Aussagekraft zu üben und zu perfektionieren.
Ich kann verstehen, warum Benjamin Franklin so vorgegangen ist. Versucht im Kopf mal folgende Frage zu beantworten: wie viele Systeme habt ihr als Entwickler:in oder Architekt:in fundamental (mit)entworfen? Üblicherweise treffen wir Architekturentscheidungen viel seltener als Entscheidungen auf Code-Ebene. Und der Feedback-Zyklus ist obendrein um vieles länger. Wenn wir Architektur als Disziplin sehen, die sich mit wichtigen Entscheidungen rund um ein Softwaresystem beschäftigt und wir diese Entscheidungen aber nicht üben können und nur selten Feedback dazu bekommen - wie wollen wir dann darin besser werden?
Architektur-Katas sind inspiriert von Coding-Katas, deren Ziel es ist, Softwareentwicklung durch Programmieraufgaben zu üben. Im Gegensatz zu Coding-Katas wollen wir hier das System aber nicht implementieren, sondern auf einer konzeptionellen Ebene entwerfen und diskutieren. Dieses Format bietet uns daher eine spannende und spielerische Möglichkeit, Softwarearchitektur zu üben.
Post-Its, Flipcharts, fertig? Nicht ganz. Nach einer Vorstellung der Problemstellung teilen wir uns bei Architektur-Katas in Gruppen auf. Jede Gruppe versucht eine mögliche Lösung zu entwerfen. Artefakte, die von den Teams produziert werden, sind entweder vorgegeben oder es ist Teil der Kata, die wichtigsten Artefakte zu identifizieren. Dabei handelt es sich oft um Domänenmodelle, Architekturüberblicke oder Architekturentscheidungen. Danach stellen die Gruppen ihre Lösungsansätze vor und diskutieren sie mit anderen Gruppen.
Neugierig? In meiner Session beim Architektur-Punsch zeige ich genauer, wie eine Kata für euch und eure Teams aussehen kann. Wir diskutieren, was ihr davon habt mitzumachen, aber auch wie ihr sie vorbereiten und moderieren könnt. Es geht darum, wie ihr vom linken zum rechten Bild kommt (die Bilder wurden bei einer Architektur-Kata aufgenommen):
Um euch in diesem Blogpost einen kleinen Vorgeschmack zu geben, zeige ich kurz, wie die Aufgabenstellung einer Kata aussieht. Eine Aufgabenstellung teilt sich in vier verschiedene Bereiche:
Der Detailgrad der Ausformulierung ist stark von Faktoren wie den Erfahrungen der Teilnehmer, aber auch vom gesteckten Zeitrahmen abhängig. Ihr findet hier beispielhaft zwei Aufgabenstellungen von Architektur-Katas, eine etwas ausführlicher beschrieben und eine etwas allgemeiner gehalten. Die Themen sind passend zum Architektur-Punsch gewählt ;-)
Hier klicken zum Download
Hier klicken zum Download
Noch mehr Anregungen erhaltet Ihr am 15. Dezember 2022 bei unserem Architektur-Punsch. Einfach anmelden! Neben meinem Vortrag zu diesem Thema gibt es dort viele weitere spannende Programmpunkte zu entdecken.