Architektur ohne Firlefanz – Ihre Lösung auf einem Bierdeckel
Viele interessieren sich für Ihre Softwarelösung oder zumindest für Teilaspekte davon: Neue im Team, teamfremde Kollegen, Manager, Kooperationspartner... – Wie geben Sie diesen Leuten einen prägnanten Einstieg? In diesem Beitrag erfahren Sie, wie Sie Schritt für Schritt einen prägnanten Architekturüberblick anfertigen. Ich diskutiere, was mindestens hineingehört und welche Formate sich in unterschiedlichen Situationen bewähren.
In der CDU wird gerade wieder viel über Friedrich Merz gesprochen. Sogar in der Jungen Union. Den Älteren unter uns ist er während seines politischen Sabbaticals (ca. 2009-2018) mit einer inspirierenden Idee aus seiner Zeit als Oppositionsführer in Erinnerung geblieben. Jeder Bürger solle seine Einkommenssteuer auf einem Bierdeckel ausrechnen können! Für viele, die das grau-grüne Chaos des kafkaesken Mantelbogens mit Anhang N, KAP, SO etc. erlebt haben, musste dieses Versprechen verlockend klingen. Mich eingeschlossen.
Architekturen beschreiben in grün und grau?
In vielen Entwicklungsteams herrscht eine ähnlich geringe Begeisterung für Dokumentation wie für das Ausfüllen der Steuerformulare. Wobei das Anfertigen von Architekturbeschreibungen verglichen mit API oder Quelltext-Dokumentation sogar noch am unteren Ende der Skala rangiert.
Das hat Gründe. Softwarearchitektur fühlt sich für viele Entwickler schwergewichtig und abgehoben an. Sie verbinden damit detailreiche UML-Diagramme und farbenprächtiges Visio großen Ausmaßes und tiefer Schachtelung. Bei zugehöriger Dokumentation kommen ihnen dicke Word-Dokumente und PowerPoint-Präsentationen mit dreistelliger Folienzahl in den Sinn.
Mitunter höre ich von Teams als Argument gegen das Festhalten ihrer Architektur, die Sachen würden ohnehin veralten. Der Quelltext sei die beste Dokumentation. Denen widerspreche ich gern mit dem Leitspruch von Simon Brown: "Der Quelltext erzählt nicht die ganze Geschichte" (wörtlich: "The code doesn't tell the whole story."[1]).
Quelltext hat unbestreitbar Vorteile als Informationsquelle. Änderungen sind durch die Versionsverwaltung leicht nachvollziehbar und er bleibt stets aktuell zur entwickelten Lösung. Gleichzeitig lassen sich bestimmte Aspekte gerade bei umfangreichen Softwaresystemen gar nicht oder nur schwer aus dem Source-Code allein herauslesen. Das gilt insbesondere für jemanden, der neu ins Team kommt. "Warum habt Ihr das so gemacht?" ist eine oft gehörte Frage. Oder auch anders herum: "Warum benutzt Ihr nicht ...?". Solche Fragen zielen auf zentrale Entscheidungen ab. Der Quelltext schweigt. Hat Ihr Team Antworten?
Entscheidungen nachvollziehbar vermitteln
Ich verstehe Softwarearchitektur als Summe wichtiger Entscheidungen, die
- später schwer zu ändern sind,
- viele im Vorhaben betreffen und
- den Erfolg der Software maßgeblich beeinflussen.
In jedem software-intensiven Vorhaben gibt es solche Fragestellungen. Abb. 1 vermittelt mögliche Themenbereiche und zeigt dabei gleichzeitig, wie vielfältig die zu lösenden Probleme sind.
Eine wirkungsvolle Architekturdokumentation hält die zentralen Entscheidungen des beschriebenen Systems nachvollziehbar fest. Sie unterstützt Sie und Ihr Team bei der Kommunikation mit relevanten Zielgruppen. Je nach Vorhaben könnten das z. B. diese sein (mit unterschiedlicher Intention):
- Neue Teammitglieder (die mitentwickeln wollen, und sich in der Software nicht zurechtfinden).
- Entscheider und andere Stakeholder (die Unsicherheiten haben oder geringes Vertrauen in Ihre Lösung).
- Teamfremde Kollegen (die an Lösungsansätzen interessiert sind, aber keine oder nur sehr detaillierte Informationen finden).
Hier soll es nicht um umfangreiche Dokumentation gehen, sondern um das Minimum für den ersten Eindruck: Einen prägnanten Architekturüberblick! Gut gemacht kann er auch nicht alle Fragen beantworten. Für Details fragt der Interessierte nach oder schaut woanders, mitunter auch in den Quelltext. Der Überblick bietet einen anregenden Einstieg und unterstützt Sie und Ihr Team beim Vermitteln der zentralen Lösungsansätze.
Ohne einen solchen Überblick müssten Sie Außenstehenden die Architektur Ihrer Software jedes Mal aus dem Stegreif erklären. Falls sie sich erinnern. Im Extremfall führen Sie auch regelmäßig die immer gleichen Diskussionen – mitunter sogar innerhalb Ihres Teams.
Was gehört mindestens in einen Architekturüberblick?
arc42 – der etablierte Gliederungsvorschlag für Architekturbeschreibungen [2] – begleitet viele Entwicklungsvorhaben beim Dokumentieren ihrer Softwarearchitektur. Er ist insbesondere in der DACH-Region etabliert. Durch vermehrt verfügbare englischsprachige Fachliteratur (z. B. [3]) hat er sich auch darüber hinaus verbreitet.
Mit seinen 12 Abschnitten taugt das arc42-Template in voller Ausbaustufe allerdings nicht als Mindestumfang für einen Architekturüberblick. Auch wenn vieles für seine Verwendung spräche. Es wäre zu groß.
Wir verfolgen daher einen kompakteren Ansatz:
- ausgehend von der Aufgabe,
- wenige Inhalte und
- nachvollziehbar durch Einbeziehung der Einflüsse.
Abb. 2 zeigt das Rezept im Überblick – auf einem Bierdeckel sozusagen. Tabelle 1 beschreibt mögliche Inhalte (Zutaten) und klärt, ob sie aus meiner Sicht verpflichtend für einen prägnanten Überblick sind. Was gehört also zwingend hinein?
Tabelle 1: Mögliche Inhalte eines prägnanten Architekturüberblicks
| Zutat | Beschreibung und Form | Verpflichtend für Überblick |
|---|---|---|
| Mission Statement | Plakative Darstellung der Aufgabenstellung. Kurzer Text. | Ja. |
| Kontextabgrenzung | Visualisierung der Fremdsysteme und Benutzer, mit denen das System interagiert. Diagramm mit Erläuterungen. | Ja. Kann im prägnanten Überblick entfallen, falls ein informelles Überblicksbild (s. u.) den Aspekt mit abdeckt. |
| Rahmenbedingungen | Die wichtigsten technischen bzw. organisatorischen Vorgaben, die beim Entwurf einzuhalten sind (bzw. waren). Liste oder Tabelle. | Ja, aber nur Ausschnitt. Kann nur entfallen, wenn Vorgaben für die Zielgruppe allgemein bekannt sind, und/oder nicht prägend für die Lösung waren. |
| Qualitätsziele | Die wichtigsten (Top 3-5) an das System gestellten Qualitätsanforderungen ("-ilities"), inkl. Motivation. Tabelle. | Ja. Kann im prägnanten Überblick als Spalte in der Lösungsstrategie (s. u.) aufgehen. |
| Informelles Überblicksbild | Visualisierung der Lösung mit Betonung der zentralen Architekturansätze (z. B. Stil, Muster, Struktur ...) – kein UML. | Nein. Falls es entfällt ist die Kontextabgrenzung (s. o.) verpflichtend aufzunehmen. |
| Lösungsstrategie | Tabelle mit Qualitätszielen und zugeordneten high-level Lösungsansätzen, mit Verweisen auf Überblicksbild und Lösungsdetails. Tabelle. | Ja. Nennt die zentralen Ideen (= folgende Zeilen dieser Tabelle), die daher im Überblick alle optional sind (in dieser Spalte: "Nein"). |
| Architekturstil | Prägendes Muster der Lösung. Name und Ausgestaltung. Kurzer Text. | Nein (siehe Lösungsstrategie). |
| Technologie-Stack | Aufzählung der verwendeten Programmiersprache(n), Frameworks, Middleware... | Nein (siehe Lösungsstrategie). |
| Grobe Zerlegung | Fachliche Gliederung auf oberste Ebene, inkl. Beziehungen. Diagramm. | Nein. Oft im Überblicksbild skizziert. |
| Technisches Konzept | Darstellung einer systemübergreifenden Idee für ein in der Regel technisches Thema (z. B. Persistenz-Konzept). Ausarbeitung als Text. | Nein. Im Überblick i. d. R. nur Nennung. |
Die Aufgabe (Bierdeckel, linke Seite oben)
Am Beginn steht stets die Aufgabenstellung – quasi das Mission Statement für das zu beschreibende Softwaresystem. Sie beantworten mit wenigen Sätzen die folgenden Leitfragen:
- Wozu ist das Software-System da?
- Was ist das zentrale Verkaufs-/ Nutzungsargument? ("Claim", "Slogan")
- Wem nützt es?
- Was sind die wesentlichen Features des Systems?
- Wie unterscheidet es sich von Produkten der Mitbewerber oder der Vorgängerversion?
Wenn Sie eine besonders kompakte Form anstreben, verdichten Sie Ihre Antworten auf wenige (2-3) prägnante Sätze. Stellen Sie sich vor, Sie müssten Ihr Vorhaben auf einer Webseite kurz und knackig "verkaufen". Sie können sich dabei an echten Systemen orientieren. Tabelle 2 enthält zur Inspiration Kurzbeschreibungen einiger Softwarelösungen, entnommen direkt von den Webseiten der Anbieter.
Tabelle 2: Beispiele für Mission Statements
| Name | Beschreibung auf der Webseite (Ausschnitt) |
|---|---|
| Kubernetes | Kubernetes (K8s) ist ein Open-Source-System zur Automatisierung der Verteilung, Skalierung und Verwaltung von containerisierten Anwendungen. Es wurde nach den gleichen Prinzipien entwickelt, die es Google ermöglichen, Milliarden von Containern pro Woche zu betreiben ... |
| Spotify | Spotify ist ein digitaler Streaming-Dienst für Musik, Podcasts und Videos, mit dem du Zugriff auf Millionen Songs und andere Inhalte von Künstlern aus der ganzen Welt hast. ... Spotify ist auf verschiedenen Geräten, einschließlich Computern, Smartphones, Tablets, Lautsprechern, Fernsehern und in Autos, verfügbar. |
| Affinity Photo | Wenn Sie selbst eine Software für die Fotobearbeitung zusammenstellen könnten, würde sie genau so arbeiten. Ob Sie nun schnelle Korrekturen benötigen, eine detaillierte Retusche umsetzen müssen oder einfach nur ein komplexes Kunstwerk aus Hunderten von Ebenen erschaffen möchten – Affinity Photo ist für alles gerüstet. ... |
Dieser Beitrag zeigt als durchgängiges Beispiel Zutaten eines prägnanten Architekturüberblicks für Atlassian Confluence [4]. Er bezieht sich der Einfachheit halber auf Version 2.x der verbreiteten Wiki-Software.
Das Mission Statement könnte so lauten: "Confluence ermöglicht es Entwicklungsteams effizient zusammenzuarbeiten und Informationen zu teilen. Es besticht durch eine "Auspacken und Los geht's"-Installation, die webbasierte Oberfläche ist leicht zu erlernen. Sie können Confluence auch über eine umfassende Remote-API ansprechen. Reicht nicht? Greifen Sie auf zahlreiche 3rd-Party-Erweiterungen zu oder entwickeln Sie Ihre eigenen!".
Neben dem Mission Statement ist es stets ratsam, eine Kontextabgrenzung (auch: Systemkontext) anzufertigen. Diese verbreitete Technik (zum Nachlesen z. B. [5]) visualisiert das zu beschreibende System als Blackbox und versammelt die Benutzer und Fremdsysteme, mit denen das System direkt interagiert, drumherum. Abb. 3 zeigt einen einfachen Systemkontext für Confluence.
Maßgebliche Einflüsse erheben
Schließlich erheben Sie für die Aufgabenstellung noch die wichtigsten architekturrelevanten Anforderungen: Rahmenbedingungen und Qualitätsziele.
Rahmenbedingungen sind Vorgaben, die beim Entwurf einzuhalten sind (bzw. waren). Diese schränken Sie und Ihr Team bei Entscheidungen ein – Optionen fallen weg, der Lösungsraum wird kleiner. In einen prägnanten Architekturüberblick nehmen Sie lediglich diejenigen Vorgaben auf, die großen Einfluss auf Ihre Lösung hatten. Das können sowohl organisatorische Vorgaben sein (z. B. Termine, Budget, Team ...) als auch technische (Zielumgebung, Middleware, ...).
Qualitätsziele sind diejenigen Merkmale, auf die Ihre Architektur im Idealfall fokussiert. Im Deutschen neigen diese Eigenschaften dazu, auf "-heit" und "-keit" zu enden (Sicherheit, Benutzbarkeit ...). Abb. 4 präsentiert die Hauptbegriffe aus der entsprechenden DIN/ISO-Norm. Weitere "-heiten", "-keiten" und "-täten" ordnen sich diesen Kategorien unter, etwa Erlernbarkeit unter Benutzbarkeit oder Verfügbarkeit unter Zuverlässigkeit.
Für Ihren Architekturüberblick identifizieren Sie als Ziele die wichtigsten an das System gestellten Qualitätsanforderungen – die Top 3-5. Ich empfehle, nicht nur die Eigenschaft zu nennen, sondern sie mit einem Adjektiv zu versehen (z. B. "intuitive Erlernbarkeit") und mit einem oder zwei Sätzen zu motivieren. Was bedeutet das Ziel in Ihrem Vorhaben? Warum ist es wichtig? Erst diese Erläuterungen ermöglichen ein gemeinsames Verständnis. Die Merkmale allein – Effizienz, Zuverlässigkeit ... – sind zu abstrakt. Tabelle 3 beschreibt als Beispiel die Qualitätsziele von Confluence in der empfohlenen Form.
Tabelle 3: Qualitätsziele für Confluence 2.x
| Qualitätsziel | Beschreibung |
|---|---|
| Leicht zu betreiben | Für ein Team ist es einfach, mit Confluence zu starten. |
| Gute Benutzbarkeit | Confluence ist effizient und intuitiv von allen Teammitgliedern zu verwenden. |
| Hohe Zuverlässigkeit | Das System steht den Anwendern jederzeit zur Verfügung. |
| Gute Wartbarkeit | Confluence ist leicht zu ändern und um Funktionalität zu erweitern. |
| Sicherheit der Inhalte | Inhalte sind vor unberechtigtem Zugriff und Veränderung geschützt. |
Die Beschreibung der Ziele in dieser Form reicht aus, um eine erste Idee zu vermitteln. Sie dienen bei Architekturbewertungen [6] als Ausgangspunkt, um qualitative Anforderungen durch Szenarien weiter zu konkretisieren.
Die Brücke zur Lösung schlagen
Bei Ihrer Softwarearchitektur geht es vor allem darum, mit geeigneten Entscheidungen die Qualitätsziele zu erreichen, unter Einhaltung der Rahmenbedingungen. Eine Gegenüberstellung der Ziele mit Lösungsansätzen (welche die Ziele unterstützen) ist daher eine besonders kompakte Form, um einen Einstieg in die Architektur zu geben. Wir bezeichnen sie im Folgenden als Lösungsstrategie.
Als Format empfehle ich eine Tabelle mit zwei Spalten: Links die Qualitätsziele, rechts die besten Argumente, die Sie haben, um dem Risiko zu begegnen, dass Sie und Ihr Team diese Ziele verfehlen. Als mögliche Lösungsansätze (rechte Spalte) kommen dabei in Betracht:
- Architekturentscheidungen, z. B. Verwendung eines Application Server Clusters (Ziel: hohe Ausfallsicherheit).
- Architekturstile, z. B. Microservices (Ziel: schnelle Adaption neuer technologischer Trends).
- Architekturmuster, z. B. Schichten (Ziel: einfache Portierung der Lösung).
- Architekturprinzipien, z. B. "Bevorzuge Standards vor proprietären Lösungen" (Ziel: niedrige Wartungsaufwände).
- Konzepte, z. B. Caching-Konzept (Ziel: Effizienz, gute Antwortzeiten).
- Vorgehen, z. B. user-centered Design (Ziel: intuitive Benutzbarkeit).
Zur Illustration enthält Tabelle 4 passende Lösungsansätze zu den Qualitätszielen zu Confluence.
Tabelle 4: High Level Lösungsstrategie für Confluence 2.x
| Qualitätsziel | Lösungsansätze in Confluence |
|---|---|
| Leicht zu betreiben |
|
| Gute Benutzbarkeit |
|
| Hohe Zuverlässigkeit |
|
| Gute Wartbarkeit |
|
| Sicherheit der Inhalte |
|
Falls Rahmenbedingungen Ihres Systems gut passen, können Sie in der rechten Spalte auch diese aufführen – gemeinsam mit den eigenen Entscheidungen und Konzepten. Vielleicht hatten Sie und Ihr Team z. B. Technologien vorgegeben, welche die Qualitätsziele gut unterstützen.
Aus der Tabelle lässt sich direkt ein informelles Überblicksbild der Architektur ableiten. Sie nehmen dazu diejenigen Lösungsansätze aus der rechten Spalte, die sich gut visualisieren lassen, und versammeln Sie in einer Abbildung (s. schematische Darstellung in Abb. 5).
Abb. 6 zeigt ein entsprechendes Überblicksbild, das ich aus den Lösungsansätzen aus Tabelle 4 abgeleitet und um Elemente aus der Kontextabgrenzung ergänzt habe. Ein weiteres Beispiel für eine solche Lösungsstrategie inklusive abgeleitetem Schaubild finden Sie auf der Webseite zu DokChess [7]. Die Architekturbeschreibung dort ist nach arc42 gegliedert und zeigt daher gleichzeitig, wie sich der Lösungsstrategieansatz in das verbreitete Template einfügt.
Einen Überblick Schritt für Schritt anfertigen
Ihren prägnanten, minimalen Architekturüberblick fertigen Sie initial in drei Schritten an:
- Zielgruppe auswählen
- Wenige Zutaten anfertigen
- Geeignete Form auswählen und die Inhalte einfügen – Zeigen!
Unterschätzen Sie dabei nicht den ersten Schritt – er wird leider oft vergessen. Machen Sie die Zielgruppe Ihres Architekturüberblicks und deren Ziele stichpunktartig explizit. Richten Sie im Anschluss Inhalte und Form daran aus! Entscheider interessieren sich beispielsweise eher für organisatorische, Entwickler hingegen für technische Rahmenbedingungen. Mitunter identifizieren Sie verschiedene Zielgruppen. Konsequenterweise fokussieren Sie zunächst auf eine davon und fertigen später weitere Überblicke an.
Zum zweiten Schritt: In diesem Beitrag haben Sie bereits wichtige Zutaten für Ihren Architekturüberblick kennengelernt (für Details verweise ich auf Tabelle 1):
- Mission Statement,
- Kontextabgrenzung (entfällt ggf., falls im Überblicksbild mit gezeigt),
- Qualitätsziele,
- Rahmenbedingungen (entfällt ggf., falls nicht entscheidend),
- Lösungsstrategie und
- Informelles Überblicksbild (entfällt, wenn Kontextabgrenzung "genügt").
Fertigen Sie die zentralen Bestandteile nun initial an, gerne gemeinsam mit Ihrem Team in einem kleinen Workshop. Ich empfehle, erste Ergebnisse bereits früh zu teilen und die Rückmeldungen in weitere Iterationen einfließen zu lassen. Die Zielgruppe kann die Gebrauchstauglichkeit Ihrer Inhalte am besten beurteilen.
Um das Ganze zu präsentieren, müssen Sie die Inhalte noch "in Form" bringen (Schritt 3). D. h. Sie müssen diese geeignet zusammenstellen, um sie mit Interessierten durch zusprechen.
Grundsätzlich haben unterschiedliche Formen jeweils ihre Stärken und Schwächen. Abb. 7 vergleicht gängige und auch weniger verbreitete Optionen. Der Bierdeckel ist zwar nicht dabei, die gezeigten Minimalzutaten kriegen Sie aber problemlos auf einem Flyer untergebracht. Zumindest wenn er geeignet gefaltet 4 DIN-A4-Seiten beinhaltet. Dann sind alle hier gezeigten Zutaten "drin".
Eine praxistaugliche Form für Neue im Team ist als Variante zum Flyer auch die Verwendung einer DVD-Leerhülle. Für diese gestalten Sie ein geeignetes Cover (Vorder- und Rückseite + Rücken). Im ersten Wurf von Hand auf ein weißes Blatt, später z. B. mit PowerPoint und auf DIN-A4 ausgedruckt. Zurechtgeschnitten schieben Sie das Resultat in die Leerhülle ein. Vorlagen dazu gibt es auch [8].
Den Neuen im Team drücken Sie die DVD-Hülle einfach in die Hand: "Daran bauen wir hier." – Oft ein vergnüglicherer Einstieg als "Schau' einfach im Wiki nach".
Fazit
Der Quelltext erzählt nicht die ganze Geschichte. Ihr Softwaresystem erschließt sich nicht von selbst. Prägnante Architekturüberblicke unterstützen Sie und Ihr Team bei der Kommunikation. Ein guter Architekturüberblick orientiert sich dabei in Form und Inhalt an der Zielgruppe. Bei sehr unterschiedlichen Adressaten brauchen Sie in der Regel auch mehrere Überblicke.
Nachvollziehbare Entscheidungen sind dabei der Schlüssel gegen "historisch gewachsen". Hierzu sind Aufgabenstellung und Einflüsse neben den Lösungsansätzen als Inhalt unabdingbar. Die Lösungsstrategie in Form der gezeigten Tabelle – unterstützt durch ein informelles Überblicksbild – schlägt hier die Brücke.
Sich an Inhalten vorhandener Architekturüberblicke, wie etwa denen zu Confluence in diesem Artikel, [3] oder [7] zu orientieren, gibt Ihnen Anregungen und Sicherheit. In diesem Zusammenhang möchte ich Sie auch auf den Architekturüberblick zum Build-System Gradle hinweisen [9]. Das e-Book enthält die hier gezeigten Zutaten (Qualitätsziele, Lösungsstrategie, ...), noch einige mehr, motiviert sie und erklärt, wann sie passen und wofür sie gut sind. Die Inhalte sind auch online verfügbar, wie z. B. [5].
Vor allem aber möchte ich Sie zum Schluss ermutigen, das Rezept auf eines Ihrer Softwaresysteme anzuwenden. Am besten gemeinsam im Team. Klein anfangen, früh zeigen!
- Simon Brown: Software Architecture for Developers: Volumes 1 & 2
- Informatik Aktuell – Gernot Starke: arc42 – Architekturen effektiv kommunizieren
- Gernot Starke, Michael Simons, Stefan Zörner & Ralf D. Müller: arc42 by Example – Real software architectures, documented with the arc42 template
- Atlassian Confluence
- Systemkontext im arc42-Starschnitt: Gradle
- Informatik Aktuell – Stefan Zörner: Was ist eigentlich Architekturbewertung?
- DokChess, ein Architekturüberblick strukturiert nach arc42 (Deutsch und Englisch),
- Vorlagen und Tipps für Architekturüberblicke auf DVD-Hüllen
- Stefan Zörner: arc42-Starschnitt: Gradle. Ein Architekturüberblick in Lebensgröße
