SW-Architektur ist schwierig

Ein Studium-Freund von mir arbeitet beim Tiefbauamt. Bei unserem letzten Treffen, zeigte er mir sein neustes Projekt. Als ich mir als Software-Ingenieur die Baupläne ansah, war ich ziemlich erstaunt. Sie hatten detaillierte, konkrete Pläne für die nächsten 3 Jahre. Die Bauingenieure unterteilten es in 3 Phasen, mit genauen Messungen und Straßenstrukturen für jede Phase. Sie hatten einen soliden Zeitplan. Und das Interessanteste daran ist, dass ich es leicht lesen konnte, und es war mir klar, obwohl ich 0 Kenntnisse im Bauingenieurwesen habe. Tatsächlich erstreckt sich dies auch auf andere Arten von Ingenieurwesen/Architektur. Denken Sie an Diagramme der Hausarchitektur, der Elektrotechnik oder des Maschinenbaus – es gibt einheitliche Möglichkeiten, diese so zu schreiben, dass alle anderen Ingenieure auf diesem Gebiet sie lesen können. Aber das ist bei der Softwareentwicklung nicht der Fall. Es ist zwar einfach, SW-Architektur-Diagramme in Software zu erstellen (mit Hilfe von Kästchen und Pfeilen, UML), aber sie zu lesen und zu verstehen, ist möglicherweise nicht einfach.

Der Unterschied zur Softwareentwicklung

Während meiner Karriere als Ingenieur habe ich zahlreiche SW-Architektur-Diagramme und Designdokumente erstellt, gelesen und überprüft und viele Interviews zum Systemdesign geführt. Ich habe festgestellt, dass Menschen Software sehr unterschiedlich beschreiben und vor allem die Grenzen von Beschreibungen nicht einhalten.

Anders bedeutet:

• Unterschiedliche Abstraktionsebenen
• Unterschiedliche Detaillierungsgrade
• Verschiedene Illustrations-/Diagrammtechniken
• Unterschiedliche Fokussierung auf nicht-funktionale Aspekte wie Zuverlässigkeit, Sicherheit, Datenschutz und Skalierbarkeit

Es ist üblich, solche Kommunikationslücken sogar im selben Team zu finden, ganz zu schweigen von verschiedenen Teams, Organisationen oder Unternehmen. Diese Lücken manifestieren sich zum Beispiel in Architekturdiagrammen, die nicht selbsterklärend sind. Sie sind entweder mit aussagekräftigen Formulierungen versehen (denken Sie an ein 10-seitiges Designdokument) oder erfordern viel Zeit, um sie zu erklären.

Diese Kommunikationslücken haben aufgrund eines aktuellen Trends in der Welt der Softwareentwicklung noch größere Auswirkungen.

Dezentralisierung der Rolle des Architekten

„Architektur als Teamsport:
Architekten arbeiten nicht mehr alleine, und Architekten können nicht mehr nur über technische Fragen nachdenken. Die Rolle eines Architekten ist in der Branche sehr unterschiedlich, und einige Unternehmen haben den Titel ganz gestrichen…“

InfoQ Bericht zu Softwarearchitektur- und Designtrends – April 2023

In der Vergangenheit haben die meisten Unternehmen und Organisationen einen Top-Down-Ansatz für SW-Design und -Architektur implementiert (V-Modell). Ein Architekten für jede ausreichend große Gruppe fungiert als zentrale Instanz für das Produkt-/Systemdesign. Es war üblich, dass Ingenieure Codierungsaufgaben auf der Grundlage einer bestimmten Architektur, Spezifikation und APIs ausführten.

Die Welt hat sich zu einem dezentraleren Ansatz verlagert, bei dem Ingenieure auf allen Ebenen an der Gestaltung und Architektur beteiligt sind, anstatt nur zu programmieren (Agile). Was zwischen den verschiedenen Ebenen und Fähigkeiten von Ingenieuren variiert, ist der Umfang ihrer Arbeit – zum Beispiel könnten Junior-Ingenieure eine bestimmte Komponente entwerfen, während erfahrenere Ingenieure ein System oder eine Multi-System-Umgebung entwerfen können.

