3 Arten der Zuständigkeit für Architektur

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

Bevor wir uns diese drei Formen der Zuständigkeit im Detail ansehen, möchte ich die allgemeinen Aufgaben des Softwarearchitekten klären.

Aufgaben, Zuständigkeiten und Verantwortung eines Architekten

Die Aufgaben eines Softwarearchitekten können je nach Organisation und Projekt variieren, aber hier sind einige typische Verantwortlichkeiten:

• Systementwurf: Der Softwarearchitekt entwirft die Struktur des gesamten Systems oder großer Teile davon. Dies umfasst die Definition von statischen Aspekten wie Strukturen, Komponenten und Schnittstellen, aber auch dynamische Aspekte wie Interaktionen und Workflows.
• Mitarbeit in der Anforderungsanalyse: Funktionale Anforderungen des Systems müssen auf technische Machbarkeit bewertet und Lücken gefunden werden. Architekten sind oftmals federführend für die Qualitätsanforderungen des Systems zuständig.
• Technologieauswahl: Basierend auf den Anforderungen des Projekts wählt der Softwarearchitekt die geeigneten Technologien, Plattformen und Frameworks aus, die für die Entwicklung verwendet werden sollen.
• Festlegen von Prinzipien und Richtlinien: Der Architekt legt Prinzipien und Richtlinien fest, die das Entwicklerteam bei der Implementierung befolgen sollte. So wird die konzeptionelle Integrität und die Wartbarkeit des Systems gewährleisten.
• Entwurf von Schnittstellen: Der Architekt entwirft die verschiedenen externen und internen Schnittstellen. Der Fokus liegt hier insbesondere bei den externen Schnittstellen, die andere Systeme bzw. Team-fremde Personen verwenden.
• Kommunikation: Der Architekt fungiert als Vermittler zwischen den technischen und nicht-technischen Stakeholdern, um sicherzustellen, dass die Anforderungen klar verstanden werden und die technische Vision des Projekts kommuniziert wird. Auch die Erstellung und Pflege vom Architekturdokumentationen und Modellen gehört hier zu den Aufgaben.
• Qualitätssicherung: Die Qualität der Architektur und des Codes werden durch den Softwarearchitekt überprüft. Dazu werden regelmäßige Reviews und Analysen durchgeführt, um sicherzustellen, dass die implementierten Lösungen den architektonischen Standards entsprechen und die Architektur den Qualitätsanforderungen des Systems genügen.
• Risikomanagement: Der Softwarearchitekt ist für technisches Risikomanagement zuständig. Dabei werden potenzielle Risiken identifiziert, bewertet und geeignete Maßnahmen zur Risikominderung entwickelt.

Gegebenenfalls können diese Zuständigkeiten auch noch erweitert und abgeändert werden. Wie gesagt ist dies vom Projektkontext und der Organisation abhängig.

Organisatorische Formen der Architektur-Zuständigkeit

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 Erfahrungen in der Projektleitung und dem Umgang mit Endkunden. In dieser Position wird typischerweise 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 Personen die für Softwarearchitektur zuständig sind..

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. Innerhalb einer größeren Organisation ergibt sich fast zwangsläufig die Notwendigkeit Aufstiegschancen zu ermöglichen und deshalb verschiedene hierarchische Positionen zu schaffen. Das Motto lautet: Mehr Erfahrung, mehr Verantwortung und mehr Gehalt.

Der Architekt muss aber nicht als Einzelkämpfer agieren. Gerade wenn es sich um sehr große Systeme handelt, gibt es oft ganze Architekturteams. Auch eine Hierarchie innerhalb des Architekturteams ist denkbar, indem zwischen einem Teamleiter und gegebenenfalls Junior- und Senior-Positionen unterschieden wird.

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, testen und deployen 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 und -Konservierung 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.

Bei dieser Variante gilt mehr den je, dass alle Teammitglieder ein ähnliches Verständnis für die Aufgaben und die Arbeitsweisen in der Softwarearchitektur haben sollen. Ich empfehle hier gerne internationale Zertifizierungen wie der Certified Professional for Software Architecture (CPSA) der iSAQB. Natürlich bin ich hier als Trainer etwas voreingenommen, aber trotzdem ist es meiner Meinung nach eine gute Möglichkeit um Wissenslücken zu schließen und ein gemeinsames Verantwortungsverständnis für Architektur zu erlangen. CPSA-Schulungen kann ich Ihnen gerne über Software Quality Lab Academy anbieten.

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 für die Zuständigkeit?

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.