Stefan Zörner
17.12.2014
Teil 10 der Blog-Serie. Wir verdichten die Kernideen der Softwarearchitektur auf einem Bierdeckel.
In dieser Blogserie habe ich bereits einige Schnipsel zum Festhalten architekturrelevanter Anforderungen auf der einen und Lösungsansätzen auf der anderen Seite diskutiert. In dieser Folge lernen Sie nun ein wirkungsvolles Werkzeug kennen, das die Brücke schlägt.
Und so heißt es wieder: Schere raus und losgeschnippelt …
Die unliebsame jährliche Einkommenssteuererklärung manifestiert sich in einem grau-grünen Papierungetüm, das Ausfüllen von Mantelbogen ESt 1 A, V oder C sowie diverser Anlagen wie N, KSO oder AVEÜR (= Anlageverzeichnis/Ausweis des Umlaufvermögens zur Anlage EÜR) lässt in Deutschland so manchen verzweifeln.
Der CDU-Politiker Friedrich Merz machte 2003 mit einem radikalen Konzept zur Steuerreform auf sich aufmerksam: Die Steuererklärung sollte demnach auf einen Bierdeckel passen! Ein verlockendes Bild, leider nicht von Erfolg gekrönt.
Können wir eine Softwarearchitektur auf einem Bierdeckel erklären? Als Idealbild ist für viele bereits ein Architekturüberblick ihres Softwaresystems auf weniger als 30 Seiten anstrebsam, und in der Regel auch inklusive Abbildungen, Inhaltsverzeichnis, Glossar usw. gut machbar.
Die Lösungsstrategie für ein Softwaresystem lässt sich jedoch noch weiter verdichten, sodass sie auf eine DIN A4-Seite passt. Oder auf ein bis zwei PowerPoint-Folien.
Eine Strategie (von griechisch strategós „Feldherr, Kommandant“) ist ein Plan zum systematischen Erreichen von Zielen … – Wikipedia
Eine besonders kompakte und wirkungsvolle Form zur Dokumentation und Kommunikation der Lösungsstrategie stellt die wichtigsten Anforderungen den Lösungsansätzen in einer Tabelle gegenüber, siehe folgende Abbildung:
Die linke Spalte enthält dabei die Qualitätsziele (oder auch Architekturziele, vgl. Schnipsel #3 dieser Serie). Für ein ausdrucksstarkes Ergebnis zahlt es sich hier aus, wenn Sie den Zielen prägnante Namen gegeben haben (z.B. „Intuitive Erlernbarkeit“ statt nur „Benutzbarkeit“). In der rechten Spalte ordnen Sie den Zielen die wichtigsten Lösungsansätze Ihrer Architektur zu, die aus Ihrer Sicht der Erreichung der Ziele dienen. Als erstes sind hier die Architekturentscheidungen zu nennen.
Die folgende Tabelle listet mögliche Kategorien für Lösungsansätze für die rechte Spalte der Strategie auf und illustriert sie jeweils mit einem Beispiel. Die einzelnen Ansätze nennen Sie in Ihrer Tabelle nur schlagwortartig, beispielsweise „JPA/Hibernate als Persistenzframework“. Auf detaillierte Informationen (z.B. die ausführliche Darstellung einer Architekturentscheidung inklusive betrachteter Alternativen, das ausgearbeitete Konzept etc.) verweisen Sie lediglich.
| Kategorie | Beispiel (und dazu passendes Qualitätsziel) |
| Entscheidungen | Verwendung eines Application Server Clusters (hohe Ausfallsicherheit) |
| (Architektur-)stile | Micro Services (schnelle Adaption neuer technologischer Trends) |
| (Architektur-)muster | Schichtenarchitektur (leichte Austauschbarkeit des Clients, oder einfache Portierung der Lösung) |
| (Architektur-)prinzipien | Bevorzuge Standards vor proprietären Lösungen (niedrige Wartungsaufwände) | Konzepte | Caching-Konzept (Effizienz, gute Antwortzeiten) |
| Vorgehen | User centered design (intuitive Benutzbarkeit) |
Ansätze, wie in der Tabelle oben, wählen Sie und Ihr Team typischerweise selbst aus – Sie entscheiden. In Einzelfällen können Sie aber auch Randbedingungen als „Argumente“ für Ihre Architektur anführen. Wenn beispielsweise Technologien vorgegeben sind, die gleichzeitig gut zu den Zielen passen, können Sie diese in der rechten Seite ebenfalls nennen. Ein einzelner Lösungsansatz kann mitunter mehreren Zielen dienlich sein. Sie listen ihn dann einfach mehrmals in der rechten Spalte auf.
Um Interessierten einen Einstieg in Ihre bereits entstandene Dokumentation zu geben, können Sie die Lösungsstrategie als eine Art Zusammenschau nachdokumentieren. Besser noch beginnen Sie aber früh mit einer ersten Fassung, um Sicherheit im Architekturentwurf zu gewinnen und der Verwässerung wichtiger Architekturansätze entgegenzuwirken.
Zeit für ein richtiges Beispiel! Unser Serienstar Gradle ist endlich wieder an der Reihe …
Die folgende Tabelle stellt den Qualitätszielen von Gradle aus Schnipsel #3 (links) passende Lösungsansätze (rechts) gegenüber. Genannt werden dabei zentrale Entscheidungen (z.B. Groovy für Build-Skripte, siehe Beispiel in Schnipsel #5), Konzepte (z.B. das Plugin-Konzept), Prinzipien (z.B. “build-by-convention”) und Ideen (z.B. Groovy Wrapper, Groovy Daemon).
| Qualitätsziel | passende Lösungsansätze in Gradle |
| Erweiterbarkeit | -------- |
| (Gradle lässt sich leicht um neue Funktionalität erweitern. Es kann auf lange Sicht dem technologischen Fortschritt bei Tools und Entwicklungsmethodik folgen) |
|
| Effizienz | -------- |
| (Teams und einzelne Entwickler erhalten durch kurze Buildzeiten schnelle Rückmeldungen; Gradle steigert so ihre Produktivität) |
|
| Interoperabilität | -------- |
| (Gradle arbeitet mit bestehenden Werkzeugen wie Ant und Maven und deren Öko-Systemen nahtlos zusammen) |
|
| Erlernbarkeit | -------- |
| (Entwickler und Buildmanager finden sich schnell in Gradle zurecht, der Einstieg und das Erstellen erster Build-Skripte fallen ihnen leicht) |
|
| Installierbarkeit | -------- |
| (Der Aufwand, der zum Installieren von Gradle notwendig ist, um einen Build auszuführen ist, sehr gering) |
|
| Skalierbarkeit | -------- |
| (Gradle bleibt auch bei sehr umfangreichen Builds und in Multi-Projekt-Szenarien handhabbar und effizient) |
|
Die Lösungsstrategie oben ist etwas umfangreicher. Auf ein DIN A4-Blatt passt sie noch, Bierdeckel wird knapp. Das hat mehrere Gründe. Zum einen enthielt das Gradle-Beispiel in Schnipsel #3 sechs Qualitätsziele, und ich wollte hier keines unterschlagen. In einem Architekturüberblick beschränken Sie sich zum Beispiel auf die Top-3. Zum andern habe ich in der Tabelle oben die Ziele vollständig (d.h. jeweils mit Erklärung in Klammern) wiedergegeben. So sind sie auch ohne “Hin- und herblättern” im Blog gut verständlich.
arc42 hält für die Lösungsstrategie einen eigenen Abschnitt bereit: den vierten …
In den arc42-Abschnitten davor (1-3) sind architekturrelevante Anforderungen (z.B. Randbedingungen und Qualitätsziele) versammelt, danach Lösungsdetails wie Bausteinsicht, Konzepte, Entscheidungen. Die Lösungsstrategie schlägt in dieser Anordnung die Brücke, sie führt in die Lösung ein.
Das gezeigte Werkzeug der Lösungsstrategie ist nicht nur exzellent geeignet, um die grundlegenden Aspekte Ihrer Architektur zu zeigen und dabei gleichzeitig zu motivieren. Es hilft auch während des Entwurfs der Architektur dabei, Lücken und Ungereimtheiten aufzudecken.
Wenn Sie zu einem Architekturziel keine passenden Lösungsansätze in der Architektur identifizieren, ist da noch etwas zu tun. Und wenn Sie umgekehrt einen zentralen Aspekt der Architektur keinem Ziel zuordnen können, sollten Sie ihn hinterfragen. Im Grunde stellt die Tabelle eine besonders schlanke Form der Architekturbewertung dar. Passt die Lösung zur Zielsetzung?
Den zehnten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben, können Sie hier herunterladen. ;-)
Mit der nächsten Folge – Schnipsel #11 von 11 – endet dann der arc42-Starschnitt in diesem Blog. Mit der Laufzeitsicht lernen Sie zum Abschluss eine Möglichkeit kennen, der statischen Bausteinsicht ein wenig Leben einzuhauchen …
Dieser Beitrag ist ursprünglich als Teil einer Blog-Serie beim Hanser-Verlag (“Hanser Update”) erschienen. Die Inhalte, ergänzt um reichhaltiges Bonus-Material, sind mittlerweile auch als E-Book bei Leanpub verfügbar.