Welche Aufgaben eines Softwarearchitekten lassen sich nun in einer Kata trainieren? Die wichtigsten Aufgaben haben Gernot Starke und Peter Hruschka treffend beschrieben [4] – sie sind in Abb. 1 dargestellt.

Dieses vielfältige Aufgabengebiet möchte ich im Folgenden etwas genauer betrachten:

• Anforderungen und Randbedingungen klären:
  Als Architekt muss man ein Verständnis für die zu entwickelnde Anwendung haben und die fachlichen Anforderungen verstehen, um darauf aufbauend die passende Architektur zu entwickeln. Dies gelingt am besten durch direkte Kommunikation mit den Kunden, Anwendern und weiteren Stakeholdern. In agilen Projekten hat sich dazu die Phase-0 etabliert, in der die wichtigsten Anforderungen abgesteckt werden und eine erste Architekturvision [5] entsteht.
• Strukturen entwerfen:
  Sobald ein Bild des zu erstellenden Systems vorhanden ist, kann dieses in passende Strukturen gegossen werden. Ausgehend vom Systemkontext werden wichtige Subsysteme und ihre Beziehungen dargestellt. Dieses grobe Bild wird im agilen Umfeld entwicklungsbegleitend an den erforderlichen Stellen weiter verfeinert. Die Architektur entsteht nach und nach mit der Umsetzung der Anforderungen.
• Technische Konzepte entwerfen:
  Einige Design-Entscheidungen haben Auswirkungen auf das gesamte System (z. B. Umsetzung von Logging, Exception Handling, Persistenzanbindung, Resilienz, asynchrone Kommunikation) und sollten im gesamten System einheitlich gelöst werden. Diese weitläufigen und somit architekturrelevanten Entscheidungen müssen erkannt werden, um sie anschließend zu verallgemeinern, zu dokumentieren und allen betroffenen Entwicklern zugänglich zu machen. Netflix zum Beispiel gibt den Teams größtmögliche Freiheiten bei der Umsetzung der Microservices für die sie komplett verantwortlich sind. Wichtige technische Konzepte werden jedoch identifiziert und den Teams in Form von gut dokumentierten Open-Source-Bibliotheken zugänglich gemacht [6].
• Architektur kommunizieren:
  Architektur muss in verschiedenste Richtungen kommuniziert werden. Die Stakeholder interessiert es, ob ihre Anforderungen entsprechend umgesetzt werden. Die Entwickler müssen die Architekturkonzepte verstehen, damit diese auch passend umgesetzt werden. Hierbei hilft die gemeinsame Arbeit im Team. Die Dokumentation deckt ebenfalls einen Teil der Kommunikation ab. Hierzu hat sich der Einsatz von Templates [7] und Wikis bewährt.
• Umsetzung betreuen:
  Die Ideen der Softwarearchitektur müssen in die Entwicklungsteams getragen werden. Dies erfolgt durch Kommunikation, aber noch besser durch aktive Zusammenarbeit während des gesamten Projekts. Dabei übernimmt das Team die Architekturarbeit. In der Praxis sieht dies oft so aus, dass sich einige erfahrene Entwickler dieser Aufgabe annehmen und darauf achten, dass auch die anderen Teammitglieder in Entscheidungen einbezogen werden.
• Architektur bewerten:
  Bei der Architekturbewertung geht es darum, mittels definierter Szenarien die Erreichung der Qualitätsziele durch die Architektur zu überprüfen. Dazu gibt es verschiedene etablierte Verfahren [8]. Das Themengebiet ist so umfangreich, dass es an dieser Stelle nicht weiter vertieft werden kann.

In einer Architektur-Kata werden fast alle dieser Aufgaben trainiert. Die Schwerpunkte der Gruppenarbeit liegen auf „Anforderungen und Randbedingungen abklären“ und „Strukturen entwerfen“. In der anschließenden Präsentation muss die Architektur kommuniziert werden, die zuvor meist in Diagrammform dokumentiert wurde. Die anderen Teilnehmer bewerten die Architektur und geben Feedback.

Den erfolgreichen Einsatz der Architektur-Kata zu Ausbildungszwecken konnte ich zusammen mit 14 weiteren Kollegen der Sybit GmbH vor einiger Zeit erfahren. Wir haben uns über den Zeitraum eines halben Jahres mit dem Thema Softwarearchitektur auseinandergesetzt und mit dem Zertifikat der iSAQB (foundation level) [9] abgeschlossen. Dabei wurden die Themengebiete von den Teilnehmern selbstständig erarbeitet und gegenseitig geschult. Jeweils eine Architektur-Kata vor und nach der Schulung zeigten den Teilnehmern deutlich die erzielten Lernerfolge auf. Das Format kam so gut an, dass wir es dieses Jahr weiteren Mitarbeitern anbieten werden.

Für die Feedbackrunden gehen jeweils zwei Gruppen zusammen und stellen sich gegenseitig ihre Ergebnisse vor (Abb. 2). Bei einer ungeraden Gruppenanzahl übernimmt am besten der Moderator die Aufgabe des Feedbacks für eine Gruppe. Ansonsten nimmt der Moderator als Beobachter an der Präsentation teil und unterstützt gegebenenfalls die Teams durch gezieltes Nachfragen. Dabei können folgende Fragen hilfreich sein:

• Was ist das umzusetzende System und was gehört zum Kontext?
• Welches sind die wichtigsten Systemteile und in welcher Beziehung stehen sie zueinander?
• An welchen Stellen habt ihr Flexibilität eingebaut?
• Wie seid ihr vorgegangen?
• Welche Notation habt ihr benutzt?
• Wie viele Diagramme habt ihr erstellt?
• Welche Detailtiefe habt ihr erreicht?