Sein oder nicht sein?

Die Rolle des Architekten im 21. Jahrhundert

Uwe Friedrichsen

© shutterstock.com/Gajus

Für die einen ist er das Ziel aller IT-Träume, für die anderen ein Relikt aus vergangenen Zeiten. Die Rede ist – mal wieder – vom Architekten. Nachdem die Rolle viele Jahre so unumstritten war, dass sie sogar einen festen Platz in vielen IT-Aufbauorganisationen hatte, ist sie in den letzten Jahren immer häufiger in Frage gestellt worden. Das geht so weit, dass Architekten in der modernen Softwareentwicklung als hinderlich betrachtet werden und daher die Abschaffung der Rolle gefordert wird. Wer hat nun recht? Oder liegt die Wahrheit wie so oft in der Mitte? Zeit für eine Bestandsaufnahme und eine Neuausrichtung.

Zum Einstieg eine Abgrenzung: Wir reden hier über die Rolle des Architekten, nicht über Architektur. Häufig werden diese beiden Themen in einen Topf geworfen, was dann zu beliebigen, nutzlosen Diskussionen führt. Architektur steht hier nicht zur Debatte. Die Frage, ob man Architektur braucht, ist sinnlos, da Architektur immer da ist, egal ob man sie explizit entwirft oder sie während der Implementierung entsteht.

Und wir reden auch nicht über Architekturarbeit, d. h. dem Arbeiten an einer Architektur. Auch diese wird benötigt. Wer glaubt, dass ein reales Projekt jenseits der Sandkastengröße komplett ohne explizite Architekturarbeit auskommt, ist ein genauso naiver Träumer wie die Leute, die heute noch glauben, dass man Architekturen abschließend vor Beginn der Implementierung definieren kann.

Wir hinterfragen hier ausschließlich die Notwendigkeit der Rolle des Architekten. Brauchen wir in der Softwareentwicklung die Rolle eines Architekten oder kann die notwendige Architekturarbeit auch ohne einen Architekten gemacht werden? Wie eingangs erwähnt, gibt es zu dieser Fragestellung jede Menge Meinungen, die von „Wird unbedingt benötigt“ bis zu „Auf gar keinen Fall“ reichen. Anstatt den verschiedenen Meinungen nachzuspüren, versuche ich, mich dem Thema von zwei anderen Seiten zu nähern: Auf der einen Seite betrachte ich das Anforderungsprofil, das mit einem Architekten verbunden ist, und die einzelnen Teilaufgaben der Architekturarbeit. Davon ausgehend untersuche ich, welche der Aufgaben das beschriebene Anforderungsprofil benötigen und welche der Aufgaben auch mit einem anderen Anforderungsprofil bewältigt werden können.

Auf der anderen Seite betrachte ich die typischen Probleme der klassischen Architektenrolle in der Praxis und stelle das gegen häufige Defizite in der Ausgestaltung anderer Projektrollen. Davon ausgehend entwerfe ich eine Vision für eine bessere Verteilung der Architekturarbeit auf die vorhandenen Projektrollen und eine dazu passende Architektenrolle. In Summe wird es nicht die neue Rollenbeschreibung für einen Architekten geben, aber eine Reihe von Ideen, in welche Richtung wir die Rolle des Architekten im 21. Jahrhundert weiterentwickeln können.

W-JAX 2018 Java-Dossier für Software-Architekten

Kostenlos: 40+ Seiten Java-Wissen von Experten

Sie finden Artikel zu Enterprise Java, Software-Architektur, Agilität, Java 11, Deep Learning und Docker von Experten wie Kai Tödter (Siemens), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

Anforderungen an einen Architekten

