In dieser Blogserie habe ich bereits einige Schnipsel zum Festhalten architekturrelevanter Anforderungen auf der einen und Lösungsansätze auf der anderen Seite diskutiert. In dieser Folge lernen Sie nun ein wirkungsvolles Werkzeug kennen, das die Brücke schlägt.

TeaserBild_Folge_10

Und so heißt es wieder: Schere raus und losgeschnippelt…

Ihre Architektur auf einem Bierdeckel?

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.

Steuererklärung

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)

Ihre Lösungsstrategie stark verdichtet

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:
Loesungsstrategie
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.Schnipsel #10 zum Ausschneiden und Zusammenkleben

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 …

– – – 8< – – –

Schnipsel #10: Lösungsstrategie Gradle

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)
  • Build-Files sind Groovy-Skripte, kleine Erweiterungen auch ohne aufwändige Programmierung möglich
  • Ausgereiftes Plugin-Konzept, Custom Plugins können in Groovy, Java, Scala … entwickelt werden
  • Exzellent dokumentierte Gradle API und erweiterbare DSL
Effizienz ——–
(Teams und einzelne Entwickler erhalten durch kurze Buildzeiten schnelle Rückmeldungen; Gradle steigert so ihre Produktivität)
  • Unterstützung inkrementeller Builds
  • Dependency-Cache zur Reduktion der Download-Zeiten
  • Betrieb im Hintergrund für kürzere Start- und Ausführungszeiten möglich (Gradle Daemon)
Interoperabilität ——–
(Gradle arbeitet mit bestehenden Werkzeugen wie Ant und Maven und deren Öko-Systemen nahtlos zusammen)
  • Direkte Verwendung von Ant-Tasks und Ant-Projekten in Gradle möglich
  • Konverter für Maven pom.xml nach Gradle Build-Skript verfügbar
  • Unterstützung von Maven-Repositories (Download von Abhängigkeiten, Veröffentlichen von Artefakten)
  • Gradle API erlaubt Einbetten von Gradle, zum Beispiel in IDEs
Erlernbarkeit ——–
(Entwickler und Buildmanager finden sich schnell in Gradle zurecht, der Einstieg und das Erstellen erster Build-Skripte fallen ihnen leicht)
  • Verwendung der Sprache Groovy für Build-Skripte (siehe: „Why Groovy?“)
  • Deklarative Builds mit Groovy DSL und „build-by-convention“
  • Zielgruppengerechte Dokumentation (Tutorials, User-Guide)
Installierbarkeit ——–
(Der Aufwand, der zum Installieren von Gradle notwendig ist, um einen Build auszuführen ist, sehr gering)
  • Java ist die einzige Systemvoraussetzung
  • Wrapper lädt Gradle automatisch herunter — Builds sind so ohne weitere Installation möglich
Skalierbarkeit ——–
(Gradle bleibt auch bei sehr umfangreichen Builds und in Multi-Projekt-Szenarien handhabbar und effizient)
  • Umfassende Unterstützung für Multi-Project Builds
  • darüber hinaus: Ansätze für Effizienz (siehe oben)
——–

– – – >8 – – –

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.

Wo kleben wir den Schnipsel hin?
arc42 hält für die Lösungsstrategie einen eigenen Abschnitt bereit: den vierten …
Schnipsel #10 abheften in arc42
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.

Eine Architekturbewertung auf dem Bierdeckel
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?

Ausblick

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 …

Ich hoffe, Sie finden weiterhin Gefallen an dieser kleinen Serie und freue mich auf Ihre Fragen und Rückmeldungen. Kommentieren Sie einfach hier im Blog oder schreiben Sie mir (E-Mail: stefan.zoerner[ät]embarc.de). Wünsche greife ich gerne in den nächsten Folgen auf, Fragen beantworte ich direkt hier.

Sie haben einen Schnipsel des arc42-Starschnitts zu Gradle verpasst? Hier finden Sie alle bisherigen Folgen.