Kolumne: Architektur intensiv

„Coding Architects“ sind der Modetrend – und wer „nur“ Architekt:in ist, hat ein schlechtes Gewissen. Dabei gibt es gute Gründe, warum Architekt:innen nicht coden sollten.

„Coding Architects“ sind Menschen, die Architektur betreiben und außerdem selbst Code schreiben. Viele von ihnen nennen sich so voller Stolz. Wenn man aber unverstellt auf diese Rolle blickt, erschließt sich nicht sofort, was an dieser Rolle so gut sein soll. Es ist offensichtlich eine Doppelbelastung. Sowohl Softwareentwicklung als auch Softwarearchitektur sind echte Herausforderungen. Beiden Rollen gerecht zu werden, macht das Leben sicher nicht besonders einfach. Dabei geht es nicht nur um das Skillset.

Wenn nur eine Person die Rolle der Softwarearchitekt:in bekommen hat, wird sie sich um alle Architekturbelange kümmern müssen. Das bedeutet nicht zwingend, dass sie alle Entscheidungen selbst trifft. Aber sie muss den Überblick behalten und einzelne Entscheidungen moderieren oder delegieren. Diese Tätigkeiten können eine Person vollständig beschäftigen. Die Doppelbelastung kann leicht zu einer Überlastung führen oder sogar dazu, dass Architekturthemen vernachlässigt werden.

Und das Ergebnis der zwei Rollen ist noch ein anderes: Die Architekt:in ist im Zweifel eine unzuverlässige Entwickler:in, weil sie andere Prioritäten haben muss. Im Zweifel hat die Architektur bei Aufgaben Vorrang vor dem Code, da sich nur diese Person darum kümmern kann und Architektur häufig tatsächlich wichtiger ist als die konkrete Implementierung. Dann ist die Frage, wie wertvoll eine unzuverlässige und überlastete Entwickler:in für das Projekt ist.

Doppelbelastung – warum?

Wenn die Nachteile der Doppelbelastung so offensichtlich sind, stellt sich die Frage, warum so viele die Rolle „codende Architekt:in“ für erstrebenswert halten. Der wesentliche Grund: Der Code stellt die Realität im Projekt dar. Codende Architekt:innen haben eine bessere Verbindung zum Code und damit zur Realität als Architekt:innen, die nicht coden.

Im Prinzip ist das richtig, aber eine einzelne Entwickler:in kann nur einen kleinen Teil des Systems selbst sehen und ändern. Architekt:innen müssen aber auch und vor allem Entscheidungen treffen oder moderieren, die für das gesamte System relevant sind. Der Einblick aus der eigenen Arbeit mit dem Code kann dabei helfen – aber es ist nicht gesagt, dass die wesentlichen Herausforderungen dabei unmittelbar klar werden. Weil die codende Architekt:in wie erwähnt den Fokus nicht auf den Code legen kann, ist es unwahrscheinlich, dass die codende Architekt:in die kritischen Codeänderungen vornehmen wird. Die eigene Entwicklungsarbeit kann also kein Ersatz für eine Kommunikation mit dem Team und den Entwickler:innen sein, um einen breiteren Blick auf das System zu bekommen.



Vielleicht geht es aber um etwas anderes: Es kann sicher als Architekt:in nicht schaden, zumindest einen groben eigenen Blick auf das System zu bekommen, indem man darin codet. Das ist aber machbar, ohne dass man eine vollwertige Entwickler:in ist. Außerdem müssen Architekturkonzepte sich im Code niederschlagen. Das selbst auszuprobieren und zu erfahren, kann ebenso hilfreich sein. Schließlich kann es für die Glaubwürdigkeit gut sein, wenn man selbst auch Code schreiben kann und nicht nur in abstrakten Konzepten denkt.

Ebenso kann man die Rolle der Architekt:in mit Leben füllen, indem man mit anderen Personen gemeinsam am Code arbeitet. Beim Pairing kann die Architekt:in Konzepte vermitteln und gleichzeitig erkennen, welche Herausforderungen eine Lösung auf Architekturebene erfordern. Das ist zweifellos hilfreich, bedeutet aber nicht, dass die Entwickler:in selbst sehr viel Code schreibt. Verständnis von Code und den Herausforderungen auf dieser Ebene müssen Architekt:innen natürlich auf jeden Fall mitbringen.

