Wer macht Architektur bei Ihnen?

12.02.2024

Jedes Softwaresystem hat eine Architektur. Die Frage ist nur, ob sie explizit entworfen wird oder einfach nur „passiert“. Selbstverständlich werden sich ein besser wartbareres und funktionsfähigeres System erhalten, wenn Sie sich explizit um den Entwurf der Architektur kümmern.

Doch wie kann das aussehen? Wie können die Zuständigkeiten für die Architektur am besten aufgeteilt werden? Im Wesentlichen werden in der Praxis drei verschiedene organisatorische Formen gefunden:

  1. Der Architekt als Position
  2. Die Architektur-Rolle
  3. Architektur-Fertigkeiten

Sehen wir uns diese drei Formen im Detail an.

Der Architekt als Position

Die klassische Variante ist es, den Architekten als Position zu betrachten. Es gibt eine Person, den Softwarearchitekten, der sich exklusiv um die Zuständigkeiten der Softwarearchitektur kümmert. Meistens ist sie oder er erfahren:e Entwickler:in und hat eventuell auch Projektleitungserfahrung. In dieser Position wird nicht mehr viel Code geschrieben oder Tests durchgeführt. Man konzentriert sich auf die Architekturarbeit und entwickelt unter Umständen noch „architekturkritische“ Komponenten.

Die Erfahrung und Seniorität des Architekten als Position schlägt sich häufig auch in der Jobbezeichnung nieder. Mögliche Positionsbezeichnungen könnten sein:

  • Softwarearchitekt
  • Systemarchitekt
  • Systemdesigner
  • Enterprise Architect
  • Technical Architect
  • Solution Architect
  • Lead Engineer
  • Lead Developer
  • Technical Lead
  • etc.

Natürlich kann es hier beliebige Abwandlungen und Übersetzungen ins Deutsche oder Englische geben, sowie beliebige Senioritäts-Prefixe (Junior/Senior/Principal/etc.). Nicht jedes Unternehmen versteht das gleiche unter den jeweiligen Titeln. Ich persönlich bin der Meinung, dass ein Enterprise Architect und Lead Engineer/Lead Developer andere Funktionen über haben sollte als ein Softwarearchitekt. Aber in der Praxis sieht man eben diese verschiedenen Begriffe für einen Softwarearchitekten.

Architektur als Position sieht man häufig bei größeren Unternehmen, bei konservativen Unternehmen, oder auch wenn es sich um ein eher unerfahrenes Entwicklungsteam handelt, dass von eine:r Architekt:in geführt wird. Größere Unternehmen verwenden diese Variante deshalb gerne, weil sich ab einer gewissen Größe die Notwendigkeit der Aufgabenteilung und der Hierarchiebildung ergibt. Mitarbeiter:innen spezialisieren sich auf Themengebiete, unter anderem auch Architektur. Das diese Spezialisierung eher erfahrene Mitarbeiter:innen machen, liegt daran, dass Architekturentscheidungen häufig komplex und kostspielig sind. Deshalb setzt man auf die Erfahrung der Mitarbeitenden. Umgekehrt wird die Position des Architekten bzw. der Architektin als Aufstieg in der Karriereleiter gesehen. Mehr Erfahrung, mehr Verantwortung und mehr Gehalt.

Der Architekt muss aber nicht alleine agieren. Oft gibt es ganze Architekturteams, gerade wenn es sich um sehr große Systeme handelt. Auch eine Hierarchie innerhalb der Architekten ist denkbar.

Vorteile

  • Wenn du Architektur „aus einer Hand“ kommt, wirkt sich das positiv auf die Konsistenz aus.
  • Ebenso wird die konzeptionelle Integrität der Lösung unterstützt.
  • Es gibt klar definierte Verantwortlichkeiten und Zuständigkeiten.
  • Die Qualitätssicherung erfolgt zentral beim Architekten bzw. dem Architekturteam.

Nachteile

  • Unter Umständen besteht ein höherer Koordinationsaufwand zwischen Architekt:in und Entwicklungsteam.
  • Der bzw die Architekt:in kann zum Flaschenhals für Entscheidungen werden. Dadurch kommt es zu längeren Wartezeiten.
  • Bei Ausfall des Architekten bzw. der Architektin können keine Architekturentscheidungen getroffen werden.

Die Architektur-Rolle

Gerade, aber nicht nur in agilen Teams wird Architektur gerne in Rollen gelebt. Es gibt keine dezidierten Architekt:innen, sondern ein oder mehrere Personen im Entwicklungsteam übernehmen die Architektur-Rolle neben anderen Rollen. Typischerweise wird die Zuständigkeit für Architektur so auf mehrere Personen aufgeteilt und ein Team-Konsens für architekturrelevante Fragen gefunden.

Eine spannende Frage lautet hier natürlich: Wie kann ich Konsistenz in der Architektur garantieren, wenn mehrere Personen dafür zuständig sind? Viele Köche verderben ja bekanntlich den Brei.

