Kolumne

Knigge für Softwarearchitekten: Die Agilitekten

Peter Hruschka, Gernot Starke

In den letzten Jahren tauchten zahlreiche Artikel und Blogbeiträge auf, die unserer Meinung nach eine gefährlich Botschaft verbreiten: Wir sind agil und brauchen daher keine Architekten! Wir wollen dagegenhalten: mit dem Agilitekten.

Ein gut geführtes Restaurant kann als Metapher für ein Softwareentwicklungsteam dienen. Dort sind die Zuständigkeiten für die Arbeit im Team klar verteilt. Der Saucier macht die Soßen, der Patissier ist für Feingebäck und Süßspeisen verantwortlich, die Oberkellnerin kümmert sich um die Begrüßung und die Vergabe der Sitzplätze, der Sommelier konzentriert sich auf den Wein, und der Küchenjunge spült das Geschirr. Wenn man die Arbeitsmuster eine Weile beobachtet, wird man feststellen, wie sich jede Person auf den Arbeitsbereich konzentriert, für den sie zuständig ist.

Die Kellnerin kommt mit einer Bestellung an, heftet sie an die Pinnwand und verschwindet wieder, um einen Korb mit Brot an den Tisch zu bringen. Der Annoncier liest die Bestellung durch und ruft den Spezialisten die Namen für jedes Gericht zu. Der Poissonier brät den Heilbutt an, der Saucier bereitet die Soße zu, der Legumier bereitet das Gemüse und die Garnierung mit Brunnenkresse vor und der für die Präsentation der Gerichte zuständige Koch richtet die Speise an. Sobald alles fertig ist, kontrolliert der Chefkoch das Ergebnis. Dann wird der Kellner herangerufen und serviert die Gerichte am Tisch. Jeder Einzelne weiß, was er zu tun hat, wann er es zu tun hat und – mindestens ebenso wichtig – was er von den Kollegen erwarten kann. Die Atmosphäre ist lebendig, geschäftig und entschlossen. Wenn Sie diesem Muster in einem Softwareprojekt begegnen, spüren Sie förmlich die Energie von konzentrierter Spannung und Leistungsbereitschaft in der Luft: den Flow.

Lesen Sie auch: Knigge für Softwarearchitekten: Wie Sie die Industrie-4.0-Zukunft mitgestalten

Was hier wirklich vor sich geht, ist Folgendes: Die Leute kommen mit ihrer Verantwortung und ihrem Wissen zur vollen Entfaltung. Die UI-Spezialisten wissen, was von ihnen erwartet wird. Die Tester wissen, wann eine Version wirklich auslieferungsfähig ist. Die Datenbankentwickler wissen, wo ihre Aufgaben beginnen und enden. Jeder Einzelne im Team ist zuversichtlich in Bezug auf das, was er zu tun hat, und darauf, dass er weiß, wann er seinen Beitrag geleistet hat. Und der Agilitekt weiß um seine Zuständigkeit für die Koordinierung von Aufgaben, die Kommunikation der Architektur an verschiedene Stakeholder, die Mitwirkung bei der Erarbeitung querschnittlicher Konzepte, die Moderation an Schnittstellen, das Herbeiführen von Entscheidungen sowie die Sicherstellung konzeptioneller Integrität.

Manche Projekte basieren darauf, dass alle für alles verantwortlich sind: „Wir sind ein Team. Wir ziehen alle an einem Strang. Wenn irgendetwas getan werden muss, steht es in der Verantwortung jedes Einzelnen, dafür zu sorgen, dass es getan wird.“ Kaum überraschend, dass das nur selten gut geht. Stellen Sie sich vor, das Team in einem Restaurant würde so arbeiten. Während der Koch die Soufflés backt, würde er sich um die Reservierungen Sorgen machen, der Kellner würde noch etwas Salz in die Suppe werfen, der Oberkellner würde das übrige Geschirr waschen, aus Sorge, es könnte nicht genügend für Tisch 22 vorhanden sein – jeder würde sich um alles kümmern – oder in alles einmischen – und nichts besonders gut machen.

Agilitekten tragen die Verantwortung für die Qualität der Lösung. Das bedeutet, dass sie mit Kollegen gemeinsam an Aufgaben arbeiten, bei Bedarf um Unterstützung bitten oder andere relevante Quellen als Hilfe heranziehen. Entscheidend ist, dass nur eine Person die Verantwortung für die Gesamtaufgabe tragen kann. Der Agilitekt hat durch seine Rolle eingewilligt, die Verantwortung für Funktionalität und Qualität der Lösung zu übernehmen. Als Agilitekt wissen Sie, dass Sie es sind, der für den Erfolg der Lösung den Kopf hinhalten muss.

