Architektur-
Dojo
Mit Katas zur Entwicklung von Systemarchitekturen
17. März, 2023 / Moritz Deißner & Anusch Athari
Softwareentwicklung ist eine Fähigkeit, die ständig trainiert und weiterentwickelt werden muss. Eine Methode, die wir bei Turbine Kreuzberg erfolgreich einsetzen, sind Coding Katas. Vor kurzem haben wir die Kata-Methode auf die Entwicklung von Systemarchitekturen angewendet, um die Fähigkeiten unseres Teams in diesem Bereich zu erweitern.
Werfen wir zunächst einen Blick auf die Kata-Methode an sich. Wen der Name an Kampfsport erinnert, liegt goldrichtig. Der Begriff »Kata« stammt aus dem Japanischen und bedeutet »Form«. In der Kampfkunst bezieht er sich auf Bewegungsmuster, die wiederholt geübt werden, um das Muskelgedächtnis aufzubauen und die eigenen Fähigkeiten zu perfektionieren. Coding Katas funktionieren ähnlich: Es handelt sich in der Regel um kleine Übungen, bei denen Entwickler:innen mit einer Programmiersprache ein Feature entwickeln oder sie nutzen müssen, um ein sehr spezifisches Problem zu lösen. Solche Training-Sessions helfen, die eigenen Fähigkeiten durch Übung und Wiederholung zu verbessern. Mit Katas kann man alle möglichen Fähigkeiten erlernen – geeignete Beispiele finden sich überall im Netz. Ein guter Ausgangspunkt ist die Katas-Liste von Dave Thomas oder das awesome-katas-Repository von Gabe Montalvo.
Katas-Übungen werden in der Regel im Rahmen einer Schulung und nicht als Teil eines realen Projekts durchgeführt. Sie können sowohl eigenständig oder als Gruppenaktivität durchgeführt werden. Letzteres hat natürlich den zusätzlichen Vorteil, dass es den Teilnehmern die Möglichkeit gibt, Wissen auszutauschen und voneinander zu lernen.
Neben dem Schliff der eigenen Programmierkunst kann die kontinuierliche Anwendung von Katas dazu beitragen, auch viel mehr über Softwareentwicklung im Allgemeinen zu lernen. Dazu zählen beispielsweise:
- Grundlegende Designprinzipien und -muster: Entwickler:innen können sich mit den grundlegenden Prinzipien und Mustern vertraut machen, die bei der Software-Konzeption verwendet werden, und deren Anwendung auf strukturierte Weise üben.
- Technologie- und Framework-Auswahl: Entwickler:innen können lernen, wie sie die für ein bestimmtes Projekt am besten geeigneten Technologien und Frameworks auswählen, auch unter Berücksichtigung von Faktoren wie Leistung, Skalierbarkeit und Wartbarkeit.
- Zerlegung eines Systems in Komponenten und Dienste: Entwickler:innen können lernen, wie man ein System in kleinere, besser handhabbare Teile aufteilt, und können die Anwendung von Techniken wie Modularität und »Separation of Concerns« üben
- Abwägen von Kompromissen und Treffen von Entwurfsentscheidungen: Entwickler:innen können lernen, die Vor- und Nachteile verschiedener Designoptionen abzuwägen, und können üben, fundierte Entscheidungen über das Design eines Systems zu treffen.
Im Allgemeinen sollten Katas so strukturiert sein, dass sie der übenden Person ein klares und genau definiertes Problem bieten, das es zu lösen gilt. Sie enthalten eine spezifische Problemstellung mit genügend Kontextinformationen, klare Ziele und Grenzen, eine Reihe konkreter Tasks, die zu bearbeiten sind, und Kriterien, anhand derer das Team die erarbeitete Lösung bewerten kann.
Überzeugt? Okay, dann werfen wir einen Blick auf unser Workshop-Experiment.
Von Coding zur Architektur Katas
Es lässt sich schon ahnen, worauf das alles hinausläuft. Wir haben uns gefragt: Was wäre, wenn wir die Kata-Methode nicht nur zum Programmieren, sondern auch zur Entwicklung nutzbarer Systemarchitekturen nutzen würden? Unsere Arbeit bei Turbine Kreuzberg verlagert sich immer mehr in das Herz der digitalen Landschaften von Unternehmen. Immer öfter entwickeln wir maßgeschneiderte Enterprise Applikation von null an. Deshalb ist es wichtiger denn je, unsere Fähigkeiten im Aufbau von Systemarchitekturen breit im Team zu verankern.
Wie in so vielen Dingen bei Turbine Kreuzberg sind wir iterativ nach Trial-and-Error-Methode vorgegangen. Deshalb haben wir eine Reihe von Katas-Workshops ins Leben gerufen, in denen Teams den Entwurf einer plausiblen Systemarchitektur für einen vordefinierten Anwendungsfall üben sollten. Dabei ging es natürlich weniger um die resultierende Architektur als vielmehr darum, das Vorgehen zu lernen. Zu unseren Hauptzielen gehörte es, die Fähigkeiten der Teilnehmer beim Architekturdesign zu verbessern, denjenigen Entwickler:innen, die mit Architekturdesign bisher nur wenig vertraut waren, mehr Einblick zu geben, und einen Raum für Wissensaustausch zu schaffen.
Unsere Motivation war, Entwickler:innen durch das Proben von Design-Entscheidungen in einer sicheren Umgebung besser auf reale Fälle vorzubereiten. Außerdem würden die Teams lernen, wie man Applikationen konzipiert, und die Entwicklung und damit die Verantwortung für diese Systeme auf mehrere Teams verteilen.
Wir kündigten die beiden bevorstehenden Workshops regelmäßig während unserer wöchentlichen internen »Devtalks«-Session an. Die Teilnahme war freiwillig. Jeder Workshop begann mit einer kurzen Einführung in die Kata-Methode sowie einer Erläuterung des Anwendungsfalls und der Aufgaben. Anschließend erhielt jedes Team ein leeres Miro-Board, auf dem es arbeiten konnte, d. h. seine Architektur und Komponentenübersicht strukturieren konnte. Am Ende sammelten wir Feedback über die Methode und den Anwendungsfall.
Unser Anwendungsfall: »Fancy Food«
Um unseren Workshop-Teams etwas an die Hand zu geben, haben wir ihnen ein fiktives, aber sehr realistisches Szenario vorgestellt. Ein (fiktives) Start-up namens »Fancy Food« ist an Turbine Kreuzberg mit dem Vorschlag herangetreten, ein Minimum Viable Product (MVP) zu bauen, d.h. eine erste Version eines Produkts mit gerade genug Funktionalität, um von ersten Kund:innen genutzt werden zu können. Die Mission von Fancy Food ist es, mit leckeren Mahlzeiten die Ernährungsbedürfnisse seiner Kund:innen zu erfüllen und ihr allgemeines Wohlbefinden zu fördern. Wir haben uns von diesem Architektur-Kata-Szenario inspirieren lassen, auf das wir bei der Vorbereitung der Workshops gestoßen sind.
Um das Szenario abzurunden, haben wir eine Reihe von Voraussetzungen und Anforderungen formuliert:
- Fancy Food hat eine Küche, in der die Mahlzeiten zubereitet werden.
- Fancy Food verwendet intelligente Kühlschränke als Verkaufsstellen. Die Mahlzeiten werden von der Küche an diese Verkaufsstellen geliefert.
- Die Kund:innen prüfen die Verfügbarkeit der Mahlzeiten mit Hilfe der Mobile/Web App am nahegelegenen POS.
- Die Kund:innen gehen zum nächstgelegenen POS und kaufen oder holen die Mahlzeiten ab.
- Das System muss die Lagerbestände an den POS aufrechterhalten.
Unsere Workshop-Teams hatten folgenden Aufgaben: Benutzer/Kunden identifizieren, Anwendungsfälle identifizieren, Systemkomponenten ableiten, die High-Level-Architektur der Applikation zu entwerfen und die Architektur der Integration zu konzipieren. Als zusätzlichen Bonus gaben wir den Teilnehmern die Aufgabe, eine sinnvolle Teamstruktur für den Anwendungsfall und eine grobe Aufwandsschätzung für die Implementierung zu erarbeiten.
Die Ergebnisse
Im Allgemeinen war unser Architektur-Katas-Experiment ein großer Erfolg. Unsere Entwicklungsteams waren davon begeistert, die Möglichkeit zu bekommen, sich mit Architekturen zu beschäftigen – vor allem diejenigen, die zuvor wenig bis gar keine Erfahrung mit dem Entwurf von Architekturen hatten. Die meisten von ihnen schätzten es zudem, ein Softwareprojekt aus der »Consulting«-Perspektive zu betrachten, d. h. schon weit vor der eigentlichen Implementierungsphase in ein Projekt einzusteigen. Das zeigt, dass die meisten Entwickler:innen keine Eintagsfliegen sind: Sie wollen nicht nur eine Aufgabe nach der anderen lösen, sondern intellektuell gefordert werden, kreativ arbeiten und das, was sie später umsetzen werden, mitgestalten.
Beim Vergleich der beiden Workshop-Gruppen lassen sich Ähnlichkeiten in den vorgeschlagenen Lösungen feststellen. Die erste Gruppe ging mehr in die Tiefe, während die zweite Gruppe einen breiteren Ansatz wählte war und eher einen MVP-Ansatz verfolgte.
Die erste Gruppe identifizierte die entscheidenden Komponenten und ihre Beziehungen zu einander, indem sie den Informationsfluss konkreter Daten verfolgte. Dadurch wurde eine mögliche API-Spezifikation für die verschiedenen Integrationspunkte erstellt, aber es dauerte auch sehr lange, das gesamte System abzubilden.
Die zweite Gruppe begann auch mit der Erörterung spezifischer Technologien, die für die Umsetzung ihrer Lösung geeignet wären. Zudem ermittelten sie ihre jeweiligen Komplexitäts-Tradeoffs und die Auswirkungen auf das Budget angesichts des erwarteten anfänglichen Investitionsvolumens.
Die zweite Gruppe identifizierte zusätzlich Rollen und deren Handlungsspielraum innerhalb des Unternehmens. Daraus konnten sie die Komponenten ableiten, die »Experten-Tools« wären und für die außer der Kernfunktionalität nicht viel Aufmerksamkeit erforderlich sein würde.
Die Ergebnisse haben nur bestätigt, dass es notwendig ist, kontinuierlich Katas zu üben, ganz gleich ob nun architekturbezogen oder nicht. Wir haben gesehen, dass Übung wirklich den Meister machen kann – oder zumindest zu Verbesserungen führt. Das Training versetzt unsere teilnehmenden Entwickler:innen jetzt in die Lage, bessere Architekturentscheidungen zu treffen und fundiertere Schätzungen zu erstellen. Sie haben ein tieferes Verständnis für die Anwendung von Designprinzipien und -mustern sowie verbesserte Problemlösungsfähigkeiten. Innerhalb des vordefinierten Bereichs, den unsere Workshops abgedeckt haben, erlangten die Teilnehmer:innen zunehmende Kenntnisse und Vertrautheit mit den für die Architekturentwicklung relevanten Techniken.
Darüber hinaus kamen unsere Entwickler:innen einfach auf neue Ideen und Ansätze für die Softwarearchitektur, was sich auf ihre Fähigkeit auswirken sollte, diese in ihrer täglichen Arbeit anzuwenden. Und letztlich, wie so oft im Workshop-Setting, hat die gemeinsame Arbeit auch das Team-Gefühl gestärkt.
Moritz Deißner
Technical Director
Moritz.Deissner@turbinekreuzberg.com
Anusch Athari
Technical Director
Anusch.Athari@turbinekreuzberg.com