Beginnen wir mit dem Anforderungsprofil an einen Architekten. Was macht einen Architekten aus? Welches Profil erfüllt er? Wie üblich beginnen wir unsere Materialsammlung bei Wikipedia (wo sonst?) unter dem Schlagwort „Architekt“ [1]: „Der Architekt […] befasst sich mit der technischen, wirtschaftlichen, funktionalen und gestalterischen Planung und Errichtung von Gebäuden und Bauwerken […]. Seine Kernkompetenz ist das über das Bauen hinausgehende Schaffen von Architektur. […] Das Berufsbild des Architekten ist nicht eindeutig definier- und abgrenzbar, länderweise verschieden und ständig in Bewegung. […] Der Beruf des Architekten ist traditionell generalistisch angelegt: die Baumeister vergangener Zeiten erstellten in Personalunion den Entwurf und die Statik und beaufsichtigen den Bauablauf.“

Natürlich wissen wir seit Langem, dass sich die Baumetapher nur sehr eingeschränkt auf die Softwareentwicklung übertragen lässt und sich damit auch das Bild des Bauarchitekten nur eingeschränkt auf den Softwarearchitekten übertragen lässt. Da der Architektenbegriff aber ursprünglich dem Bauwesen entlehnt worden ist, macht es dennoch Sinn, die Sammlung da zu beginnen.

Da finden wir schon einiges, das uns aus dem Bereich der Softwarearchitekten bekannt vorkommt: Breites Wissen, übergreifende Verantwortung, nicht nur Umsetzer, sondern auch Planer, aber auch unscharfe Definition, Überschneidung mit anderen Rollen und steter Wandel. Schauen wir bei Wikipedia weiter nach „Softwarearchitekt“ [2], dann finden wir dort vergleichbare Aussagen: „Softwarearchitekt ist ein Begriff zur Stellenbeschreibung für Menschen, die […] im Bereich der Softwaretechnik an der Softwarearchitektur und deren Implementierung arbeiten. […] Trotz Fehlens einer gemeinhin akzeptierten Definition der Rolle eines Softwarearchitekten […]“

Nun soll man sich ja nie alleine auf Wikipedia verlassen. Schauen wir also einmal beim iSAQB vorbei, das sich die Aus- und Weiterbildung von Softwarearchitekten auf die Fahnen geschrieben hat. Dort findet man im Lehrplan für den CSPA-F [3] die folgende Passage: „Software-Architekten tragen die Verantwortung für die Erreichung der geforderten oder notwendigen Qualität der Lösung. Sie müssen diese Verantwortung mit der Gesamtverantwortung der Projektleitung koordinieren.“

Das deckt sich in etwa mit den vorherigen Anforderungen. Die Verantwortung wird etwas stärker betont und die (häufig schwierige) Beziehung zu der Projektleitung angesprochen. Außerdem wird die Verantwortung für die Architektur im Allgemeinen auf das Erfüllen der Qualitätsattribute hin konkretisiert – eine Definition, die weithin akzeptiert ist.

Eine weitere beliebte Quelle ist das Software Engineering Institute der Carnegie Mellon University. Es hat viele Definitionen zu Softwarearchitektur auf seinen Seiten gesammelt, bietet überraschenderweise aber keine Definition eines Softwarearchitekten [4] – also Fehlanzeige.

Dagegen haben Dana Bredemeyer und Ruth Malan auf ihrer Website eine Menge interessanter Definitionen zur Rolle des Softwarearchitekten zusammengetragen [5]. Ohne diese hier im Detail wiederholen zu wollen, drehen sich die meisten dieser Definitionen um Menge der Erfahrung, Soft Skills und Wissensbreite als primäre Differenzierungsfaktoren von Softwarearchitekten gegenüber anderen Rollen in der Softwareentwicklung.

