Jeder kennt sie, manchmal heißen sie Architekturteam, manchmal Framework-Team, manchmal Methoden und Verfahren. Jede größere Firma mit eigener IT und Software-Entwicklung hat sie. Neben anderen Aufgaben sind diese Teams häufig dafür verantwortlich, Code zu schreiben, den andere Teams im Unternehmen nutzen. Mich interessiert in diesem Blogpost nur dieser Aspekt ihrer Arbeit. Eberhard Wolff sagt im neuesten, sehr empfehlenswerten heise-Architektur-Podcast , dass der Ansatz, ein Framework-Team aufzubauen, das die technologische Infrastruktur baut, die dann alle zu benutzen haben, gescheitert ist, und im Bereich von fachlichen Frameworks sogar spektakulär gescheitert ist. Dieser Punkt brachte mich zum Nachdenken. Ist das wirklich so? Sind dann Architekturteams (ich verwende im Folgenden diesen Begriff als Synonym für alle oben genannten) im Bezug auf diese Aufgabe überflüssig?
Ich habe in meinem beruflichen Leben schon viele Firmen-Frameworks und Bibliotheken gesehen, und darunter war vieles, was ich niemals so gemacht hätte.
Zehnstufige Vererbungshierarchien, bei denen man sich nur an bestimmten Stellen mit seinem Code einklinken kann, strenge Korsetts, die dem Entwickler die Luft zum Atmen und jegliche Motivation nehmen, und dennoch an vielen Stellen trickreich umgangen werden.
Komplexität durch generische Alleskönner-Komponenten, die keiner mehr richtig versteht.
Und dennoch halte ich Firmen-interne Frameworks und Bibliotheken für wichtig. Ich habe zufälligerweise in den letzten Jahren relativ viel im Batch-Bereich gemacht, und dort gibt es immer eine firmen-spezifische Scheduler-Anbindung, Return-Codes, ein unterschiedlicher Umgang mit Protokollen und weitere gemeinsame Funktionalität. Wenn jetzt jeder, der einen neuen Batch-Job schreiben will, das alles selbst machen muss, ist das einfach ungeheuer ineffizient. Und in anderen Bereichen sieht das nicht anders aus, da gibt es vielleicht spezielle Monitoring-Servlets für alle REST-Anwendungen, einen bevorzugten Web-Anwendungsstack mit firmen-eigener Security und so weiter.
Also, was nun?
Ich denke nicht, dass ein Architekturteam überflüssig ist, aber ich denke, dass sich Fokus und Selbstverständnis des Teams ändern müssen. Ein Architekturteam hat eine Aufgabe: den anderen Teams dabei zu helfen, produktiv zu sein.
Nicht mehr und nicht weniger.
Damit wird das Architekturteam zum Dienstleister. Es gibt nicht vor, wie die Dinge zu laufen haben, sondern es macht Angebote – die auch abgelehnt werden können.
Wir haben in den letzten 15 Jahren gelernt, dass Monolithen problematisch sind, und der Microservices-Hype ist das überspitzte Resultat aus diesen Schmerzen. Nach einer Phase der Konsolidierung wird klar werden, dass nicht alles so micro werden muss, wie jetzt manchmal dargestellt, dass es aber trotzdem sinnvoll ist, kleinere Anwendungen zu haben. Und man wird unterschiedliche Typen von Anwendungen haben, Web in verschiedenen Formen, Batch, Einzelsatzverarbeitung, Reactive und so weiter.
Die Aufgabe des Architekturteams ist es, die Entwicklerteams in allen diesen Typen von Anwendungen produktiv zu halten, und dazu gehören ein oder mehrere bevorzugte Technologiestacks inklusive Querschnittslogik (Spring Boot Starter sind eine gute Möglichkeit, um Stack und Logik zusammenzubringen). Entwicklerteams können diese verwenden, müssen es aber nicht. Hier kann man vom Open Source – Modell und Github lernen: es gibt einen Lead-Developer für jeden Stack / jede Bibliothek, der diese weiterentwickelt, Pull-Requests bewertet und für seinen Code wirbt – in Workshops, Präsentationen und Co. Dieser Lead-Developer sollte die Hälfte seiner Arbeitszeit in Projekten verbringen, die seinen Code verwenden.
Es ist kein Problem, wenn es mehrere Stacks / Bibliotheken gibt, die dasselbe Problem lösen. So mag es vielleicht für Web-Anwendungen einen Stack mit dem Play-Framework und einen mit Spring Boot / Spring MVC und Thymeleaf geben. In regelmäßigen Abständen wird geprüft, ob der Stack / die Bibliothek genutzt wird, und so kann die Architekturteam-Unterstützung für einen Stack eingestellt werden, wenn es schon lange keinen neuen Projekte mehr damit gab.
Lead-Developer für Framework/Blibliothek/Stack müssen nicht unbedingt aus einem dedizierten Architekturteam kommen, vorstellbar ist auch, dass ein Mitglied eines Teams, das einen neuen Stack im Projekt verwendet, Lead-Developer für diesen Stack wird. Dann muss es im Unternehmen aber auch Prozesse dafür geben, dass diese Person entsprechend Zeit für die Weiterentwicklung bekommt.
Fazit
Firmen-Frameworks / -Bibliotheken und -Technologiestacks bleiben wichtig, da sie die Entwicklerteams produktiver machen. Und genau darauf muss der Fokus liegen. Sehen die Entwicklerteams keinen Produktivitätsvorteil, müssen sie die oben genannten Artefakte nicht verwenden. Ein Artefakt, das niemand mehr als Produktivitätsvorteil sieht, kann abgewickelt werden.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Flohre
16.2.2022 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Flohre
Senior Software Developer
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.