Nun, der Kernpunkt ist hier natürlich die Zusammenarbeit. Grundlegende Architekturansätze und Prinzipien müssen innerhalb des Teams abgestimmt werden, um somit ein Regelwerk für Architekturentscheidungen zu erstellen. Innerhalb dieses Regelwerks können die einzelnen Rolleninhaber:innen eigenständig agieren. Es ist auch denkbar, dass die Zuständigkeiten nach Systemkomponenten oder anderen Kriterien aufgeteilt wird. Handelt es sich um ein Client-Server-System, kann ein Rolleninhaber für den Client und einer für den Server zuständig sein. Behandelt das System Funktionen für Lagerhaltung und Auslieferung, kann man einen fachlichen Schnitt ziehen und daran die Zuständigkeiten zuteilen.

Wichtige und weitreichende Entscheidungen sollten zwischen allen Rolleninhaber:innen abgestimmt werden. Wird keine Entscheidung gefunden, kann es helfen, das restliche Team mit einzubeziehen. Die Architekt:innen bereiten die Entscheidung vor und das gesamte Team stimmt ab.

Vorteile

  • Die Verantwortung lastet auf mehreren Schultern.
  • Ein personeller Ausfall kein leichter kompensiert werden.
  • Wenn mehrere Personen zusammenarbeiten, kann dies die Kreativität fördern und elegante Lösungen für komplexe Probleme fördern.

Nachteile

  • Geteilte Verantwortlichkeit kann auch bedeuten, dass niemand verantwortlich sein will.
  • Es ist ein höherer Abstimmungsaufwand zwischen den Rolleninhabern notwendig.
  • Entscheidungen werden eventuell inkonsistent getroffen, was im schlimmsten Fall zu einer chaotischen Architektur führen kann.

Architektur-Fertigkeiten

Die letzte Variante ist es, Architektur als Fertigkeit, als Skill zu sehen, den jeder Softwareentwickler besitzen soll. Genauso wie ein Entwickler programmieren und testen kann, soll er auch Architektur können. Dies ist natürlich die dezentralste Art, um Architekturverantwortung zu leben.

Hardliner würden behaupten, dass dies die einzig richtige Möglichkeit ist, denn Architektur muss eine Kernkompetenz eines jeden Entwicklers sein. Wenn wir uns überlegen, dass wir in der Entwicklung ständig Entscheidungen treffen und wir oft erst im Nachhinein sagen können, ob eine Entscheidung „architekturrelevant“ war, so ist dieser Gedanke nachvollziehbar. Auf der anderen Seite sollte hier aber auch das Thema der Erfahrung und Seniorität berücksichtigt werden.

Für diese Variante sollte eine transparente Kommunikation und eine Lernkultur im Team etabliert sein. Außerdem hilft es, wenn bereits Prozesse zur Modellierung und Dokumentation von Architektur eingesetzt werden. Dies kann als zentrales Mittel zur Wissensweitergabe betrachtet werden.

Ein weiterer Weg, um Wissen in der Softwarearchitektur zu teilen, sind Architekturreviews. Dabei wird die Architektur des Systems evaluiert, Risiken identifiziert und Verbesserungspotentiale gefunden. Gleichzeitig wird Wissen weitergegeben und Inkonsistenzen entdeckt. Die Reviews können von einem einzelnen oder von mehreren Reviewern durchgeführt werden. Ein Review sollte aber nicht zwischen Tür und Angel durchgeführt werden. Planen Sie Zeit dafür ein und erstellen Sie eine Vorgehensweise für das Architekturreview.

Nutzen Sie Tools, um Metriken zu ermitteln als weitere Maßnahme, um die Qualität der Architektur kontinuierlich zu überwachen. Tools wie nDepend, SonarQube, jArchitect und andere statische Codeanalysewerkzeuge, helfen diese Metriken automatisiert und ad hoc zu erstellen.

Vorteile

  • Das Verantwortungsgefühl im Team wird gestärkt.
  • Jeder im Team baut Kompetenzen in der Softwarearchitektur auf.
  • Weitere Vorteile wie bei der Architektur-Rolle.

Nachteile

  • Hier gilt mehr denn je: Gute Koordination und Richtlinien sind notwendig, sonst entsteht Chaos!
  • Erhöhter Kommunikations-, Dokumentations- und Reviewaufwand.
  • Weitere Nachteile wie bei der Architektur-Rolle.

Was ist der richtige Weg?

Sie werden es sich sicher denken: Es kommt drauf an. 😉

Jede Variante hat sein Für und Wider. Die richtige Wahl hängt von der persönlichen Philosophie, Unternehmensstrukturen, organisatorischen Randbedingungen und Projekterfordernissen ab. Diese Gegenüberstellung hilft aber vielleicht einen kritischen Blick auf seine eigenen Strukturen zu werfen, diese zu hinterfragen und eventuell Verbesserungen zu finden.

Raphael Dumhart

Raphael Dumhart hat über 10 Jahre lang die Softwareentwicklung einer der größten österreichischen Baukonzerne aufgebaut und geleitet. 2011 war er Mitgründer eines IT-Startups und 2020 Gründer und Geschäftsführer eines EduTech-Startups. Derzeit ist er als Berater und Trainer für Softwarearchitektur und Softwareentwicklung tätig.

Sie wollen mehr zu diesen Thema erfahren?

Lassen Sie uns Wissen in die Tat umsetzen und kontaktieren Sie mich noch heute!

Kontaktieren

Die neusten Blogposts