Dieses Bild findet sich auch in dem Kompetenzframework für Architekten von Bredemeyer wieder [6], das in dem zugehörigen Artikel „The Role of the Architect“ [7] detailliert erläutert wird. In Kurzform fordert das Framework einen breiten Erfahrungshintergrund und ausgeprägte Soft Skills. Außerdem wird die Generalistenanforderung noch etwas ausgeweitet. Es geht nicht nur um einen IT-Generalisten, sondern ein Architekt muss sich auch mit diversen nicht technischen Themen auskennen, um die von ihm geforderten Aufgaben im Rahmen seiner Verantwortung umsetzen zu können. Wenn wir die Anforderungen aus den verschiedenen Quellen zusammenfassen, so soll ein Architekt das folgende Anforderungsprofil erfüllen:

•    Breiter Erfahrungshintergrund (auch außerhalb der reinen Softwareentwicklung) und ausgeprägte Soft Skills
•    Architekturarbeit machen – sowohl Entwurf als auch Umsetzung
•    Übernahme gesamtheitlicher Verantwortung für das Projekt bzw. System

Die gesamtheitliche Verantwortungsübernahme sollte in Zeiten selbstorganisierter, „empowered“ Teams eigentlich für alle Beteiligten selbstverständlich sein, weshalb wir diese Anforderung nicht weiter betrachten werden.

Nehmen wir die beiden verbliebenen Punkte, dann ergibt sich damit ein Bild wie in Abbildung 1 dargestellt: Um Architekturarbeit machen zu können, muss man über einen breiten, über die Grenzen der IT hinausgehenden Erfahrungshintergrund und ausgeprägte Soft Skills haben.

Abb. 1: Anforderungsprofil an einen Architekten (traditionelle Definition)

 

Bestandteile von Architekturarbeit

Das wirkt jetzt ein wenig elitär, da nach diesem Anforderungsprofil nur sehr wenige Leute überhaupt Architekturarbeit machen können. Es drängt sich die Frage auf, ob dieses Profil für Architekturarbeit wirklich unabdingbar ist. Zur Beantwortung dieser Frage müssen wir uns Architekturarbeit etwas genauer ansehen. Eine gute Beschreibung hierfür liefert arc42 mit seiner Differenzierung von Architekturarbeit in die folgenden sechs Kernaufgaben [9]:

1. Anforderungen, Randbedingungen und geforderte Qualitätsmerkmale klären und hinterfragen, bei Bedarf verfeinern
2. Strukturentscheidungen hinsichtlich Systemzerlegung und Bausteinstruktur treffen
3. Übergreifende technische Konzepte entscheiden und bei Bedarf umsetzen
4. Softwarearchitektur kommunizieren und dokumentieren
5. Konsistenz von Quellcode und Softwarearchitektur prüfen und sicherstellen
6. Softwarearchitektur bewerten, insbesondere hinsichtlich Risiken bezüglich der geforderten Qualitätsmerkmale

Anders betrachtet lassen sich diese Aufgaben zusammenfassen zu den folgenden Aufgabenblöcken (Abb. 2):

• Sicherstellen, dass das Richtige gemacht wird (Punkte 1 und 6)
• Versuchen, das Geforderte richtig zu machen (Punkte 2 und 3)
• Querschnittliche Aufgaben (Punkte 4 und 5)

Abb. 2: Aufgaben der Architekturarbeit nach arc42, zusammengefasst in Gruppen

Es gibt auch noch eine Reihe weiterer Beschreibungen von Architekturarbeit, aber letztlich laufen sie alle auf die gleichen, zuvor beschriebenen Aufgabenblöcke hinaus. Deshalb ist die Differenzierung gemäß arc42 für unsere Zwecke hinreichend.

Anforderungen an Architekturarbeit

Kommen wir jetzt zurück auf die Frage, ob das beschriebene Architektenprofil unabdingbar für Architekturarbeit ist, indem wir uns die verschiedenen Aufgabenblöcke der Reihe nach anschauen.

Anforderungen zu klären, hinterfragen und verfeinern bedeutet, dass man unklare oder fehlende Anforderungen klären muss, dass man widersprüchliche Anforderungen konsolidieren muss, dass man für unrealistische Anforderungen Alternativen vorschlagen und Kompromisse herbeiführen muss – mit dem Ziel, sicherzustellen, dass man „das Richtige macht“.