Gefangen im Elfenbeinturm

Ein weiterer Grund, diese Doppelbelastung zu akzeptieren, ist die Flucht aus dem Elfenbeinturm. Architekt:innen müssen sicher auf einer abstrakteren Ebene als Code arbeiten. Aber wenn sie nicht aufpassen, sind sie von der Realität zu weit entfernt. Dann treffen sie Entscheidungen auf der Basis von Informationen, die nicht der Realität entsprechen. Die Entscheidungen lösen vermutlich die zentralen Probleme nicht und werden ignoriert. Die Architekturarbeit ist dann wertlos. Man ist im Elfenbeinturm ohne Kontakt zur Realität oder Einfluss auf die Realität gefangen. Codende Architekt:innen verstehen die konkreten Gegebenheiten eher und sind daher weniger anfällig für Realitätsferne.

Diese Argumentation ist sicher nachvollziehbar, aber am Ende müssen Architekt:innen doch vor allem mit anderen kommunizieren, um den Elfenbeinturm zu verhindern [1]. Das Coden hilft nur zum Teil. Und es hilft nicht dabei, die Perspektiven anderer Stakeholder kennenzulernen, die ebenfalls wichtig sein können.

Architektur ist kein Code

In jedem Projekt gibt es unterschiedliche Personen mit unterschiedlichem Einfluss auf den Code: Tester:innen sind für das Finden von fachlichen und anderen Fehlern zuständig. UX-Expert:innen können besonders gut nutzbare Oberflächen entwerfen. Diese Arbeit ist nur sinnvoll, wenn sie den Code beeinflusst. Aber UX und Tests sind andere Aufgabengebiete als Coding. Für diese Rollen ist die Erwartungshaltung wohl kaum, dass sie außerdem noch Code produzieren. Architektur hat ebenfalls einen Einfluss auf den Code. Vielleicht ist sie näher am Code als die anderen Aspekte, aber warum soll nur diese Rolle auch Code produzieren? Diese Ausnahmeposition der Architektur scheint nicht offensichtlich.

Das bedeutet am Ende auch, dass man Architektur als etwas eigenes, vom Code bis zu einem gewissen Maße getrenntes Thema verstehen muss. Und das ist ja auch tatsächlich so. Die Struktur des Systems und die Antwort auf die nichtfunktionalen Anforderungen bzw. Qualitäten sind eigene, komplexe Themen. Sie erfordern Stakeholdermanagement. Und sie erfordern manchmal Lösungen, die nicht einfach im Code zu finden sind. Die Antwort auf Qualitätsprobleme liegt nicht immer im Code. Ein System, das nicht benutzerfreundlich ist, wird kaum Benutzer:innen finden und am Markt nicht erfolgreich sein. Die entscheidenden Maßnahmen sind im Bereich UX und nicht so sehr im Code vorzunehmen.

Betrachten wir ein Problem, das anscheinend direkt mit Code zu tun hat: mangelnde Wartbarkeit. Das kann selbst bei perfektem Code passieren, wenn er nicht ordentlich übergeben wurde. Dann sind die Maßnahmen aber kein Coding und keine Verbesserung der Codequalität, sondern eine sinnvolle Übergabe oder gemeinsames Kennenlernen des Codes, wenn eine Übergabe nicht mehr möglich ist.

Qualität sicherzustellen, kann also sehr wichtig sein – lässt sich aber nicht durch die Wahl einer Technologie oder bessere Codestrukturen lösen. Architektur bedeutet, diese Themen zu identifizieren und zu lösen. Wissen über den Code hilft dabei, aber in erster Linie sollte man sich auf die Architektur fokussieren und alle diese Herausforderungen lösen.

Fazit

Codende Architekt:innen unterliegen der Doppelbelastung von Coding und Architekturarbeit. Im Konfliktfall gewinnt vermutlich die Architekturarbeit. Dann kann das Coding der Architekt:in kaum bei der Implementierung von Features helfen. Es fördert aber ein besseres Verständnis des Systems und gegebenenfalls eine bessere Zusammenarbeit mit Entwickler:innen. Insgesamt ist es aber möglich, die Architekturrolle auszufüllen, ohne zu coden und im Elfenbeinturm zu enden – dazu ist Kommunikation und eine gute Zusammenarbeit mit allen Stakeholdern zentral [1].