Schaut man sich das Scaled Agile Framework Big Picture an, so stechen neben den bekannten agilen Rollen, wie dem Scrum Master (sowie dem Release/Solution Train Engineers) und den Product Ownern (sowie Product/Solution Managern) die drei Architekten-Rollen (System-Architect, Solution-Architect und Enterprise Architect) ins Auge. Damit ist SAFe® auch das einzige agile Framework, welches explizit Architekten-Rollen als Verantwortlichkeiten benennt. Nahezu alle anderen agilen Frameworks verlagern Architektur-Aufgaben in die agilen Teams.
Bei größeren agilen Vorhaben und insbesondere im skalierten Umfeld (mit mehreren Hundert agilen Teammitgliedern, die alle an einem gemeinsame Produkt arbeiten) braucht es jedoch technisches Alignment, damit das entwickelte Produkt stabil und langfristig erfolgreich ist. Mit Alignment sind hier aber techn. Rahmenbedingungen und nicht Top-down-vordefinierte und verteilte Arbeit gemeint. Denn auch in SAFe® passiert die eigentliche Entwicklung von Produkten und damit verbundener konkreter Architektur bei technischen Produkten in den agilen Teams der Release Trains.
Um das "Mysterium" um die drei Architekten-Rollen in SAFe® etwas zu lüften, gibt es seit einigen Monaten ein neues SAFe® Advanced Training "SAFe® for architects", in dem über drei Tage die genauen Anforderungen und Aufgaben der verschiedenen Architekten-Rollen erklärt und auch spielerisch ausprobiert werden. "Die Teilnehmer sind immer erstaunt, wieviele weitere Aufgaben ein Architect in SAFe® neben den Rahmenbedingungen der technischen Architektur noch hat", beschreibt Manuel Marsch, der das Training bereits mehrfach als Inhouse-Training bei großen Kunden durchgeführt hat. Neben dem Diskutieren von Rahmenbedingungen mit den agilen Umsetzungsteams sowie dem Coachen technischer Praktiken, bildet ein Architekt auch ein gemeinsames Team mit Release Train Engineer und Product Management bzw. Solution Train Enigneer und Solution Management. Dieses entscheidet dann gemeinsam über die nächsten anstehenden technischen und fachlichen Aufgaben für die Release Trains. Und so wie die fachlichen Rollen (im Laufe einer SAFe® Transformation durch die ständig stattfindende Kommunikation) technische Grundlagen erlernen, werden SAFe® Architekten auch in Business Entscheidungen eingebunden und müssen ein wenig in die fremde BWL-Welt eintauchen. Denn die Priorisierung der neuen Aufgaben für die ARTs (Agile Realease Trains) werden in SAFe® vom Produkt/Solution Management und Architekten gemeinsam als Team getroffen, was einer der Erfolgsfaktoren des Frameworks ist. "Genau dies wird im Architekten Training in einer recht umfangreichen Simulation via Learning-by-Doing behandelt, so dass es als Advanced Training wirklich mit Beispielen arbeitet und nicht wie andere SAFe® Trainings nur Theorie vermittelt. Allerdings ist der vorherige Besuch einer weiteren SAFe® Schulung ( bspw. Leading SAFe®, SAFe® PO/PM oder SAFe® for teams) Voraussetzung für dieses Training", erklärt Manuel.
Auch werden im SAFe® for architects Training neue SAFe® Begrifflichkeiten, wie die Arbeit mit Solutions (für große Produktentwicklungen) und neue Zeremonien (Solution Demo, Architects Sync) eingeführt und das bisher stiefmütterlich behandelte Thema "Solution Intent" endlich ausführlicher detailliert. Somit ist das Architects-Training insbesondere für Mitarbeiter großer SAFe® Implementierungen mit mehreren ARTs und mehreren hundert Mitarbeitern geeignet. Aber auch Architekten kleinerer SAFe® Implementierung mit nur einem Release Train werden vom Erfahrungsaustausch mit anderen Architekten profitieren, was ein besonderer Vorteil unserer öffentlichen KEGON-Trainings ist, in welchen Teilnehmer aus ganz unterschiedlichen Umfeldern aufeinandertreffen und sich austauschen.
Zuletzt lässt sich sagen, dass es sicherlich ein gewisser Weg vom "IT-Architekten" zum guten SAFe® Architekten ist, aber dieses Training (nach einem SAFe® Grundlagen-Training ein nächster wichtiger Schritt Entwicklungsschritt ist, bei dem Spass und Erfahrungsaustausch nie zu kurz kommen.