Das bedeutet viel Kommunikation mit sehr unterschiedlichen Stakeholdern mit vielfach sehr unterschiedlichen Erwartungen an die Lösung. Man benötigt zunächst einen großen Erfahrungshintergrund auch außerhalb der reinen Softwareentwicklung, um die Bedürfnisse der Stakeholder überhaupt richtig verstehen zu können und darüber hinaus meist ausgeprägte Soft Skills, um die notwendigen Konsolidierungen und Kompromisse herbeizuführen. Für diese Aufgabe benötigt man definitiv das beschriebene Architekten-Skillset.

Das Bewerten einer bestehenden Softwarearchitektur ist dem Klären von Anforderungen sehr ähnlich, nur mit einer anderen Zielsetzung. Anstatt sicherzustellen, dass die Anforderungen hinreichend für einen Entwurf sind, hat man bereits einen fertigen Entwurf und prüft (vereinfacht dargestellt), ob dieser hinreichend für einen Satz von (neuen) Anforderungen ist. Dies umfasst ähnliche Tätigkeiten wie die Anforderungsklärung. Insbesondere muss man auch hier mit vielen Stakeholdern kommunizieren und die Implikationen von Anforderungen bewerten können. Deshalb benötigt man auch für diese Aufgabe das beschriebene Architekten-Skillset. Für den Lösungsentwurf und die Umsetzung („die Dinge richtig machen“) muss man zunächst die Frage beantworten, was das Ziel einer Architektur ist. Wie bereits in der Beschreibung der Aufgaben zu erkennen, ist das Ziel einer Softwarearchitektur die Erfüllung der geforderten Qualitätsmerkmale – nicht mehr, aber auch nicht weniger.

Eine gute Beschreibung für Softwarequalitätsmerkmale liefert der Standard ISO/IEC9126, kompakt nachlesbar in [10] (mittlerweile offiziell von ISO/IEC25000ff. abgelöst, aufgrund der besseren Zugänglichkeit und Verständlichkeit verwenden wir hier trotzdem den alten Standard).
In Kurzform definiert der Standard Qualitätsmerkmale für die Teilbereiche Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit. Diese kann man in zwei Kategorien zusammenfassen:

• Merkmale, die Laufzeitaspekte der Software (inkl. Inbetriebnahme) beschreiben – alle Merkmalsbereiche außer Änderbarkeit
• Merkmale, die die Quellcodequalität beschreiben – der Merkmalsbereich Änderbarkeit

Die Kategorie bezogen auf die Laufzeitaspekte erfordert Experten in der jeweils betroffenen Domäne. Es ist z. B. schwer, ein tragfähiges Sicherheitskonzept zu entwerfen und umzusetzen, wenn man keine Ahnung von Security hat. Diese Tätigkeiten erfordern also primär einen Domänenexperten.
Betrachten wir den Merkmalsbereich Änderbarkeit. Die dafür benötigte Codequalität lässt sich in zwei Aspekte aufteilen:

• Der Code muss verständlich sein. Je schlechter Code verständlich ist, desto aufwändiger und fehlerträchtiger sind Änderungen. Verständlichkeit ist also die Voraussetzung für Änderbarkeit.
• Der Code muss in Hinblick auf zukünftige Anforderungen änderbar sein. Wichtig ist dabei, dass Änderbarkeit eine Qualität ist, deren Erfüllungsgrad man erst in der Zukunft bewerten kann.

Die Verständlichkeit des Codes zu gewährleisten und zu erhalten, ist die Verantwortung eines jeden, der Code für das System schreibt. Ein einsamer Architekt kann das erfahrungsgemäß weder à priori noch à posteriori sicherstellen. Hier geht es um gemeinsam gewählte Konventionen, Clean Code, Refactorings, usw. – hierzu gibt es genug Literatur und Empfehlungen, sodass ich das Thema hier kurz halten kann.

