Stefan Zörner
17.11.2014
Teil 9 der Blog-Serie. Wir planen Themen, die viele betreffen. Viele im Team, viele Teams ... Skizzenhaft im Entwurf, verbindlich in der Wahl der Mittel.
Beim Zerlegen einer Softwarelösung in Subsysteme, Module o.ä. reduzieren Sie Komplexität – Modularisieren ist “Teilen und Herrschen”, der aktuelle Microservices-Trend seine neueste Facette. Gleichwohl gibt es Aspekte, die Sie nicht in jedem Teil individuell entscheiden und lösen wollen. Solche übergreifenden Themen dokumentieren Sie in sogenannten “Konzepten”. Um solche geht es in dieser Folge der Starschnitt-Serie. Und so heißt es wieder: Schere raus und losgeschnippelt …
Alle Jahre wieder werden in Los Angeles die Oscars für besondere Leistungen im Film vergeben. Die beste Regie, das beste Drehbuch, die beste Filmmusik … insgesamt über 30 Kategorien.
Auch für Softwarelösungen könnte man Preise vergeben. Das beste UI. Die beste Performance … Etwas eingegrenzt passiert das sogar. Bei Spielen zum Beispiel. Vielleicht erinnert sich der ein oder andere Leser noch an seine C=64-Vergangenheit und Spieletests in den einschlägigen Zeitschriften (Stichwort Happy Computer). Kategorien dort etwa Graphic, Sound, …
Computerspiele und auch einzelne Aspekte dazu lassen sich also bewerten – zumindest wird es gemacht (siehe z.B. IGN). Können wir auch Bewertungen für die beste Softwarearchitektur abgeben? Was ist überhaupt gute Softwarearchitektur?
Klassische Architekturbewertung wie zum Beispiel ATAM vergibt keine Preise. Nicht einmal Noten (siehe zum Beispiel dieser Artikel). Bei Architekturbewertung geht es darum, die zentralen Lösungsansätze (z.B. Technologieentscheidungen) für ein Softwaresystem gegen die Aufgabenstellung zu halten, um Risiken zu identifizieren und Kompromisse herauszuarbeiten.
In dieser Serie haben wir schon einige Schnipsel kennengelernt, die dazu dienen architekturrelevante Anforderungen festzuhalten und im Team und gegenüber den Stakeholdern zu kommunizieren.
Und auch schon einige, die der Lösung verpflichtet sind:
(Spoiler-Alarm: Mit dieser Folge kommt ein wichtiger Aspekt dazu)
Bei einer guten (besser vielleicht: adäquaten) Softwarelösung passen Struktur und Zerlegung, Technologieentscheidungen, … zu den Anforderungen. Sie hält die Randbedingungen (z.B. Zeitplan, Budget, geforderte Standards) ein, erreicht die Qualitätsziele, birgt wenige Risiken.
Unterm Strich also nicht einfach, Oscars für die beste Architektur, das beste Design, die beste Umsetzung, … zu vergeben. Oder die beste Wartbarkeit, Sicherheit, Benutzbarkeit … Zumal diese Dinge ja ggf. gar nicht gefragt waren. So gesehen hat auch der Kinobesucher in der Regel wenig von einem Film mit dem Oskar für das beste Make-up/die beste Frisur. Der preisgekrönte Film in dieser Kategorie war 1992 übrigens “Terminator 2 – Tag der Abrechnung” – blöd, wenn man auf coole Frisuren aber nicht auf Action steht.
Eine der wenigen Eigenschaften von Softwarearchitektur, die ich als allgemein preiswürdig erachte, ist konzeptionelle Integrität. Hinter diesen gleich zwei Fremdwörtern verbirgt sich die schlichte Tatsache, dass gleiche Probleme innerhalb des Systems stets gleich gelöst sind. Abweichungen hiervon führen zu schwer verständlichen und auch schwer zu erklärenden Lösungen. Bei der Einarbeitung neuer Kollegen fallen dann Sätze wie:
Dabei sind sehr wohl Ausnahmen zulässig, nur sollte es da gute Gründe für geben:
Diese Tatsache gehört kommuniziert, damit ein neuer Kollege der im Quelltext darüber stolpert, nicht falsche Schlüsse zieht („Komisch, mal nehmen sie JPA, mal direkt JDBC, kann ich mir also aussuchen. Vielleicht auch was ganz anderes nehmen …“).
Wenn Sie derartige Dinge nicht reparieren, schleppen Sie technische Schulden mit. Im Extremfall verwischt mit der Zeit die Softwarearchitektur, die konzeptionelle Integrität geht verloren (oder ohne Fremdwörter: Am Ende ist alles verkackt).
Im Rahmen Ihrer Entwicklung erarbeitete Lösungen für übergreifende Themen müssen Sie im Team teilen, damit die Ansätze und Prinzipien durchgängig eingehalten werden. Sie müssen sie insbesondere auch an neue im Team kommunizieren. Ein bewährtes Werkzeug, um die entsprechende Themen zu bearbeiten und die Lösungsansätze festzuhalten sind Konzepte.
Ein Konzept ist ein grober Plan, welcher die Maßnahmen zur Erreichung eines Ziels auflistet oder beschreibt, sowohl skizzenhaft im Entwurf, als auch verbindlich in der Auswahl der Mittel. – Wikipedia
Für welche Themen Sie Konzepte anfertigen hängt von Ihrem Projekt (und dessen Zielen) ab. Die folgende Tagcloud gibt eine erste Idee vom Themenspektrum.
Häufig zieht eine Technologieentscheidung ein Konzept nach sich. Sie wählen in einer Entscheidung eine Technologie unter verschiedenen Alternativen aus (z.B. eine Persistenztechnologie), und beschreiben anschließend in einem Konzept, wie sie diese Technologie einsetzen (z.B. in einem Persistenzkonzept).
Die folgende Liste nennt mögliche Themen für Konzepte in Gradle
Die Themen haben gemeinsam, dass sie zentrale Lösungsansätze beschreiben, und oder an vielen Stellen von Gradle wirken.
Zu vielen dieser Themen finden sich in der Gradle-Dokumentation entsprechende Informationen, etwa im Gradle User Guide. Für das Abhängigkeitsmanagement beispielsweise liegen gleich zwei Kapitel unterschiedlicher Flughöhe vor (8. Dependency Management Basics, 51. Dependency Management). Sie erklären die grundlegenden Konzepte und Lösungsansätze, aber keine Implementierungsdetails. Letztere sind für die Zielgruppe eines User Guides aber auch von untergeordnetem Interesse.
Die Gliederungen der beiden Kapitel im User Guide zu Dependency Management sehen beispielsweise so aus:
| 8. Dependency Management Basics 8.1. What is dependency management? 8.2. Declaring your dependencies 8.3. Dependency configurations 8.4. External dependencies 8.5. Repositories 8.6. Publishing artifacts 8.7. Where to next? |
51. Dependency Management_ 51.1. Introduction 51.2. Dependency Management Best Practices 51.3. Dependency configurations 51.4. How to declare your dependencies 51.5. Working with dependencies 51.6. Repositories 51.7. How dependency resolution works 51.8. Fine-tuning the dependency resolution process 51.9. The dependency cache 51.10. Strategies for transitive dependency Management |
Nicht jeder Entwickler beherrscht das Verfassen guter technischer Konzepte. Wobei „gut“ hier vor allem zielgruppengerecht heißt. Die primäre Zielgruppe technischer Konzepte sind oftmals andere Entwickler im Team, welche die Lösung nachvollziehen und umsetzen wollen/sollen. Aber es gibt auch andere potentielle Leser.
Eine Struktur, die sich zum Gliedern von Inhalten aller Art in Vorträgen, Artikeln etc. bewährt hat, und die insbesondere unterschiedliche Zielgruppen adressiert, ist das Vier-Quadrantenmodell (alternativ: 4-Mat-System). Die folgende Abbildung zeigt die Struktur angelehnt an ein Buch von Uwe Vigenschow et al (weitere Lesehinweise für Was-Menschen am Ende des Beitrags).
Die Struktur lässt sich auch auf technische Konzepte prima anwenden. Inhalte ordnen Sie den vier Quadranten zu und bringen Sie dann entsprechend in Reihenfolge. So sollte beispielsweise eine Motivation stets am Anfang stehen (und niemals fehlen). Leser aus einer zentralen Zielgruppe für die meisten Konzepte, nämlich Entwickler, schätzen Kürze und freuen sich insbesondere über Inhalte im „Wie“-Quadraten:
Beim „Was“ ergänzen in übergreifenden Konzepten oft gute Quellen zum Nachlesen die eigenen Inhalte. Gerade beim Einsatz gängiger Technologien passen Verweise auf gute Literatur. Tutorials im Internet oder auch Videos und Podcasts zum Thema sind eine weitere schöne Ergänzung. Damit lässt sich das Konzept selbst kürzer halten, ganz im Interesse der Entwickler.
Das Thema Abhängigkeitsmanagement aus dem Gradle-Beispiel wurde mit zwei Konzepten (Kapiteln) dokumentiert. Wenn wir diese zusammenführen wollten und dabei die Gliederungsstruktur des Vier-Quadrantenmodells einhalten finden sich schnell Unterkapitel in der bestehenden Dokumentation, die zu den Quadranten mit ihren jeweiligen W-Fragen passen. Hier einige Beispiele (Kapitelnummer aus dem User Guide in Klammern):
| Warum? | Introduction (51.1) What is dependency management? (8.1) |
| Was? | Dependency configurations (8.3) How dependency resolution works (51.7) |
| Wie? | How to declare your dependencies (51.4) Dependency Management Best Practices (51.2) |
| Wohin noch? | Strategies for transitive dependency Management (51.10) Where to next? (8.7) |
Technische Konzepte entstehen oftmals im Kontext eines Projektes als Antwort auf die Frage: “Wie gehen wir mit XY um?” (XY z.B.: Persistenz, Security, …). In vielen Fällen lassen sie sich aber auch außerhalb des Projektes weiter verwenden, bewährte Konzepte sind für ähnlich gelagerte Problemstellungen interessant.
Softwarelösungen innerhalb einer Unternehmens etwa haben häufig ähnliche Randbedingen. Es besteht daher berechtigte Hoffnung, dass ein Lösungsansatz eines Projektes grundsätzlich auch auf andere Systeme im Unternehmen passt. Um das aber bewerten zu können muss Ihr Konzept nachvollziehbar sein (Stichwort “Hintergründe erläutern” im “Was?"-Quadrant).
Fertigen Sie ein Konzept also als eigenständigen Schnipsel an, und nicht nur als Unterkapitel innerhalb eines umfangreichen Architekturbeschreibungsdokumentes (eh kein guter Plan).
arc42 hält für übergreifende Konzepte einen eigenen Abschnitt bereit:
Das betreffende Kapitel im arc42-Template enthält eine umfangreiche Themensammlung. Lassen Sie sich von den insgesamt 23 Unterkapiteln (Persistenz, Benutzeroberfläche, …) nicht abschrecken. Sie müssen diese nicht sklavisch abarbeiten; die Themensammlung dient zu Ihrer Inspiration und erhebt nicht einmal einen Anspruch auf Vollständigkeit. Ganz ähnlich wie die Tagcloud oben in diesem Beitrag. Wählen Sie gezielt aus!
Übergreifende Konzepte sind ein Mittel zum Zweck. Der Zweck: Für Themenfelder, wo es für Sie und Ihr Team (oder sogar Ihre Teams) wichtig ist, einheitliche Lösungen zu diskutieren und zu etablieren.
Und der Preis für konzeptionelle Integrität geht dieses Jahr an … Ihr Team für Ihr Softwaresystem?
Den neunten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben, können Sie hier herunterladen. ;-)
In der nächsten Folge geht es übrigens um die Lösungsstrategie, also Abschnitt 4 in arc42. In der dann gezeigten Form setzt sie Architekturziele und Lösungsansätze in Beziehung. Ich persönlich halte es für eines der nützlichsten Werkzeuge, um die Architekturidee zu kommunizieren…
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.