Sind Architekturteams in größeren Unternehmen überflüssig?

3 Kommentare

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.

Tobias Flohre

Tobias Flohre arbeitet als Senior-Softwareentwickler/Architekt bei der codecentric AG. Seine Schwerpunkte sind Java-Enterprise-Anwendungen und Architekturen mit JavaEE/Spring. Er ist Autor diverser Artikel und schreibt regelmäßig Blogbeiträge zu den Themen Architektur und Spring. Zurzeit beschäftigt er sich mit Integrations- und Batch-Themen im Großunternehmen sowie mit modernen Webarchitekturen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Eberhard Wolff

    Hallo,
    damit keine Missverständnisse aufkommen: wir sollten in dem Podcast auch diskutiert haben, dass Wiederverwendung technischer Artefakte sinnvoll sein kann – vor allem, wenn das wie hier beschrieben im Geiste von Open-Source-Projekte geschieht und wenn die Benutzung nicht erzwungen wird. Die Kritik richtete sich an den Ansatz, Frameworks als Mechanismus zum Erzwingen von Architektur zu nutzen – der hier ja auch kritisch gesehen wird. Und natürlich auch fachliche Frameworks – die eben praktisch nicht umgesetzt werden können und hier auch nicht betrachtet werden. Ich glaube daher, dass dieser Blog-Post und unser Podcast nicht im Widerspruch stehen sollten – ganz im Gegenteil.
    Eberhard

    • Tobias Flohre

      11. Juni 2014 von Tobias Flohre

      Ich sehe auch keinen Widerspruch. Framework-/ Architekturteams waren einfach kein Thema im Podcast, deswegen habe ich mir dazu Gedanken gemacht.
      Und bezüglich Deines Tweets, dass Framework-Team ungleich Architekturteam ist: das ist klar, es sind nur häufig dieselben Leute. Ich beziehe mich ja in diesem Post explizit auf die Framework-/Bibliothek-Tätigkeit in so einem Team.

  • Eberhard Wolff

    … und natürlich vielen Dank für die Erwähnung des Podcasts und den Link darauf 🙂

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.