Die Änderbarkeit von Code ist eines der am meisten missverstandenen Themen in der IT, mit dem man problemlos einen ganzen Artikel füllen könnte. Ich möchte mich hier auf ein paar wenige Aussagen beschränken:

Es ist nicht möglich, Code für alle möglichen Änderungen offenzuhalten. Jede Designentscheidung, die man trifft, entfernt Freiheitsgrade aus dem Lösungsraum. Wollte man eine Software aber offen für alle möglichen Änderungen halten, benötigt man alle Freiheitsgrade des Lösungsraums. Das würde bedeuten, dass man keine Designentscheidungen treffen kann, also keine Software entwickeln kann.

Die häufig propagierte Lösung, eine möglichst generische oder konfigurierbare Lösung zu entwerfen, ist auch eine Sackgasse. Jeder zusätzliche Flexibilitätspunkt in einer Lösung erhöht die Komplexität der Lösung. Erhöhte Komplexität bedeutet reduzierte Verständlichkeit. Verständlichkeit ist aber die Voraussetzung für Änderbarkeit. Man muss diese Größen also ausbalancieren und kann nicht beliebig flexible Lösungen entwerfen.

Faktisch muss man sich darauf beschränken, den Code offen für die zukünftigen Änderungsanforderungen zu halten, die diesen Code betreffen, was die Schwierigkeit aufwirft, dass man diese Anforderungen (noch) nicht kennt.

Die insbesondere in agilen Umfeldern propagierte Lösung, sich bzgl. Änderbarkeit rein auf die Verständlichkeit der Lösung zu beschränken, greift unter wirtschaftlichen Gesichtspunkten zu kurz, da man hierbei vorhandenes Wissen ignoriert.

Man kann nämlich durchaus einen zeitlich beschränkten Blick in die Zukunft werfen, indem man Bedürfnisse und Treiber von Stakeholdern analysiert sowie Unternehmensstrategien, Markttrends und Ähnliches zu Rate zieht. Daraus kann man dann die wahrscheinlichsten kommenden Anforderungen extrahieren und sicherstellen, dass heutige Designentwürfe diesen Anforderungen nicht zuwiderlaufen. Dafür ist das Aufwand-Nutzen-Verhältnis in der Regel sehr gut.
Inhaltlich kommt diese Tätigkeit einer regelmäßigen Architekturbewertung sehr nahe. Für den Rahmen dieses Artikels ist es daher hinreichend, die Tätigkeit der Architekturbewertung zuzuordnen und aus dem Bereich des Entwurfs herauszunehmen.

Die Querschnittsaufgaben Kommunikation, Dokumentation und Qualitätssicherung fallen unabhängig vom konkreten Aufgabengebiet immer an. Das sind keine architekturspezifischen Aufgabenstellungen. Sie sollten von jeder Person wahrgenommen werden, die Architekturentscheidungen trifft. Natürlich benötigt man für die Aufgaben gewisse Fähigkeiten, z. B. zielgruppengerecht kommunizieren und dokumentieren zu können, aber in Zeiten von eigenverantwortlichen, „empowered“ Teams sollte auch das selbstverständlich sein.

Abbildung 3 fasst die erforderlichen Skillsets für die verschiedenen Teilaufgaben der Architekturarbeit noch einmal zusammen: Architekturarbeit beinhaltet durchaus Aufgaben, die ein Architektenprofil wie zuvor beschrieben erfordern. Es gibt aber auch Teilaufgaben, die mit einem anderen, reduzierteren Skillset erfüllbar sind.

Man benötigt das umfassende Architektenanforderungsprofil also offenbar nur dann, wenn man als Architekt alle Aufgaben der Architekturarbeit auf einmal wahrnehmen will.

Abb. 3: Erforderliche Skillsets für die verschiedenen Aufgaben der Architekturarbeit

Der Architekt in der Praxis

