Interview mit Stefan Toth
Wie funktioniert das Konzept der agilen Softwarearchitektur? Wie funktionieren agile Entscheidungsprozesse und welche Herausforderungen gibt es dabei? Das SQ Magazin hat diese Fragen Stefan Toth, Gründer der IT-Beratungsfirma embarc gestellt.
SQ Magazin: Was versteht man eigentlich unter agiler Softwarearchitektur?
Stefan Toth: Darunter kann man tatsächlich unterschiedliche Dinge verstehen. Softwarearchitektur verstehe ich als die Summe der wichtigen – also signifikanten und weittragenden – Entscheidungen. Was dabei auffällt, ist, dass diese Entscheidungen häufig
als Prozess getroffen werden. Es gibt also nicht nur einen Zeitpunkt, an dem etwas entschieden wird, sondern schwierige Entscheidungen werden über einen langen Zeitraum hinweg
bearbeitet. Diesen Entscheidungsprozess agil zu gestalten, ist die Aufgabe agiler Softwarearchitektur.
SQ Magazin: Welche Fragen sollte man sich im agilen Entscheidungsprozess stellen?
Stefan Toth: Das sind Fragen wie: Wie kann ich mehr Personen am Entscheidungsprozess beteiligen? Wie kann ich empirisch vorgehen? Wie kann ich die architektonische Planung nicht nur als Festlegungs- sondern auch als Priorisierungsinstrument nutzen? Diese Tätigkeiten zu sortieren und im Sinne von agilen Prinzipien umzusetzen, das ist der Kerngedanke der agilen Softwarearchitektur.
SQ Magazin: Gibt es bestimmte Voraussetzungen und Skills für Erfolge in der agilen Softwarearchitektur?
Stefan Toth: In puncto Soft Skills sind eine hohe Kommunikationsfähigkeit und vor allem Offenheit wichtig. Auch wenn man selbst viel Erfahrung hat, ist es wichtig, auf Einwände zu hören
und andere Meinungen zuzulassen. Man sollte die eigene Rolle im Sinne des „Servant Leaderships“ verstehen, also nicht aufgrund einer Machtposition bestimmte Entscheidungen treffen,
sondern eher den Blick hin zur Frage wenden: Welchen Mehrwert kann ich leisten? Dann kann ich mich viel besser auf das konzentrieren, was ich wirklich gut kann und nicht nur darauf,
was ich aufgrund meiner Rolle definitionsgemäß tun sollte.
SQ Magazin: Was sind die methodischen Voraussetzungen, die man mitbringen sollte?
Stefan Toth: Fachlich finde ich es gerade im agilen Kontext wichtig, dass man Ziele herunterbrechen und konkrete Zielsetzungen formulieren kann, die man als Team auch gut bearbeiten kann. Wichtig finde ich es auch, Architekturideen in eine konsistente Vision zu verdichten und mit diesen Visionen Leute zu begeistern und mitzureißen.
Letztendlich wollen wir im Agilen eine Klammer haben, zwischen einer Zielsetzung und dem zugehörigen Feedback. Und da würde ich auch die Kernaufgabe agiler Softwarearchitektur sehen: Ziele zu definieren und das Feedback klarer zu machen.
SQ Magazin: Welche Rollen gibt es im agilen Kontext und wie unterscheiden sie sich zum klassischen Kontext?
Stefan Toth: Im agilen Kontext gibt es Menschen, die an einer Softwarelösung
arbeiten sowie einen Product Owner, der das Team anleitet und die fachlichen Zielsetzungen im Blick behält – mehr Rollen braucht es eigentlich nicht. Man geht dabei von einer cross-funktionalen Rollenbesetzung aus – Architektur wäre dann ein Teil davon. Das bedeutet: Wer auch immer Architekturwissen im Team mitbringt, kann sich einbringen. Wenn man von Softwarearchitektur als Rolle redet, kann diese Rolle auch auf verschiedene Teammitglieder aufgeteilt werden. Manche Leute sind eben kommunikativ stärker, manche technisch stärker
und gemeinsam können sie das tun, was man unter Architekturarbeit versteht. Wenn man aber an größere Kontexte denkt, in denen mehrere Teams arbeiten, dann ist es notwendig, dass man übergreifende Rollen für die technische Kommunikations-, Abstimmungs- und Visionsarbeit hat.
Dafür gibt es unterschiedliche Namen: Manche sagen „Architecture Owner“, manche nennen es „unterstützender Architekt“, andere sprechen von „Marshalls“, die auf bestimmte Qualitätsaspekte
achten. Wichtig ist nur, dass man diesen Rollen nicht zu viel Macht zuspricht, damit anderen Beteiligten die Verantwortung nicht entzogen wird.
SQ Magazin: Warum ist es problematisch, wenn eine Rolle “zu viel” Macht hat?
Stefan Toth: Wichtig ist, dass das gesamte Entwicklungsteam die Verantwortung für das Produkt übernimmt und sich verantwortlich für seine Qualität fühlt. Alle im Team sollten mit
dem Ziel agieren, das bestmögliche Produkt zu bauen und reagieren, wenn sie Fehler bemerken oder etwas nicht wie gewünscht funktioniert. Dieses Verantwortungsbewusstsein muss im
Gesamtteam verankert sein. Eine zu prominente Architekturrolle könnte das Verantwortungsbewusstsein des Teams schädigen. Wenn bspw. von der Organisationsseite aus, bei Problemen, zum Architekten gegangen wird und nicht zum Team, fühlt sich das
Team irgendwann nicht mehr verantwortlich.
SQ Magazin: Welche Erfahrungen haben Sie damit in der Praxis gemacht? Was funktioniert bei der agilen Softwarearchitektur und was nicht?
Stefan Toth: Grundsätzlich ist es kein Problem ist, wenn eine Person im Team mehr Verantwortung übernimmt, sofern dieser Prozess organisch aus der Gruppe heraus entsteht. Problematisch wird es nur, wenn einer Person diese Rolle zugeschrieben wird, die sich so nicht herausbilden würde. Dieser “Mismatch” ist es, der in der Praxis häufig zu Problemen führt, weil diese Person dann etwas tun muss, was nicht in ihr Kompetenzspektrum fällt. Ein anderes Thema sind Gruppenentscheidungen: Häufig werden Mehrheitsentscheidungen getroffen. Diese können dazu führen, dass teilweise starke Widerstände übergangen werden.
Infolge solcher Entscheidungsprozesse kann es passieren, dass sich am Ende niemand mehr mit
dem Produkt identifiziert. Dann ist es besser in Richtung des Konsensverfahrens zu gehen und zu schauen: Wo existieren Widerstände und warum? Außerdem nutzen wir in der Praxis verschiedene Kommunikationsinstrumente, die uns bei der agilen Arbeit helfen: Wir versuchen unsere Architekturpläne und -visionen sichtbar zu machen und groß auf Wände zu tapezieren oder auf Whiteboards zu schreiben. Gemeinsam machen wir Post-It Sessions und fragen: Woran arbeiten wir gerade? Was muss verändert werden? So machen wir diese Architekturveränderung wirklich plastisch und fordern die Beteiligung von allen Teammitgliedern ein.
SQ Magazin: Die oben genannten Herausforderungen haben dazu geführt, dass bereits 2014 das CPSA – AGILA Modul vom ISAQB entwickelt wurde. Wem empfehlen Sie diese Schulung?
Stefan Toth: Das CPSA Advanced Level Modul AGILA vom iSAQB beschäftigt sich damit, wie Softwarearchitektur agil gelebt und gestaltet werden kann. Es werden Fragen behandelt wie:Wie entsteht eine agile Architekturvision als Gegenentwurf zu einem Big-Upfront-Design im klassischen Umfeld? Wie wird der Backlog beeinflusst? Wir beschäftigen uns damit, wie Architekturprinzipien statt starrer Vorgaben angewendet werden können und wie man mit technischen Schulden auf Architekturebene umgeht. Das CPSA Advanced Level Modul AGILA hilft allen, die in agilen Teams arbeiten. Aber auch Personen in klassischen Kontexten lernen, wie man dynamischer und teamgetriebener arbeiten kann.
SQ Magazin: Vielen Dank für das Gespräch!