Im Grunde handelt es sich dabei um einen Kultur- und Mentalitätswandel vom zentralisierten Top-down-Designprozess zu einem dezentralen Bottom-up-Prozess, der allen gehört.

Die Kosten

Diese Änderung bringt viele Vorteile mit sich: Befähigung und Entwicklung von Ingenieuren aller Ebenen, ein erhöhtes Gefühl der Eigenverantwortung und des Engagements, die Eliminierung des Single Point of Failure und eine bessere Verteilung des Wissens in den Teams.

Es ist jedoch auch mit Kosten verbunden:

• Qualität: Ein Architekt ist in der Regel als erfahrener Ingenieur qualifiziert und verfügt über langjährige Erfahrung im Aufbau und der Wartung von Softwaresystemen. Diese Arbeit auf alle im Team zu verteilen bedeutet, dass es keine weitere Qualifikation gibt, abgesehen davon, Teil des Teams zu sein. Um eine hohe Qualität zu gewährleisten, müssen die Teams in Schulungen, Schulungen und Mentoring investieren, einen guten Designprozess aufbauen und eine offene Feedback-Kultur einführen.
• Gemeinkosten: Ein solider Designprozess in der Organisation trägt dazu bei, die Qualitätsmesslatte zu erhöhen, führt jedoch zu einem erheblichen Aufwand. In der Regel umfassen solche Prozesse die Erstellung eines Designdokuments, von Systemdiagrammen, Flussdiagrammen und beinhalten einen Feedback-Prozess, der mehrere Iterationen und Durchläufe des Designs erfordern kann.

Die Implementierung eines gesunden Designprozesses in einer Organisation ist eine Herausforderung. Es besteht eine Spannung zwischen dem dadurch verursachten Aufwand und dem durch den Prozess erzielten Qualitätsgewinn. Ist das Verfahren zu leicht oder gar nicht vorhanden, gibt es keinen Qualitätsgewinn. Wenn der Prozess zu umfangreich ist, kann er für Ingenieure belastend werden, da sie sich möglicherweise nicht vollständig daran halten oder sogar nach Möglichkeiten suchen, ihn zu umgehen – was letztendlich zu einer verringerten Effizienz führt. Der Sweet Spot liegt wie immer etwas dazwischen.

Ein praktisches Fazit: Das Modell C4

Es gibt viel zu diskutieren, wie ein gesunder Designprozess aussehen sollte, aber ein praktisches Konzept, das ich hervorheben möchte, ist das C4-Modell.

Visualisierungen sind ein wichtiger Bestandteil im Softwaredesign. Wie oben erwähnt, wird Software sehr unterschiedlich beschrieben, insbesondere wenn es um Softwarediagramme geht.

Diagrammerstellung -> Modellierung

Das C4-Modell zielt darauf ab, die kurzlebigen, freien Diagrammtechniken zu einer langlebigen, kanonischen und standardisierten Modellierungstechnik weiterzuentwickeln. Sie können es sich als eine Reihe von Regeln und Konventionen vorstellen, wie Softwarearchitektur visualisiert und beschrieben werden sollte (ähnlich den Standards, die in anderen technischen Bereichen existieren).

4 Schichten

Das C4-Modell besteht aus 4 Schichten von Abstraktionen (daher der Name):

1. System Context: die höchste Abstraktionsebene. Diese Schicht enthält interne Systeme, externe Systeme, Benutzer (wenn es mehrere Arten von Benutzern gibt, sollten diese angegeben werden) und die Beziehungen zwischen den 3 von ihnen.
2. Container: Sobald Sie Ihre Systeme eingerichtet haben, können Sie in ein bestimmtes System hineinzoomen. Ein System besteht aus einem oder mehreren Containern. Ein Container stellt eine Anwendung oder einen Datenspeicher dar, wie z. B.: Backend-Dienst, Frontend-Anwendung, mobile Anwendung, relationale Datenbank, Schlüssel-Wert-Speicher, Nachrichtenbus, Objektspeicher usw.
   
   Eine einfache Möglichkeit, darüber nachzudenken, zumindest aus der Backend-Perspektive, ist es, über separate Prozesse/ausführbare Dateien nachzudenken. Jede ausführbare Datei wird einem eigenen Container zugeordnet.
   
   Wenn Sie bereits ein Interview zum Systemdesign hatten, konzentriert es sich in der Regel auf die Containerschicht.