Aber wie sieht das eigentlich in der Praxis aus? Nehmen wir einmal an, wir hätten einen heldenhaften Architekten mit dem geforderten Skillset und dieser schickt sich an, die Architekturarbeit in einem Projekt zu übernehmen. Üblicherweise kristallisiert sich einer der folgenden drei (überspitzten) Prototypen heraus:

• Der unerbittliche Diktator: Er beharrt darauf, dass die notwenigen Architekturarbeiten von ihm gemacht werden, bevor mit der Umsetzung begonnen wird. Ob er nun auf einem BDUF (Big Design UpFront) beharrt oder evolutionäre Ansätze zulässt, er wird zum Flaschenhals und bremst das ganze Team aus. Alle sind genervt und der Architekt im Dauerstress.

• Der Klärer: Er sammelt fehlende Anforderungen, stellt sicher, dass nicht nur die fachlichen, sondern auch die nicht fachlichen Anforderungen erfasst sind, konsolidiert, klärt Widersprüche, findet Kompromisse bei unrealistischen Anforderungen und macht Lösungsentwürfe – kurzum: Er stellt sicher, dass die Entwickler sinnvolle Anforderungen haben und möglichst effizient Software entwickeln können. Im Gegenzug wird er von den Entwicklern belächelt und mit dem „Architects don’t code“ Anti-Pattern abgestraft, weil er mangels Zeit kaum kodiert. Insbesondere in den frühen Entwicklungsphasen, in denen sein Entwicklungsinput für die Grundstrukturen des Systems sehr wertvoll sein kann, ist der Klärungsaufwand am höchsten und er findet praktisch keine Zeit zum Entwickeln.

• Der Frameworkhacker: Er programmiert. Punkt. Er ist die coolste Sau im Projekt und programmiert am liebsten Frameworks und andere hochkomplizierte Sachen, die die anderen nicht drauf haben. Auch kennt er alle neuen und hippen Technologien und bringt mindestens fünf davon in jedem Projekt unter. Meetings meidet er. Anforderungen zu klären ist nicht seine Aufgabe. Und sollte das Ergebnis nicht den Erwartungen entsprechen, dann waren die Stakeholder mal wieder unfähig, sich vernünftig auszudrücken. Die Bewunderung der anderen Entwickler ist ihm sicher. Bei den restlichen Stakeholdern genießt er aber eher einen zweifelhaften Ruf und ob das Ergebnis den Erwartungen entspricht, hat mit seinen Tätigkeiten wenig zu tun.

Diese Prototypen sind natürlich etwas überspitzt und in der Praxis finden sich auch noch jede Menge andere Varianten, aber eines wird klar: Es ist praktisch unmöglich, als Einzelperson (oder als kleines Architektenteam für große Projekte) alle Aufgaben vollständig zu erfüllen. Entweder man wird zum Flaschenhals oder aber wichtige Aufgaben bleiben liegen. Es sind schlicht zu viele Aufgaben auf der Architektenrolle vereinigt. Aber was kann man tun? Es sind doch alle Aufgaben für den Projekterfolg wichtig.

Defizite im Umfeld

Um die Fragestellung zu beantworten, macht es Sinn, einmal ein paar Schritte zurückzutreten und sich zu überlegen, warum die Rolle des Architekten so überfrachtet ist. Könnte es sein, dass die Rolle des Architekten über die Zeit hinweg nur deshalb so überfrachtet worden ist, weil andere Personen es sich regelmäßig bequem gemacht und ihre jeweilige Rolle nicht ordentlich ausgefüllt haben?

