Das klassische Verständnis von IT-Architektur ist besonders in der agilen Welt häufig irreführend. Architektur sollte grösstenteils in den Teams gemacht werden; ein System Architect in SAFe ist primär ein Agilitätsförderer, eher als ein klassischer Architekt.
Architekten in der IT sind bekannt dafür, etwas Abstand zu Entwicklungsteams zu haben, und von oben herab Entscheidungen zu treffen. High-Level Zielbilder werden aufgestellt, die umgesetzt werden sollen. Entscheide zur System- und Applikationslandschaft werden gefällt – mit der ‘Aussensicht’, aber häufig ohne detaillierte Kenntnisse der entsprechenden Applikationen. Es werden Vorgaben und Richtlinien auferlegt, und durch ‘Quality Gates’ versucht zu kontrollieren. System- oder Solution-Architekten werden als Experten angesehen, die zu Beginn eine Architektur aufzeichnen, und dann an das Entwicklungsteam übergeben. Besonders in einer modernen, agilen Arbeitsweise ist es aber wichtig, sich von diesem Rollenbild zu lösen.
Was braucht es wirklich?
Die Prinzipien zum Agilen Manifest sagen, Anforderungsänderungen sollen selbst spät in der Entwicklung willkommen geheissen werden. Man versucht nicht mehr, die Zukunft vorherzusagen und in einem umfassenden Architekturbild festzuhalten, sondern schafft die Grundlagen, um Entscheide aufzuschieben und sich damit mehr Möglichkeiten freizuhalten. Arbeit ‘auf Vorrat’ soll möglichst zurückhaltend getan werden. Viel Aufwand und Vorarbeit die gegebenenfalls wieder verworfen werden muss soll vermieden werden.
Und wenn es trotzdem wertvoll wäre eine Systemübersicht zu haben, soll das selbstorganisierte agile Team das selbst entscheiden, und kann diese auch selbständig erstellen und unterhalten. Abmachungen dazu, wie gearbeitet wird oder welche Technologien, Tools, und Praktiken benutzt werden können im Entwicklungsteam aufgestellt und im Verlaufe der Zeit angepasst werden. Und wenn es übergreifende Richtlinien braucht, reicht es häufig, diese als Best Practices statt als Vorgaben festzuhalten.
Was macht dann der Architekt?
Trotzdem kennen Frameworks wie das Scaled Agile Framework (SAFe) die Rolle der System oder Solution Architects. Und genau weil diese so heissen, wird oft der Bezug zur klassischen IT-Architektur gemacht. So wie aber ein Release Train Engineer in SAFe nicht ein ‘Engineer’ ist (sondern eher eine Rolle mit methodischem Fokus, ein ‘Scrum Master’ für den Release Train), ist ein System Architect nicht unbedingt primär ein Architekt.
Stattdessen kann ein System Architect eher als ‘technisches Gewissen’ für den Release Train bezeichnet werden. Sie unterstützen die agilen Teams darin, die technischen Grundlagen zu schaffen um schnell Annahmen zu testen und Hypothesen zu validieren. Sie helfen abzuwägen, wo eine bewusst geplante Architektur wertvoll ist, und in welchen Fällen sich diese genau so gut über die Zeit entwickeln kann. Sie vertreten die Investitionen in technische Basisarbeit gegenüber anderen Prioritäten der Product Manager und Business Owner. Sie sind ‘Lean-Agile Leader’, welche die Agilität fördern, einfach mit einem stärkeren Fokus auf die technischen Aspekte.
Und ja, manchmal braucht es auch ein wenig klassische Architektur oder ein übergreifendes Zielbild. Und auch da kann ein System Architect unterstützen. Aber oft braucht es das viel weniger häufig als man initial annimmt.
Weiterführende Literatur / Links
Agile Architecture in SAFe (Englisch)