Autorität sein und Autorität haben

Kompetenz zieht Ansehen nach sich [1]. Autorität und Ansehen haben einen natürlichen Drang zur Kompetenz hin und sammeln sich bei ihr. In einem multifunktionalen Team (gibt es überhaupt noch andere?) bringen die verschiedenen Teammitglieder unterschiedliche Kompetenzen auf unterschiedlichen Gebieten ein. Die Autorität, Entscheidungen treffen zu dürfen, sollte sich dieser Kompetenz anschließen.

Geistige Arbeit unterscheidet sich grundlegend von Produktionstätigkeiten. In der Produktion wird den Arbeitern ein gemeinsames und in der Regel einfaches Ziel vorgegeben: „Ausstoß der maximal möglichen Produktion von Reiswaffeln innerhalb der nächsten acht Stunden.“ Und sie verfügen über geeignete Fähigkeiten, um diese Arbeit zu erledigen. Der Produktionsleiter ist üblicherweise ein Meister auf diesem Gebiet und verfügt über profundes Wissen über die Fertigungsstraße und ihre Funktionsweise. Wenn Entscheidungen getroffen werden müssen, ist dies die Aufgabe des Produktionsleiters.

Im Gegensatz dazu sind bei einer geistigen Arbeit wie Architekturentwicklung die Fähigkeiten der Beteiligten vielfältig, ebenso wie Fachkenntnisse in den benötigten Disziplinen. Bestimmte Entscheidungen fallen in das natürliche Fachgebiet eines oder mehrerer Teammitglieder. Wenn eine Entscheidung vollständig innerhalb des Teams getroffen werden kann, sollte sie dort von den jeweiligen Spezialisten getroffen werden. Falls eine Entscheidung auch Personen außerhalb des Teams betrifft, müssen die Mitglieder des Teams, in deren natürliches Fachgebiet die betroffene Entscheidung fällt, auf jeden Fall an der endgültigen Entscheidungsfindung beteiligt werden.

Stefan Toth zeigt in [2] verschiedene Interpretationen der Architektenrolle (Abb. 1), die wir alle in der Praxis mehr oder weniger verbreitet wiederfinden.

Den klassischen Architekten mit Vorgaben von oben und ohne Beachtung von Feedback aus dem Team finden wir genauso gefährlich wie das Team ohne expliziten Verantwortlichen für die Architektur. Obwohl natürlich Ausnahmen die Regel bestätigen und auch diese Organisationsformen manchmal funktionieren können.

Wenn das Team eher jung und unerfahren ist, übernimmt der Agilitekt (oder Architektur-Owner) mehr Koodinierungs- und Entscheidungsverantwortung. Im Idealfall hat man als Agilitekt hoffentlich Architekturagenten, die in ihrem jeweiligen Aufgabenbereich eigenständig größere Teile entscheiden und verantworten können. Dann bleibt für den Agiliteken aber immer noch die Koordinierung und Moderation zwischen den Teammitgliedern, um insgesamt Konsistenz, Ausgewogenheit und Angemessenheit zu erreichen.

hruschka_starke_knigge_1

Abb. 1: Ein Architekt mit Vorgaben von oben und ohne Beachtung von Feedback kann genauso gefährlich sein, wie ein Team ohne Architekturverantwortlichen; am besten gibt es einen Agilitekten, idealerweise mit Architekturagenten

Im allgemeinen Sprachgebrauch hat das Wort Autorität unterschiedliche Bedeutungen. Zum einen kann eine Person aufgrund ihres außerordentlichen Fachwissens auf einem bestimmten Gebiet eine natürliche Autorität sein. Zum anderen kann eine Person aufgrund ihrer Position Autorität haben. Es ist durchaus möglich, eine natürliche Autorität zu sein, ohne Autorität zu haben. Ebenso ist es möglich, eine Autorität zu haben, ohne eine Autorität zu sein. Im Idealfall ist ein Agilitekt keine Autorität, sondern besitzt natürliche Autorität und wird deshalb von den Teammitgliedern respektiert.

Lesen sie auch: Knigge für Softwarearchitekten: Software is eating the World

Fazit

Im agilen Team zu arbeiten, macht Spaß. Die Fähigkeiten aller Teammitglieder zu nutzen, Aufgaben gemäß den Fähigkeiten zu übernehmen und für deren Erledigung auch die Verantwortung zu übernehmen, ist eine gute Idee. Lösungsvorschläge erarbeiten, sich gegenseitig Feedback zu geben und gemeinsam Entscheidungen treffen, ist gut. Aber einer muss die Gesamtverantwortung für die Lösung übernehmen: der Agilitekt. Und Gesamtverantwortung ist unteilbar.

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: