Die Arbeit von Softwarearchitekten ist so vielfältig, dass man sie selten in einer Person, „dem Architekten“, zusammenfassen kann.
Besser ist es, wenn Architektur von einem Team gemacht wird. Am besten von einem cross functional team, nämlich einem Team, in dem alle benötigten Funktionen (also Rollen und Skills) enthalten sind. Solch ein Team hat eine Stärke: Es kann selbstständig und schnell entscheiden, ohne erst viel Rückfragen an seine Umgebung stellen zu müssen. Welche Funktionen braucht man in einem Architekturteam?
Ein Architekturteam zusammensetzen
Da wären zunächst Benutzer und Kunden. Benutzer sind solche, die mit dem System später arbeiten sollen. Sie haben eine Vorstellung davon, mit welchen Begriffen (Konzepten) und Abläufen sie arbeiten wollen. Ein kognitives Modell, das man in der Architektur möglichst getreu abbilden sollte, damit sich die Software so verhält wie erwartet. Kunden sind solche, die ein Auge auf Termin und Kosten haben. Architekturentscheidungen, die ohne Berücksichtigung dieser zwei Faktoren fallen, stellen sich im Nachhinein oft als nicht praktikabel heraus, deshalb ist es gut, einen Vertreter des Kunden mit im Architekturteam zu haben. Kunden wissen auch, für welches Marktsegment sie welche Konfiguration des Systems brauchen – ebenfalls ein wichtiger Input für die Architektur.
Das Business vertritt die geschäftliche Seite, und zwar die der eigenen Organisation, eben derjenigen, die das neue System schafft. Schließlich soll mit dem neuen System auch Geld verdient werden, das die Mitarbeiter ernährt und die Firma wachsen lässt. Das Business kann zum Beispiel sehr gut beitragen, wenn es um die Frage geht, ob man einen Syytembestandteil besser einkauft oder selbst entwickelt.
Domänenexperten sind die Leute mit den grauen Haaren, die viel wissen. Es sollten Experten für die Fachdomäne(n) dabei sein, damit das neue System auch den richtigen fachlichen Regeln folgt. Es sollten Experten für die technische(n) Domäne(n) dabei sein, damit nicht etwas entworfen wird, das technisch sehr aufwändig werden wird. Usability-Experten sind auch wichtig, denn das neue System muss gut benutzbar sein.
Unter die Domänenexperten fallen zum Beispiel auch Leute, die schon jahrzehntelang ähnliche Systeme bei denselben Kunden betreut haben und die genau wissen, was die damaligen Stolpersteine und wichtigen Punkte waren. Auch die traditionell als „Architekten“ bezeichneten Leute rechne ich zu dieser Rolle.
Entwickler schließlich sind dafür verantwortlich, das System bis ins Detail weiterzuentwerfen, zu programmieren und zu testen. Sie müssen sofort beim Entwurf der Architektur mitsprechen, sonst entwirft man etwas, das nachher nur als Hindernis für die Prorgrammierung und den Test empfunden wird. Zu dieser Rolle habe ich auch Designer und Tester gezählt – sie sind für mich im weitesten Sinne auch Entwickler, weil sie für das Problem, das die Benutzer haben, eine Lösung finden und sicherstellen.
Gemeinsam entwerfen und entscheiden
Wenn alle sich treffen und zusammenwirken, kann man schnell entwerfen und Entscheidungen fällen. Entwurfsentscheidungen können aus allen Blickwinkeln gleichzeitig geprüft und bewertet werden. Das vermeidet Wartezeiten und die unseligen Zyklen von „Schreiben und Reviewen“, die monatelang dauern. In einem cross functional team erstellt man Architekturen, die als wirkliche Stütze für die Entwicklungsteams dienen, überflüssiges Detail vermeiden und es ermöglichen, dass die Entwickler schnell und leicht vorankommen.
Dazu demnächst mehr in einem weiteren Blog-Beitrag. Oder kommen Sie zur Jax on Tour, da gebe ich einen Vortrag dazu.