Nehmen wir die Projektmanager: Sie managen und managen. Sie fühlen sich dabei wahnsinnig wichtig. Was sie managen, interessiert sie nicht. Sie können alles managen. Hier einen Report, dort ein Statusmeeting, hier ein paar KPIs und wenn es dann einmal knallt, eine Moderation oder Eskalation initiieren, immer schön auf Metaebene und ohne Bezug zum konkreten Inhalt. Warum soll ein Projektmanager nicht für die Inhalte verantwortlich sein? Wenn er schon das Budget verwaltet, dann soll er selbst auch sicherstellen, dass das Richtige gemacht wird und Konflikte und Widersprüche selbst auflösen, anstatt sich bequem auf die Metaebene zurückzuziehen, ohne seinen Machtanspruch abzugeben.

Nehmen wir die Requirements Engineers (RE): Sie stecken all ihre Energie in die Erfassung möglichst eindeutiger Anforderungen. Ob die Anforderungen, die sie so toll erfasst haben, aber in Summe Sinn machen oder ob sie widersprüchlich sind, interessiert sie nicht. Das ist für sie ein Problem anderer Leute. Warum eigentlich? Eine Antwort wie „Das kann ein RE nicht leisten“ (habe ich nicht nur einmal gehört) lasse ich nicht gelten, denn „es“ muss schließlich geleistet werden, damit das System erstellt werden kann. Und im Sinne gemeinschaftlicher Verantwortung sollte ein RE sicherstellen, dass das Ergebnis seiner Arbeit mehr ist als eine akkurat formulierte Aufnahme eines Meinungswirrwarrs.

Nehmen wir die Product Owner (PO): Sie reduzieren den ach so wichtigen „Business Value“ auf reine Fachthemen und ignorieren deshalb nicht fachliche Anforderungen einfach. Nun, wenn Themen wie Sicherheit, Verfügbarkeit, Antwortzeitverhalten, Stabilität usw. keinen Business Value haben, warum lassen wir sie dann nicht einfach weg? Lasst uns ein System bauen, das keinerlei Sicherheit bietet, dauernd abstürzt und grottenlahm ist, wenn es denn einmal verfügbar ist. Dann wird man solchen Schwachsinn wie „Nicht fachliche Anforderungen haben keinen Business Value“ ganz schnell nicht mehr zu hören bekommen. Wenn der PO nun aber für den Business Value zuständig ist, dann soll er sich gefälligst auch um die nicht fachlichen Anforderungen kümmern.

Nehmen wir die Entwickler: Sie fühlen sich am wohlsten, wenn sie einfach vor sich hin entwickeln dürfen und sich um nichts anderes kümmern müssen. Und da alles andere weniger Spaß macht, wird es einfach aktiv ignoriert. Klären von Anforderungen? Spontaner Sprachverlust! Auflösen von Widersprüchen? Ach, nee! Dokumentation von Entscheidungen? Spontane Gicht in den Fingern! Im Gegenzug wird jeder für ahnungslos erklärt, der nicht den ganzen Tag vor der IDE verbringt und dem Entwicklerautismus frönt. Warum sollen Entwickler denn stur vor ihrer IDE bleiben dürfen, nur weil sie sich maximal unwillig anstellen, wenn sie mal etwas anderes tun sollen? Gerade in Zeiten von „Eigenverantwortung“ und „Empowered Teams“ müssen Entwickler lernen, dass die neuen Rechte auch mehr Verantwortung und damit zusätzliche Pflichten bedeuten und dass isoliertes Kreisen nur um Schreiben von Code nicht mehr ausreichend ist.

Und so weiter. Natürlich gibt es eine Menge Personen, die ihre Rolle besser ausfüllen als hier beschrieben (auch ich kenne solche Personen), aber es gibt leider noch mehr Personen, die in der Ausübung ihrer Rolle den oben beschriebenen Stereotypen erschreckend nahe kommen.
So lässt sich festhalten, dass ein guter Teil der Überfrachtung der Architektenrolle wohl daher rührt, dass er sich über die Zeit zur „Müllabladestelle“ für im Projektkontext häufig vernachlässigte Aufgaben entwickelt hat. Ohne diese regelmäßige Vernachlässigung von Aufgaben hätte sich die Architektenrolle wahrscheinlich gar nicht erst zu so einer eierlegenden Wollmilchsau entwickelt, wie sie es heute ist.

