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…

TeaserBild_Folge_9

And the Oscar goes to …

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,  …

Abbildung: Rating für ein Computerspiel (Kategorien angelehnt an IGN)

Abbildung: Rating für ein imaginäres Computerspiel (Kategorien angelehnt an IGN)

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?

Preisgekrönte 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.

Der Oscar für die am wenigsten verkorkste Software?KleinesPuzzleTeil_9

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:

  • „Das ist so ähnlich wie im XY-Subsystem, das wir uns eben angeguckt haben, nur dass hier …“
  • „Ach ja, früher hatten wir das noch so gemacht, da gibt es noch einige Stellen von im Code …“
  • „Die Komponente hat Peter gemacht, der mochte es lieber …“

Dabei sind sehr wohl Ausnahmen zulässig, nur sollte es da gute Gründe für geben:

  • „Normalerweise greifen wir mit JPA auf die Datenbank zu. In wenigen Fällen nutzen wir aus Performancegründen natives SQL …“

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.

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.

UebergreifendeThemen

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).

– – – 8< – – –

Schnipsel #9: Übergreifende Konzepte von Gradle

Die folgende Liste nennt mögliche Themen für Konzepte in Gradle

  • Aufbau eines Build-Skriptes
  • Build-Lebenszyklus
  • Abhängigkeitsmanagement
  • Gradle Wrapper
  • Gradle Daemon
  • IDE Integration
  • Logging
  • Umgang mit Repositories
  • Plugin-Konzept („Wie wird Gradle um Funktionalität erweitert?“)
  • Migration von Magen oder Ant auf 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

– – – >8 – – –

Schreibblockade. Wie genau schreibt man ein Konzept?

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 anderer 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).

Das Vier-Quadrantenmodell (Darstellung nach Vigenschow et al)

Abbildung: Das Vier-Quadrantenmodell (Darstellung nach Vigenschow et al)

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:

  • Schritt-für-Schritt-Anleitungen
  • Tipps und Tricks aus der Praxis
  • Beispiele zum Abgucken

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).

Wo kleben wir den Schnipsel hin?

arc42 hält für übergreifende Konzepte einen eigenen Abschnitt bereit:Abheften_Folge_9

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!

Und was ist mit dem Preis?

Ü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?

Zum Weiterlesen

Ausblick

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…

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.