Die Bedeutung von Software­architektur, der Einfluss agiler Methoden und die Rolle des iSAQB in diesem Kontext

Tom Asel ist iSAQB-Mitglied und der Gründer von tangible concepts. Er arbeitet seit über 15 Jahren als Entwickler, Architekt und Trainer in der Software­ent­wicklung. Dabei bildet die agile Archi­tek­tur­arbeit einen Schwer­punkt seiner Tätigkeit. Er begleitet Teams und Organi­sa­tionen dabei, Entwick­lungs­pro­zesse, Fähig­keiten, Techno­logien und Archi­tek­turen aufein­ander abzustimmen.

Wir haben mit ihm über die Bedeutung von Software­architektur heute und den Einfluss agiler Methoden gesprochen.

Tom, was sind aus deiner Sicht die aktuellen Heraus­for­de­rungen in der Softwarearchitektur?

Konkur­renz­fähige IT-Prozesse sind, je nach Sicht­weise, entweder ein Wettbe­werbs­vorteil oder eine Überle­bens­not­wen­digkeit geworden. Das gilt heute mehr denn je. Subop­timale IT-Prozesse wirken sich praktisch in jedem Unter­nehmen direkt und messbar auf das Geschäft aus.

Dazu hat sich unsere Erwar­tungs­haltung an Systeme verändert. Wir alle erwarten in der täglichen Arbeit vorzu­finden, was wir an anderer Stelle gewohnt sind: Hochver­füg­barkeit, gute Benutz­barkeit, Inter­ope­ra­bi­lität zwischen Diensten unter­schied­licher Art. Den Nutzer:innen ist dabei meist nicht klar, welch enormer Aufwand z. B. von Cloud-Anbietern betrieben werden muss, um diese Eigen­schaften für Systeme, die aus unserem Alltag nicht mehr wegzu­denken sind, zu garan­tieren. Die persön­liche Erfahrung mit Apps, Amazon und Netflix definiert die Messlatte für alle täglich genutzten Systeme.

Für Unter­nehmen folgt daraus der konstante Bedarf, die eigene System­land­schaft anzupassen und zu erweitern. Dieser Anspruch wird zum Treiber für agile Praktiken, Conti­nuous Delivery und DevOps.

All das ist nicht neu, hat aber enorm an Bedeutung gewonnen. Archi­tek­tur­schaf­fende müssen dies in ihrer täglichen Arbeit berück­sich­tigen und tragen Verant­wortung weit über einzelne Systeme hinaus. Sie müssen technisch und metho­disch Expert:innen sein.

Euer Thema ist die agile Archi­tek­tur­arbeit – Worin liegt der Unter­schied zur klassi­schen Architekturarbeit?

Im Mittel­punkt steht, archi­tek­tur­fähige Teams zu schaffen: Teams also, die weitgehend selbständig handlungs­fähig sind und Archi­tek­tur­auf­gaben wahrnehmen können, ohne, dass eine Konzen­tration auf die Archi­tek­tur­schaf­fenden als Einzel­per­sonen im Vorder­grund steht.

Je nach vorherr­schender Organi­sa­ti­ons­kultur ist der Schritt hin zu teamge­trie­bener Archi­tek­tur­arbeit einfacher oder schwie­riger. Das gilt insbe­sondere dort, wo zentra­lis­tische Ansätze, einzelne Entscheider:innen und Wissensträger:innen bislang das vorherr­schende Muster darstellten. Oftmals ist bei der Transition Unter­stützung notwendig, und wir helfen dabei, passende Maßnahmen zu identi­fi­zieren, die erfor­der­lichen Skills aufzu­bauen und Rahmen­be­din­gungen zu schaffen, in denen agile Archi­tek­tur­arbeit erfolg­reich sein kann.

Braucht es denn heute noch dedizierte Architekten:innen oder sprechen wir nicht eher von Skills, die alle Entwickler:innen früher oder später erwerben müssen?

Es ist wichtig, Archi­tektur als Disziplin zu begreifen und nicht auf eine bloße Rolle, die an Einzel­per­sonen geknüpft ist, zu reduzieren. Archi­tek­tur­arbeit leisten zu können, sollte eine Fähigkeit des Teams sein und nicht vollständig an einzelne Akteur:innen gebunden sein. Der Schlüssel liegt darin, die Verant­wortung für die zuver­lässige Erledigung von Archi­tek­tur­auf­gaben klar zu regeln, die Umsetzung aber weitgehend dem Team zu überlassen.

Also ja, alle Entwickler:innen (und im Idealfall sogar alle unmit­telbar Betei­ligten) sollten über ein grund­le­gendes Archi­tek­tur­ver­ständnis verfügen.

Welche Rolle spielt das iSAQB dabei?

Das iSAQB leistet einen wichtigen Beitrag dazu, die wesent­lichen Archi­tek­tur­fä­hig­keiten zu vermitteln und Awareness für Archi­tek­tur­themen nicht nur bei Spezialist:innen zu schaffen.

Archi­tek­tur­fähige Teams profi­tieren davon, wenn alle Mitglieder ein Grund­ver­ständnis der zu leistenden Archi­tek­tur­arbeit und damit verbun­dener Aufgaben haben. Für spezi­fische Aufga­ben­stel­lungen kann es dann einzelne Expert:innen geben, die spezi­fi­sches Wissen in der Tiefe besitzen, sei es metho­disch oder technisch.

Die iSAQB-Module geben einen Rahmen für einzelne Themen­ge­biete: Von den Grund­lagen, die das Foundation Level vermittelt und die alle an der Software­ent­wicklung aktiv Betei­ligten beherr­schen oder zumindest einordnen können sollten, bis hin zu den spezi­fi­schen Themen­ge­bieten mit indivi­du­ellen Schwer­punkten wie DDD, Web Security oder eben Agiler Architekturarbeit.

Wie kann man deiner Meinung nach mit dem hohen iSAQB-Standard nachhaltig praxis­re­le­vantes Wissen aufbauen?

Das iSAQB stellt durch ein anspruchs­volles Akkre­di­tie­rungs­ver­fahren sicher, dass Seminare nur von exzel­lenten Trainer:innen gehalten werden. Aber es benötigt noch mehr, um wirklich nachhaltig wertvolle Skills aufbauen zu können: Bei tangible concepts achten wir in jedem Training auf ein ausge­wo­genes Maß an inter­ak­tiven Elementen, denn Frontal­un­ter­richt und Folien­schlachten sind schon lange nicht mehr zeitgemäß. Unsere Trainings sind so konzi­piert, dass sie trotz eines standar­di­sierten und anspruchs­vollen Lehrplans genug Raum für indivi­duelle Frage­stel­lungen und gegen­sei­tigen Austausch lassen.

Wir glauben, dass jedes Training sich ein Stück weit an die Teilneh­menden anpassen, ihnen entge­gen­kommen und sie im richtigen Maß fordern muss, um einen echten Mehrwert zu bieten. Darum bieten wir Seminare zum Beispiel auch im Halbtags-Modus an, um sie besser in den Alltag der Teilneh­menden zu integrieren.