Eine alternative Wirklichkeit

Kehren wir mit dieser Erkenntnis zu der Frage zurück, wie man die Architektenrolle so entschlacken könnte, dass sie nicht mehr überfrachtet ist und trotzdem alle Aufgaben erledigt werden. Dafür nehmen wir einmal an, dass alle Beteiligten – wie immer wieder von agilen Heilsbringern mit missionarischem Eifer verkündet – willens sind, gesamtheitliche Verantwortung für den Projekterfolg zu übernehmen und sich nicht bequem in ihre Komfortzonen zurückziehen. Wie könnte Architekturarbeit dann heute aussehen? Ich nehme hier einmal ein agiles Umfeld an, aber es ließe sich genauso auf ein traditionelles Umfeld übertragen (Abb. 4):

• Der Product Owner stellt sicher, dass alle Anforderungen mit Business Value erfasst sind, egal ob fachlicher oder nicht fachlicher Natur. Außerdem stellt er sicher, dass widersprüchliche Anforderungen verschiedener Stakeholder zu einem Kompromiss geführt werden, bevor sie in die Umsetzung gehen und erarbeitet zusammen mit dem Team Alternativvorschläge für unrealistische Anforderungen. Kurzum: Er stellt ganzheitlich sicher, dass das Richtige getan wird.
• Die Entwickler kümmern sich ganzheitlich um die bestmögliche Umsetzung der Anforderungen. Sie verfeinern die Anforderungen in Zusammenarbeit mit dem PO oder den betroffenen Stakeholdern, bis sie sauber umsetzbar sind. Werden auf dem Weg Designentscheidungen getroffen, stellen sie selbst sicher, dass diese im Rahmen der Erfordernisse kommuniziert und dokumentiert sind. Außerdem stellen sie sicher, dass sie getroffene Entscheidungen bei ihrer Arbeit berücksichtigen und achten darauf, die Entropie im Code immer möglichst niedrig zu halten, um die Verständlichkeit zu optimieren.

Abb. 4: Vision einer neuen Architektenrolle (in einem idealen Umfeld)

Was bliebe dann für einen Architekten an Aufgaben übrig? Eigentlich nur zwei:

• Treiben einer ganzheitlichen Systemvision sowie Herbeiführen und Umsetzen (sprich: Kodieren) von Architekturentscheidungen – üblicherweise in Zusammenarbeit mit weiteren Teammitgliedern. Zur Pflege der Vision gehören auch regelmäßige Bewertungen der bestehenden Architektur und ein Blick auf wahrscheinliche, zukünftige Änderungsanforderungen – üblicherweise in Zusammenarbeit mit dem PO.
• Coachen und Unterstützen weniger erfahrener Teammitglieder, um sie in die Lage zu versetzen, selbst Architekturarbeit machen zu können.

Damit hätte man die Architektenrolle deutlich entschlackt und der Architekt könnte sich an den Stellen einbringen, an denen er den größten Mehrwert liefern kann und die nicht von anderen Rollen abgedeckt werden können.

Solange aber die gesamtheitliche Verantwortungsübernahme durch alle Projektbeteiligten nur ein von den agilen Heilsbringern beschworenes Idealbild ist, das man in der Wirklichkeit so gut wie nicht antrifft, werden wir wohl beim Architekten bleiben müssen, wie wir ihn kennen und lieben – oder hassen.

Geschrieben von
Uwe Friedrichsen
Uwe Friedrichsen
  Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als CTO der codecentric AG darf er seine Neugierde auf neue Ansätze und Konzepte sowie seine Lust am Andersdenken ausleben. Seine aktuellen Schwerpunktthemen sind agile Architektur und verteilte, hochskalierbare Systeme. Er ist außerdem Autor diverser Artikel und diskutiert seine Ideen regelmäßig auf Konferenzen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: