Lesezeit: 2 Minuten
Teil 6 - Die Architektenrolle in DevOps-Teams/Organisationen
Beim Blick zurück auf die vorausgegangenen Blogartikel der Serie fällt vermutlich die große Anzahl an Qualitätsattributen, Architekturpatterns, Technologien und Konzepten auf. Ja, die Welt der Cloud-nativen Architekturen ist in jeglicher Hinsicht vielfältig und komplex.
Seit 2014 verbreitet sich eine Philosophie in IT-Bereichen, die Antworten auf die Herausforderungen bzgl. hoher Komplexität liefern soll. Wir hatten bereits erwähnt, dass Cloud-native Technologien (z.B. aus dem CNCF) für DevOps-Teams konzipiert wurden. Man muss aber auch feststellen, dass ohne cross-funktionales Arbeiten und „Ingenieursdenken“ die Komplexität dieser Architekturen und Technologien schwer beherrschbar sind. Die beiden gehören zusammen wie Popcorn und Kino.
Übergabe von Verantwortung
Ein nicht zu unterschätzendes Erfolgskriterium für DevOps-Organisationen ist die Übergabe von Verantwortung in die Engineering-Teams. Diese Dezentralisierung ist notwendig, um Silos und Flaschenhälse sukzessive abbauen zu können.
Der Software- bzw. Systemarchitekt ist in vielen Organisationen eine Rolle, die häufig zentral bzw. querschnittlich im Organigramm positioniert ist. Wie passt das nun in diese Welt? Gibt es immer noch Bedarf für zentrale Architekten oder sollen cross-funktionale DevOps-Teams diese Rolle nun vollständig selbst übernehmen?
In unserer Praxis haben wir erlebt, dass es weiterhin die Notwendigkeit gibt, bestimmte Architekturaufgaben zentral zu bewältigen. Allerdings sollte dieses zentrale Architekturteam seinen Einfluss nicht vordringlich aus der Hierarchie herleiten, sondern aus dem breit angelegten Respekt gegenüber dem Wissen, dem permanenten Lernen und der sehr guten Kommunikation dieses Teams. Der Fokus sollte hierbei auf folgenden Themen liegen:
- Die Erstellung von Technologieleitfäden (bzw. Leitlinien),
- Die Diskussion und Definition von Blueprints
- Eine zentrale Technologieauswahl, aber stets offen für Verbesserungsvorschläge
- Standardisierung von diversen Security und Delivery-Abläufen
- Aufbau von allgemeinen Dingen wie Service-Meshes, einer Event-Infrastruktur u.v.m.
Zielsetzung: Den "Mainstream" finden
Diese Aspekte zentral zu harmonisieren ist enorm wichtig, um in der aktuell immer vielfältigeren IT-Welt die Balance zwischen Verkrustung und Wildwuchs zu finden und zu erhalten. Dabei geht es nicht darum, die Autonomie der DevOps-Teams über Gebühr zu beschneiden, sondern sich täglich aufs Neue im Sinne aller Beteiligten auf einen gemeinsamen „Mainstream“ zu fokussieren.
Am Ende muss in einer DevOps-Organisation der gesamte Schwarm der beteiligten Menschen in der Lage sein, mithilfe von internen Communities, Self-Services, Dokumentation, Consulting durch interne Service-Provider-Teams und auch durch externe Unterstützung die eingesetzten Technologien zu betreiben und ein effizientes Onboarding neuer Teams zu gewährleisten.
Neben den in der Tendenz zentralen Architekturaufgaben fallen auch innerhalb der DevOps-Teams viele gewichtige Architekturentscheidungen an. Dedizierte Rollen gibt es selten in diesem Team, das bedeutet, dass Softwarearchitekten dort mehr Praxisbezug (Entwicklungstätigkeiten, Automatisierung, Testen) haben und stärker im Entwicklungsalltag eingebunden sind als in einer zentralen Architekturrolle.
Es macht Sinn, ein Team-Mitglied im DevOps-Team zu haben, dessen Steckenpferd die Softwarearchitektur ist (inkl. der oben genannten Aufgaben). Allerdings liegt die Qualität in der Verantwortung des ganzen Teams, weshalb auch die Architekturarbeit auf möglichst viele Schultern verteilt werden sollte.