3. Komponente: Als nächstes kann ein Container in mehrere Komponenten unterteilt werden, in der Regel nach Funktionalität und Verantwortungsbereichen. Wenn wir zum Beispiel einen Backend-Zahlungsdienst nehmen, könnte er Komponenten enthalten wie: Zahlungsvollstrecker, 3rd-Party-Client, Wiederherstellungsmechanismus, Zahlungsrekorder, Absender der Benachrichtigung usw.
   
   Es ist in Ordnung, dass die Komponenten eines Containers mit anderen Containern aus Schicht 2 interagieren – zum Beispiel könnte der Wiederherstellungsmechanismus eine Nachricht an den Nachrichtenbus senden, um eine fehlgeschlagene Zahlung in einer bestimmten Verzögerung zu wiederholen.
4. Code: Dies ist die Zuordnung von Komponenten zu tatsächlichen Codeklassen/Modulen/etc. Diese Schicht von Implementierungsdetails ist in der Regel weniger interessant und sehr schwer zu pflegen und wird im Allgemeinen für die meisten Anwendungsfälle nicht empfohlen.
   
   Beim Schreiben von Code kann es jedoch hilfreich sein, sich zu überlegen: „In welche Komponente passt mein Code?„; Wenn die Antwort nicht klar ist, erstellen Sie entweder eine neue Komponente oder Sie verletzen die vorhandenen Grenzen von Komponenten.

Ein paar Anmerkungen zum Modell C4

• Container und Component sind die kritischen Layer. Um die Essenz dieser Schichten klar zu machen: Ihre Designentscheidungen auf der Container-Schicht wirken sich auf Skalierbarkeit, Zuverlässigkeit, Bereitstellung und Weiterentwicklung aus.
  Ihre Designentscheidungen auf der Komponentenebene wirken sich auf die Geschwindigkeit, Effizienz, Wartbarkeit und Qualität der Entwickler aus.
• Das C4-Modell verleiht Diagrammen der SW-Architektur Tiefe. Stellen Sie es sich wie eine Online-Karte vor – Sie beginnen mit der High-Level-Ansicht und können an Sehenswürdigkeiten heranzoomen. Falls Sie sich zu sehr in die Details vertieft haben, können Sie auch wieder herauszoomen und sich in der übergeordneten Architektur wiederfinden.
• Das C4-Modell ist ein kollaboratives, langfristiges Modell. Anstatt dass jeder Techniker seine eigenen Ad-hoc-Diagramme erstellt, kann das C4-Modell von mehreren Ingenieuren oder Teams gemeinsam genutzt und bearbeitet werden, wobei es mit dem Wachstum der Organisation und des Produkts erweitert wird.
• Es gibt eine Vielzahl von Tools, die das C4-Modell unterstützen. Heutzutage verfügen sogar gängige Unternehmensdiagramm-Software über eine C4-Vorlage.

Fazit

SW-Architektur ist ein entscheidender Bestandteil des Lebenszyklus der Softwareentwicklung und hat einen erheblichen Einfluss auf das Endergebnis des Produkts oder Systems, die Ausführungsgeschwindigkeit, die Wartbarkeit und die Weiterentwicklungsfähigkeit.

Mit den jüngsten Trends zur Dezentralisierung der Architektenrolle und der Einführung von „Architektur als Teamsport“ verändert sich die Struktur von Softwareteams und Unternehmen müssen sorgfältig darüber nachdenken, wie ihr Designprozess aussehen sollte, und die richtige Balance zwischen der Einführung von Overhead und der Aufrechterhaltung einer hohen Qualitätsleiste finden.

Ein weiterer Beitrag: Lernen beim Refactoring eines 40 Jahre alten Softwareprojekts