Architekten müssen keinen Code schreiben!

Continuous Architecture  –  14 Kommentare

Viele glauben, dass wirklich gute Softwarearchitekten Code schreiben müssen. Warum eigentlich? Schließlich sind Architektur und Code zwei unterschiedliche Ebenen der Softwareentwicklung.

Früher war alles gut: Architekten entwarfen die Architektur, Entwickler programmierten nach dieser Vorgabe. Eine klare Aufgabenteilung – mit einem Problem: Die Architekten verloren den Kontakt zur Arbeit der Entwickler. Viele Architekten waren sogar Stolz darauf, schon lange das "dreckige" Programmiergeschäft hinter sich gelassen zu haben. Aber so trafen die Architekten Entscheidungen im Elfenbeinturm ohne Bezug zur Realität. Diese Entscheidungen betrafen Technologien oder den Einsatz von Frameworks – oft um den "Wildwuchs" im Projekt einzuschränken. Schließlich können nur die hochqualifizierten Architekten solche Entscheidungen wirklich fundiert treffen.

Das Ergebnis war dann eine massive Einschränkung der Handlungsfreiheit des Teams. Oft gab es in Projekten nur zwei Alternativen: Entweder die Entscheidungen des Architekten zu ignorieren – und das Projekt funktionierte trotz der Entscheidungen. Oder der Architekt drückte die Entscheidungen durch – oft mit schwerwiegenden Resultaten für das Projekt.

Schreibender und moderierender Architekt

Die Gegenbewegung ist der Code schreibende Architekt: Er arbeitet nicht nur an der Architektur, sondern auch am Code. So kann er den Kontakt zur Realität gar nicht verlieren. Aber auch dieses Vorgehen hat Nachteile: Ab einer bestimmten Größenordnung und Komplexität des Projekts ist Architektur ein Full-Time-Job. Dann gibt es nur zwei Möglichkeiten: Der Architekt verteilt die Architekturarbeit auf mehr Schultern, oder er lässt das Schreiben von Code – vielleicht höchstens noch ab und zu im Rahmen von Pair Programming. Gerade Pairing verbessert den Informationsfluss zum Architekten und erlaubt es ihm, sich jederzeit aus der Code-Ebene wieder zurückzuziehen, weil andere Aufgaben wichtiger sind.

Es gibt auch andere Möglichkeiten, als Architekt dem Elfenbeinturm zu entkommen. Der Architekt kann technische Entscheidungen moderieren und Feedback einholen – statt die Entscheidungen einfach so allein zu treffen. Das ist sowieso ein gute Idee, denn so kann sich das Projekt die technische Kompetenz aller Mitarbeiter bei Entscheidungen zunutze machen. Dahinter steckt ein anderes Verständnis der Rolle: Der Architekt ist nicht unbedingt der beste Techniker im Projekt. Er arbeitet an der Architektur und damit eben auf einer anderen Ebene als die Teams – aber in enger Abstimmung mit den Entwicklern. Nur durch die Challenges der Entwickler und der Stakeholder kann die Architektur weiterentwickelt werden.

Code zu schreiben, kann für einen Architekten aber auch eine Möglichkeit sein, die eigenen technischen Skills aktuell zu halten. Das muss dann aber nicht im Projekt sein, sondern kann auch in Hobby-Projekten erfolgen. So oder so sollten Architekten einen halbwegs aktuellen Wissensstand für wesentliche Technologien haben.

Der Microservices-Kontext

Bei Microservices ergibt sich sowieso eine andere Aufgabe für die Architekten: Sie definieren die Protokolle zwischen den Microservices oder die Verteilung von Funktionen auf Microservices. In den Microservices haben die Teams weitgehende Freiheit – oft bis hin zu den einzusetzenden Frameworks und Programmiersprachen. Schließlich werden die Microservices als einzelne Prozesse, virtuelle Maschinen oder Docker-Container betrieben. Dann ist es aber nicht mehr notwendig, viele Vorgaben für die Interna der Microservices zu machen.

Zu diesen Fragestellungen können die Architekten beraten und Feedback geben, aber die Teams können viel mehr Entscheidungen selbst treffen. So sollte der Architekt seine Rolle verstehen: Entscheidungen moderieren und anderen bei wichtigen Fragen helfen, aber nicht Entwicklern vorschreiben, was sie zu tun haben.

PS: Danke an die innoQ-Kollegen Carmen Burmeister, Falk Hoppe, Holger Kraus, Andreas Krüger, Jerry Preissler, Philipp Schirmacher, Silvia Schreier, Michael Vitz und Till Schulte-Coerne für die Diskussion über eine frühe Version des Blog-Post!