All Posts By

Stefan Zörner

Vortrag OOP 2017: Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren

By | Publikationen, Vorträge | No Comments
„Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren“
Logo OOP 2017
Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren
Sprecher: Stefan Zörner
Vortrag auf der OOP 2017
31. Januar 2017 um 16:15 – 17:15 Uhr
ICM – Internationales Congress Center München, Am Messesee, 81829 München

Download Vortragsfolien (PDF)

Software-Systeme wachsen historisch. Das gilt nicht als Idealzustand, aber so ist die Realität nun mal. Für System-Landschaften gilt es erst recht. IT-Trendwellen schwappen über Unternehmen und hinterlassen ihre Spuren in den Anwendungen. Geglückte Würfe ebenso wie gescheiterte Initiativen.

(De-)Zentralisierung, Objektorientierung, SOA, Standardisierung, Cloud … Manche Unternehmen haben Vermächtnisse (engl. Legacy) aus drei Jahrzehnten im Betrieb. In vielen Fällen wird das Wissen darum nur mündlich weitergegeben. Die Konsequenz: langwierige und lückenhafte Einarbeitung, Unsicherheiten bei Änderungen und Neuentwicklungen. Im Extremfall führt dies zu geringem Vertrauen bei Entscheidern. Dabei ist der Aufwand, das Wesentliche fest und aktuell zu halten, gar nicht groß.

In dieser Session zeige ich, wie man bestehende Systemlandschaften kartographiert und es allen Beteiligten leichter macht, sich zurechtzufinden und informierte Entscheidungen zu treffen. Mit Anlehnung an Methoden wie arc42 (das initial nur auf Einzelsysteme passt), Beispielen aus echten Ausgrabungen, aber ohne C14.

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

Drei Dinge, die mich bei Architekturdiagrammen mit plantUML nerv(t)en

By | Allgemein, Inhaltliches | 8 Comments

plantIch sehe bei Kunden ab und an plantUML im Einsatz. Und noch häufiger fragen mich Teilnehmer in Workshops, was ich von plantUML halte, wenn es um Diagramme in der Dokumentation von Softwarearchitektur geht. Beispielsweise in den betreffenden Abschnitten von arc42 (Konkret: Kontextabgrenzung, Bausteinsicht, Laufzeitsicht …).

Um ehrlich zu sein fand ich plantUML dafür lange Zeit nicht so toll. Aus verschiedenen Gründen. Bei näherem Hinsehen ließ sich einiges davon aber auf Unkenntnis und Vorurteile meinerseits zurückführen. Und einige Unschönheiten lassen sich mit den richtigen Kniffs und Workarounds umgehen. Ein paar kleine Erkenntnisse zeige ich im Rahmen dieses Beitrags. Und beginne so meinen Frieden zu machen mit dem Werkzeug.

Aber zuvor: Was ist dieses plantUML überhaupt (für diejenigen, die es nicht kennen) und warum finde ich es (immernoch) nicht ganz so toll wie manche meiner Kunden?

plantUML

plantUML generiert UML-Diagramme als Graphik aus textuellen Beschreibungen. Die Syntax dazu ist recht einfach gehalten und schnell erlernt. Hier ein Minibeispiel. Aus der Eingabe links generiert plantUML das Diagramm rechts.cd_schach

@startuml

Schachbrett -> Figur 
Figur --> Farbe
Figur --> enum Art

enum Farbe { 
 SCHWARZ 
 WEISS
}

@enduml

 

Neben den besonders gut unterstützen Klassendiagrammen (wie im Beispiel oben, Details zur Syntax siehe hier) kann plantUML auch andere Diagrammarten der UML generieren (Sequenzdiagramme, Anwendungsfalldiagramme …).

plantUML ist Open Source, in Java geschrieben und leicht integrierbar. Entsprechend gibt es zum Beispiel Plugins für verschiedene Textsysteme (z.B. Asciidoctor), Build-Werkzeuge (z.B. Gradle) und Wikis (z.B. XWiki und Confluence). Gerade in diesen Fällen passt das Text-Format von plantUML sehr gut, fühlt es sich doch in der Versionsverwaltung ebenso wohl wie zwischen Wiki-Markup.

In der Regel nimmt der Autor beim Erstellen kaum Einfluss auf das Layout seiner Diagramme. Ich sehe das als Vorteil, kostet das Kästchenschubsen in graphischen Editoren bei Änderungen doch oftmals viel Zeit.

Drei Dinge, die ich an plantUML nicht mag

Trotz der unbestrittenen positiven Merkmale gibt es Dinge, die mir bei plantUML nicht so gut gefallen. Hier drei aus meiner Sicht besonders gewichtige:

  1. Der Technologie-Stack ist fragil
  2. Für Softwarearchitektur relevante Diagramme fehlen
  3. Die generierten Diagramme sehen altbacken aus

Der Technologie-Stack ist fragil

plantUML ist in Java geschrieben, der Download lediglich ein jar-File. Tatsächlich handelt es sich bei bei dem Tool aber eher um ein Frontend (oder wenn man mag einen Präprozessor) für das Werkzeug Graphviz.

binaryGraphviz ist eine leistungsfähige und recht verbreitete Open Source-Lösung zum Visualisieren von Graphen (also Knoten verbunden durch Kanten). Anders als plantUML wird es Betriebssystem-spezifisch als Binary installiert. Es muss lokal vorliegen (konkret: das Graphviz-Executable „dot“). plantUML greift darauf zu, es verwandelt die plantUML-Eingabe in eine Eingabe in der DOT-Sprache und lässt dann Graphviz die ganze Arbeit machen („Zwerge auf den Schultern von Riesen“).

Das Problem dabei: das Zusammenspiel zwischen plantUML und dot führt regelmäßig zu Reibung. Auch eine saubere Graphviz-Installation verweigert schon mal die Arbeit und führt zu Fehlermeldungen, lustigerweise in Form einer Graphik anstelle des erhofften Ergebnisses. Sieht dann zum Beispiel so aus:

Fehler beim Aufruf von not / Graphviz

In der Praxis heißt das etwa für ein Java-Projekt, das seine Architekturdokumentation in den Build integrieren will, dass es höhere Anforderungen an das Build-System stellt. Also an alle, die das Projekt bauen wollen. Java installieren reicht nicht (wie bei Gradle durch den Wrapper eigentlich üblich), es muss auch noch Graphviz da sein und mit plantUML zusammenspielen.  Das berühmte „It Works on My Machine“ war doch eigentlich überwunden (OK, die Pest ist schlussendlich auch noch nicht ausgestorben). Auch entsprechende Beiträge der Plugin-Benutzer in den Foren von XWiki und Confluence singen ein Lied von dem Problem.

Für Softwarearchitektur relevante Diagramme fehlen

plantUML unterstützt verschiedene Diagrammarten der UML, und die wiederum verschiedenen gut. Bei Klassendiagrammen geht mit Abstand am meisten. Gerade diese Diegrammart benötige ich allerdings in einem Architekturüberblick eher selten, bestenfalls für ein grobes Domänenmodell.

struktur_kleinBesonders wichtig sind mir methodisch gesehen die Kontextabgrenzung (Kapitel 3 in arc42, bzw. der Abschnitt „Context“ bei Simon Brown) und die statische Zerlegung (Kapitel 5 „Bausteinsicht“ in arc42). Eine Kontextabgrenzung lässt sich mit plantUML ganz gut visualisieren übrigens. Meine favorisierte Darstellung von Zerlegungshierarchien mit den Ports der Kompositionsstrukturdiagramme unterstützt plantUML leider nicht. Strukturen lassen sich zwar mit gruppierenden Elementen abbilden; Interaktionspunkte auf der „Membran“ (Ports, siehe kleine Skizze links) gehen hingehen nicht.

Die Diagramme sehen altbacken aus

Geschmäcker sind verschiedenen, mir persönlich gefällt die Darstellung von plantUML tatsächlich nicht sonderlich. Die Buchstaben-Icons bei Klassen, Aufzählungen etc. (E, C, … siehe Schach-Beispiel oben)  sind nicht mein Fall, und vor allem:  Die Farben (gelbe Kästen, rote Linien) haben die Anmutung alter Rational-Werkzeuge (kleine Zeitreise, Video). Die Zeit wünsche ich mir nicht zurück. Den Retro-Look der 90er-Jahre komplett machen dann Komponenten im Stil der UML 1. Als Beispiel hier ein rudimentärer Systemkontext (System mit einem Benutzer als Akteur) in plantUML, rechts wieder das resultierende Diagramm (das System als Komponente in UML 1-Notation):

@startumlsc_altbacken
[Webshop] <<system>>
:Kunde: - Webshop
@enduml

Auf Diagramme mit dieser Anmutung stolpere ich regelmäßig in Projekten. Dass mir die nicht übermäßig gefallen ist mein Problem, wenn die Teams es so mögen … Mein Problem könnt Ihr gleichzeitig beheben, bei plantUML läßt sich nämlich so ziemlich jede Stileigenschaft (Fonts, Farben, Strichbreiten …) konfigurieren. Aber wer hat da schon Lust zu? Der Aufwand mit all den Schaltern schreckt erstmal ab.

Die gute Nachricht: Es gibt recht große Schalter — Hebel sozusagen — welche mit wenig Aufwand viel Wirkung zeigen. Für das Beispiel oben reichen zwei dieser wirkmächtigen Hebel, und es sieht für mich deutlich passabler aus (siehe wieder Graphik rechts):

@startumlsc_modern
skinparam monochrome true
skinparam componentStyle uml2

[Webshop] <<system>>
:Kunde: - Webshop
@enduml

Das gefällt mir richtig gut schon. Derartige Skin-Parameter lassen sich übrigens auch in Dateien auslagern, von aussen in den plantUML-Prozessor reinreichen, etc. — So verschmutzen sie auch nicht alle plantUML-Quelltexte.

Fazit

Der Ansatz, aus text-basierten Beschreibungen Graphiken/Diagramme zu generieren, hat viel für sich. In vielen Fällen nutzen Teams ein Wiki oder Text-Systeme wie Asciidoc, um ihre Architekturdokumentation festzuhalten. Die Frage, wo die Diagramme herkommen, stellt sich dort stets, und plantUML ist zumindest eine Option. Mit wenigen Kniffen finde ich die Ausgabe zumindest optisch passabel, eine große Herausforderung bleibt das fragile Zusammenspiel mit Graphviz.

Ich spiele mit dem Gedanken hier ein geschlossenes Fallbeispiel bereitzustellen. Einen Architekturüberblick, in dem die Diagramme mit plantUML generiert sind, und dessen Inhalte sich an den Sichten von arc42 orientieren. Fänden Sie das interessant?

Vortrag W-JAX 2016: Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren

By | Publikationen, Vorträge | No Comments
„Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren“
Logo W-Jax
Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren
Sprecher: Stefan Zörner
Vortrag auf der W-JAX 2016
10. November 2016 um 10:45 – 11:45 Uhr (Raum: Garmisch)
The Westin Grand München, Arabellastrasse 6

Download Vortragsfolien (PDF)

Softwaresysteme wachsen historisch. Das gilt nicht als Idealzustand, aber so ist die Realität nun mal. Für Systemlandschaften gilt es erst recht. IT-Trendwellen schwappen über Unternehmen und hinterlassen ihre Spuren in den Anwendungen. Geglückte Würfe ebenso wie gescheiterte Initiativen.

(De-)Zentralisierung, Objektorientierung, SOA, Standardisierung, Cloud …manche Unternehmen haben Vermächtnisse (engl. Legacy) aus drei Jahrzehnten im Betrieb. In vielen Fällen wird das Wissen darum nur mündlich weitergegeben. Die Konsequenz: langwierige und lückenhafte Einarbeitung, Unsicherheiten bei Änderungen und Neuentwicklungen. Im Extremfall führt dies zu geringem Vertrauen bei Entscheidern. Dabei ist der Aufwand, das Wesentliche fest und aktuell zu halten, gar nicht groß.

In dieser Session zeige ich, wie ihr bestehende Systemlandschaften kartografiert und es allen Beteiligten leichter macht, sich zurechtzufinden und informierte Entscheidungen zu treffen. Mit Anlehnung an Methoden wie arc42 (das initial nur auf Einzelsysteme passt), Beispielen aus echten Ausgrabungen, aber ohne C14.

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

Vortrag Java Forum Nord 2016: Nörgeln ist einfach (Architekturbewertung)

By | Publikationen, Vorträge | No Comments
„Nörgeln ist einfach. Aber was (genau) ist eigentlich Architekturbewertung?“
Logo Java Forum Nord
Nörgeln ist einfach. Aber was (genau) ist eigentlich Architekturbewertung?
Sprecher: Stefan Zörner
Vortrag auf dem Java Forum Nord
Donnerstag, 20. Oktober 2016, 16:00 Uhr
Hannover, Hotel Dormero

Folien Download (PDF)

Statler: „Nein, nein, das hätten sie wirklich anders machen sollen.“
Waldorf: „So, wie denn nach Deiner Meinung?“
Statler: „Besser!“
(aus der Muppet Show)

Jedes interessante Softwaresystem hat eine Softwarearchitektur. Diese ist kunstvoll geplant oder zufällig entstanden, meist aber irgendwas dazwischen. Hätte man es anders machen sollen? In diesem Vortrag stelle ich vor, wie Sie Ihre Softwarearchitektur bewerten! Sind Sie auf dem richtigen Weg? Können Ihre Architekturideen in der Umsetzung aufgetretene Probleme effektiv lösen? Helfen diese bei der Erreichung Ihrer Ziele oder behindern sie diese eher? Architekturbewertung kann Sicherheit schaffen und Risiken aufzeigen und damit helfen die Aufwände im Projekt zu fokussieren. Sie lernen quantitative und qualitative Analysemethoden kennen. Was argumentative, Workshop-basierte Verfahren wie ATAM leisten thematisiere ich ebenso wie welche Aspekte Ihrer Architekturziele sich mit statischen Code-Analysen verknüpfen lassen.

Download Vortragsfolien (PDF)

 

Zur Veranstaltung

Die sieben Regeln für gute Dokumentation in Stein gemeißelt? — Tafel 3 (von 3)

By | Allgemein, Inhaltliches | No Comments

In den zwei vorherigen Beiträgen hatte ich bereits mit der kurzen Diskussion der klassischen sieben Regeln für gute Dokumentation begonnen. Ich schließe sie in diesem Beitrag mit den beiden verbleibenden Regeln 3 und 7 ab. Hier noch einmal kurz zur Erinnerung alle sieben im Überblick:

Sieben Regeln für gute Dokumentation
book
1. Schreibe aus Sicht des Lesers. (Tafel 1)
2. Vermeide unnötige Wiederholungen. (Tafel 2)
3. Vermeide Mehrdeutigkeit. Erkläre Deine Notation. (Tafel 3)
4. Verwende eine Standardstrukturierung. (Tafel 2)
5. Halte Begründungen für Entscheidungen fest. (Tafel 1)
6. Halte Dokumentation aktuell, aber auch nicht zu aktuell. (Tafel 2)
7. Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit. (Tafel 3)

Vermeide Mehrdeutigkeit. Erkläre Deine Notation (Regel 3)

Es ist unstrittig, dass sich bestimmte Informationen mit Bildern besser kommunizieren lassen als mit Text allein. Das gilt für Strukturen (Elemente und deren Beziehungen untereinander) ebenso wie für Abläufe (Folgen von Aktionen mit Alternativen, Wiederholungen, Parallelität). Ab einer gewissen Komplexität lässt sich das mit Stichpunkten oder Prosa nicht gut beschreiben. Diagramme und mitunter auch Screenshots kommen ins Spiel, bei Diagrammen ist in der Softwarearchitektur immer noch UML recht verbreitet.

In diesem Zusammenhang höre ich in Projekten oft: „Wir benutzen für unsere Architekturdiagramme UML. Die Notation ist standardisiert. Kann jeder lesen.“ Das mit dem standardisiert stimmt, meine Erfahrungen mit „kann jeder lesen“ sind andere.

In der Projektpraxis werden übrigens oft gar keine Architekturdiagramme angefertigt. Auch weil die Teammitglieder unsicher in der Notation sind. Sie glauben sie müssten UML nehmen aber haben Angst sich damit zu blamieren. Aus meiner Sicht ist UML zu verwenden kein Automatismus, und bei den vielen Zielgruppen (vgl. Regel 1) wird auch bei der UML Erklärungsbedarf da sein.

In diesem Zusammenhang zwei persönliche Ratschläge von mir rund um Diagramme:

  • Schreibt zu jedem Diagramm einen Satz der auf den Punkt bringt was zu sehen ist (“Mission Statement”, Kernaussage). In der Dokumentation (egal ob Dokument, Wiki, Poster …) platziert Ihr diesen Satz oberhalb der Abbildung.
  • Lasst Euch nicht von der Notation behindern. Benutzt stattdessen wenige Elemente, und erklärt diese in einer Legende.

Der erste Tipp sorgt zum einen dazu, dass Betrachter nicht rätseln müssen, was Ihr mit dem Bild sagen wollt. Zum anderen (und das ist das Entscheidende) hilft es Euch zu entscheiden, ob etwas „noch ins Bild reingehört“ oder nicht. Ihr vermeidet Diagramme voller Prachtfülle, in denen der Leser die relevanten Informationen dann aber suchen muss wie in einem Wimmelbild. Hier ein schönes Fundstück aus dem Netz dazu (Quelle, beachtet die beschönigende Überschrift).

complex-system-architecture-diagram-2292510

Immerhin: Eine Legende hat dieses Diagramm. Die Regel „Erkläre Deine Notation“ wende ich durchaus auch auf UML an. Und wenn Ihr dort wenige Elemente verwendet braucht Ihr auch nur wenig erklären. Die wenigen UML-Elemente dann aber bitte richtig verwenden. Sonst verwirrt Ihr diejenigen, die UML lesen können (gibt es auch).

Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit (Regel 7)

Hinter dieser Regel stecken Reviews, zumindest suggeriert das Wort „überprüfen“ das. Dokumentation kann man auf zwei Arten überprüfen. Die erste nenne ich gern „Überprüfung auf Standardkonformität“. Hier werden Kriterien an die Dokumentation gelegt und Fragen folgender Art gestellt (Beispiele):

  • Hat die Architekturbeschreibung mindestens 60 Seiten?
  • Ist sie nach arc42 gegliedert?
  • Ist jeder Abschnitt ausgefüllt?
  • Wird für die Diagramme als Notation UML verwendet?
  • Hat jedes Diagramm eine Legende?

Fragen dieser Art eignen sich prima für Checklisten, diese können in der Regel von einer QS-Abteilung abgearbeitet werden. Mitunter erfordern regulative Randbedingungen einen solchen Check auf Standardkonformität. Mit der Überprüfung auf Gebrauchstauglichkeit ist aber etwas anderes gemeint.

Nämlich dass die Dokumentation tatsächlich bei der Arbeit unterstützt. Diejenigen, welche Architektur kommunizieren wollen, und diejenigen, welche sich dafür interessieren. Also für Architekturtreiber, Lösungsansätze, Entscheidungen, Konzepte. Die geschlossenen Fragen von oben können das nicht leisten.
Architektur-Spicker #1, Seite 3
Die Überprüfung auf Gebrauchstauglichkeit findet als Test mit den Zielgruppen statt. Und hier schließt sich der Kreis von Regel 7 zu Regel 1 („Schreibe aus Sicht des Lesers“). Das Anfertigen eines Architekturüberblicks stelle ich überhaupt gerne als Kreislauf dar (initial klein Starten, dann schrittweise Verfeinern). Eine Darstellung dieser Idee findet Ihr zum Beispiel in unseren Architektur-Spicker #1 („Der Architekturüberblick“, Download als PDF) auf Seite 3 oben.

JUG Saxony Day 2016: Architekturdokumentation heute vs. 1999

By | Publikationen, Vorträge | No Comments
„Architekturdokumentation heute: Die 7 Regeln in Stein gemeißelt?“
Logo JUG Saxony Day
Sprecher: Stefan Zörner
Vortrag auf dem JUG Saxony Day 2016
Freitag, 30. September 2016, 11:30 – 12.30 Uhr
Radebeul bei Dresden, im Radisson Blu Park Hotel & Conference Centre

Download Folien Download (PDF)

„Schreibe aus Sicht des Lesers! Erkläre Deine Notation! Verwende eine Standardgliederung! …“ Die klassischen sieben Regeln für gute (Architektur-)dokumentation sind so alt, dass Ihr sie vielleicht gar nicht kennt.

Doch die Frage, wie Ihr Eure Lösungskonzepte festhaltet, kommuniziert und wirkungsvoll in der Umsetzung verankert, bleibt – und ihre Relevanz nimmt in Zeiten selbstorganisierter Teams eher noch zu.

Dieser Vortrag ruft Euch die Regeln nicht nur (falls nötig) in Erinnerung, sondern diskutiert und hinterfragt sie im heutigen Kontext. In dem leichtgewichtige Formen Schwergewichte wie die UML mehr und mehr verdrängen und in dem Entwickler die Architekturarbeit verantworten.

Lernt anhand praktischer Beispiele zeitgemäße Formen eines Architekturüberblicks und ein schlankes Vorgehen für dessen Erstellung kennen. Sowie Möglichkeiten, wie Ihr die Dokumentation näher an die Entwicklung bringt, und die Umsetzung Eurer Architektur dort angemessen überprüft. Von Richtlinien zu Prinzipien und Tests. Der Quelltext erzählt nicht die ganze Geschichte …

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

BEDcon 2016: Die 7 Regeln für gute Dokumentation in Stein gemeißelt?

By | Publikationen, Vorträge | No Comments
„Architekturdokumentation heute: Die 7 Regeln in Stein gemeißelt?“
Logo BEDcon
Stefan Zörner
Vortrag auf den Berlin Expert Days 2016
16. September 2016, 11:40 – 12:40 Uhr
Berlin, in der Urania

Download Folien Download (PDF)

„Schreibe aus Sicht des Lesers! Erkläre Deine Notation! Verwende eine Standardgliederung! …“ Die klassischen sieben Regeln für gute (Architektur-)dokumentation sind so alt, dass Ihr sie vielleicht gar nicht kennt.

Doch die Frage, wie Ihr Eure Lösungskonzepte festhaltet, kommuniziert und wirkungsvoll in der Umsetzung verankert, bleibt – und ihre Relevanz nimmt in Zeiten selbstorganisierter Teams eher noch zu.

Dieser Vortrag ruft Euch die Regeln nicht nur (falls nötig) in Erinnerung, sondern diskutiert und hinterfragt sie im heutigen Kontext. In dem leichtgewichtige Formen Schwergewichte wie die UML mehr und mehr verdrängen und in dem Entwickler die Architekturarbeit verantworten.

Lernt anhand praktischer Beispiele zeitgemäße Formen eines Architekturüberblicks und ein schlankes Vorgehen für dessen Erstellung kennen. Sowie Möglichkeiten, wie Ihr die Dokumentation näher an die Entwicklung bringt, und die Umsetzung Eurer Architektur dort angemessen überprüft. Von Richtlinien zu Prinzipien und Tests. Der Quelltext erzählt nicht die ganze Geschichte …

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

Die sieben Regeln für gute Dokumentation in Stein gemeißelt? — Tafel 2 (von 3)

By | Allgemein, Inhaltliches | No Comments

In einem früheren Beitrag hatte ich bereits mit der kurzen Diskussion von zwei der sieben Regeln für gute Dokumentation begonnen. Hier geht es weiter. Nochmal kurz zur Erinnerung alle Regeln im Überblick:

 

book

1. Schreibe aus Sicht des Lesers. (Tafel 1)
2. Vermeide unnötige Wiederholungen. (Tafel 2)
3. Vermeide Mehrdeutigkeit. Erkläre Deine Notation.
4. Verwende eine Standardstrukturierung. (Tafel 2)
5. Halte Begründungen für Entscheidungen fest. (Tafel 1)
6. Halte Dokumentation aktuell, aber auch nicht zu aktuell. (Tafel 2)
7. Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit.

Starten möchte ich mit einer Regel die falsch angewendet sogar richtig Schaden anrichten kann. Der vierten.

Verwende eine Standardstrukturierung (Regel 4)

Wenn Ihr Dokumentationszutaten über den Quelltext hinaus anfertigt (beispielsweise Schritt-für-Schritt-Anleitungen zu übergreifenden Themen wie Persistenz oder Security) stellt sich die Frage wo Ihr das Ganze ablegt und strukturiert. Dies vierte Regel wird gerne als Reklamesatz für arc42 herangezogen. arc42 stellt eine Standardgliederung für Architekturbeschreibungen dar (in D-A-CH De-facto-Standard).
list-2
Tatsächlich findet alles irgendwie seinen Platz in arc42 (der Abschnitt „Konzepte“ entpuppt sich dabei in der Praxis als Joker). Ich rate Euch aber davon ab, Architekturdokumentation initial anzufertigen, in dem Ihr eine vollständige arc42-Gliederung (immerhin 12 Abschnitte) geschlossen z.B. als Word-Dokument „ausfüllt“.

Den Wert von arc42 sehe ich vor allem im Nennen möglicher Zutaten einer Dokumentation, die zusätzlich zum Quelltext im Team entstehen. Die Kontextabgrenzung etwa, oder Qualitätsziele. Hier gibt es übrigens große Überdeckungen zu Alternativen. Die arc42-Gliederung selbst hat dann ihren großen Auftritt, wenn Ihr eine Architekturbeschreibung aus den einzelnen Bestandteilen für eine bestimmte Zielgruppe zusammen setzt. Darüber hinaus hilft die Struktur auch beim Verwalten der Teile.

Standardgliederungen funktionieren übrigens auch in kleinerem Rahmen gut. Muss nicht gleich die ganze Architekturbeschreibung sein. Beispielsweise bei Schnittstellen und Entscheidungen ist die immer gleiche Struktur hilfreich. Sie gibt den Erstellern Sicherheit und Orientierung. Im Falle von Architekturentscheidungen unterstützt sie auch das Treffen derselben (die Dokumentation fällt ab). Dieser Beitrag enthält eine praxisbewährte Gliederung für Architekturentscheidungen.

Der Schaden, den diese vierte Regel nun anrichten kann, entfaltet sich in Kombination mit der nächsten.

Vermeide unnötige Wiederholungen (Regel 2)copy

Beim Nachdenken über diese Regel stolpere ich über das Wort „unnötig“. „Don’t repeat yourself“ ist ein prominentes Prinzip (auch DRY). Wenn hier explizit von „unnötigen“ Wiederholungen die Rede ist, scheint es auch solche zu geben, die nötig oder zumindest OK sind. DRY gibt mehr Orientierung … Was will und Regel 4 sagen?

Falls Ihr Architekturdokumentation wie oft gesehen in einem arc42-Dokument in Word anfertigt, geratet Ihr bei Anwendung von „Schreibe aus Sicht des Lesers“ (Regel 1) in ein Problem: Ein einziges Dokument  wird mehrere Zielgruppen nicht gerecht. Widersteht dem Reflex, einzelne Dokumente für die jeweiligen Zielgruppen anzufertigen (gute Idee eigentlich), und die betreffenden Inhalte dann jeweils hinein zu kopieren (schlechte Idee). Ihr lauft Gefahr, dass sich die geklonten Inhalte unabhängig voneinander ändern, und/oder habt hohe Wartungsaufwende.

Fertigt die Inhalte stattdessen jeweils einmal kleinteilig an, und führt sie bei Bedarf in unterschiedlichen  Dokumenten oder anderen Formen zusammen. Am besten geht dies automatisiert, etwa im Rahmen des Build-Prozesses. In der Projektpraxis sehen wir als Formate hier eher Markdown oder (häufiger) AsciiDoc als Word. Diese fühlen sich in einer Versionsverwaltung wohl; diff und merge funktionieren prima. Mit Hilfe von Includes entstehen passende Dokumente für unterschiedliche Zielgruppen durch Rekombinieren der Inhalte. Dieser Beitrag stellt eine entsprechende Werkzeugkette mit Markdown und Maven bzw. alternativ Gradle vor.

Ebenso wie einzelne Architekturdokumentation für unterschiedliche Zielgruppen durch Cut/Copy/Paste zu erzeugen solltet Ihr keine umfangreichen Inhalte aus anderen Teilen der Dokumentation (Klassiker: Anforderungen) in Eure Dokumentation kopieren. Verweist auf sie. OK ist aus meiner Sicht eine knappe Zusammenfassung, um den Lesern das Verfolgen des Links zu ersparen, die nur einen Überblick haben wollen. Hier handelt es sich um einen Kompromiss zwischen leichter Lesbarkeit und Wartbarkeit. Das führt zu Wiederholungen, die im Sinne der Regel OK sind.

Halte Dokumentation aktuell, aber auch nicht zu aktuell (Regel 6)file-2

Veraltete Dokumentation ist häufig eine Ausrede um überhaupt nicht zu dokumentieren. Dahinter stecken zwei Annahmen:

  1. Dokumentation veraltet sowieso
  2. Veraltete Dokumentation ist wertlos

Dazu lässt sich sagen: Eine festgehaltene (Architektur-)Entscheidung veraltet keineswegs, solange Ihr nicht von ihr abweicht. Vielleicht würdet Ihr heute anders entscheiden, mittlerweile haben sich Rahmenbedingungen oder Ziele geändert, Optionen sind dazugekommen, Annahmen haben sich als falsch herausgestellt. Kurz: Ihr seid schlauer. Um die Entscheidung nachvollziehen zu können ist aber der Zeitpunkt der Entscheidung relevant. Und da Architekturentscheidungen typischerweise schwer zurückzunehmen sind, ist eine spätere Umentscheidung unwahrscheinlich. Wenn Eurer Team in bestimmten Ausnahmefällen von dieser Entscheidung abweicht, ist es erst recht lohnenswert, diese Tatsache festzuhalten und das Wissen darum zum Beispiel an Neue weiterzugeben. Merke: Dokumentation unterstützt Kommunikation.

Neben den dokumentierten Entscheidungen gehören vor allem Lösungskonzepte und Mittel, die es leichter machen im Quelltext zurecht zu finden, in Eure Architekturdokumentation. Zu letzteren gehören Diagramme, die Strukturen und Abläufe zeigen (ungeliebte und unangefochtene Notation: UML). Die Wahrscheinlichkeit, dass Konzepte und Diagramme veralten, nimmt mit dem Detaillierungsgrad zu.

Veraltete Dokumentation weicht von der Lösungsrealität (dem Quelltext) ab. Das Team hat Änderungen und Ergänzungen also nicht nachgezogen.

Ich lese diese Regel daher vor allem so: Wenn Ihr merkt, dass Ihr viel Aufwand zum Nachziehen betreiben müsst, fragt Euch, ob dieser in einem gesunden Verhältnis zum Nutzen steht. Falls nein: Abstrahieren oder Automatisieren:

  • Abstrahieren — die Dokumentation beschreibt keine Lösungsdetails, sondern liefert einen Überblick
  • Automatisieren — Teile der Dokumentation werden z.B. im Rahmen des Builds aus dem Quelltext abgeleitet

Und die anderen Regeln?

In einem weiteren Beitrag hier im Blog führe ich die Diskussion mit den verbliebenen zwei Regeln fort. Bleibt dran …

Die sieben Regeln für gute Dokumentation in Stein gemeißelt? — Tafel 1 (von 3)

By | Inhaltliches | No Comments

ten-commandment-64x64Die 10 Gebote blicken auf eine bewegte Vergangenheit zurück. Jahrtausende alt und immer noch gültig nicht nur im christlichen Miteinander. Der Überlieferung nach in zwei Tafeln aus Stein gemeißelt (drei bei Mel Brooks) und in der Bundeslade verwahrt, hinter der Indiana Jones her war (und die Schurken im Film auch) und die zuletzt auch in James Frey’s Bestseller „Endgame“ eine Rolle spielte …

Als die zehn Gebote Einzug in das Alte Testament hielten gab es noch keine Softwareentwicklung. Die Leute hatten andere Sorgen.

DocumentingSoftwareArchitecturesNicht ganz so alt (und weniger berühmt) sind die 7 Regeln für gute Dokumentation (im Original: „Seven rules for sound documentation“). Aber immerhin auch schon fünfzehn Jahre. Gedruckt zwischen die zwei Buchdeckel des englischen Standardwerks zu Architekturdokumentation.

Wer von Euch sie zum Beispiel altersbedingt nicht kennt … Kurz zum Kennenlernen — bzw. zur Auffrischung:

1. Write documentation from the point of view of the reader, not the writer.
2. Avoid unnecessary repetition.
3. Avoid ambiguity. Always explain your notation.
4. Use a standard organization.
5. Record rationale.
6. Keep documentation current but not too current.
7. Review documentation for fitness of purpose.

Als das betreffende Buch erschien war der Rational Unified Process ebenso topaktuell wie die UML oder J2EE. Seither ist einiges passiert in der Softwareentwicklung.

Leser1. Schreibe aus Sicht des Lesers. Wiederholung2. Vermeide unnötige Wiederholungen. Hieroglyphen3. Vermeide Mehrdeutigkeit. Erkläre Deine Notation.
Gliederung4. Verwende eine Standardstrukturierung. Begründung5. Halte Begründungen für Entscheidungen fest. Aktualität6. Halte Dokumentation aktuell, aber auch nicht zu aktuell.
Präsentation7. Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit.

Ich möchte in diesem und zwei weiteren Beiträgen die obigen sieben Regeln im heutigen Licht diskutieren. Können Sie uns heute noch etwas sagen? Oder ist das ganze ein Relikt (dann konservieren wir es mit Lastenheft und Systemtestphase)?

Aus dramaturgischen Gründen gehe ich in einer anderen Reihenfolge vor …

Halte Begründungen fest, oder „Warum solltet Ihr überhaupt dokumentieren?“ (Regel 5)

unknown-documentSimon Brown sagt so schön „Der Quelltext erzählt nicht die ganze Geschichte“. Er steht damit im Kontrast zum beliebten Satz „Der Quelltext ist die Dokumentation“ (… und darüber hinaus dokumentieren wir nichts).

Wenn es um das Festhalten von Informationen geht hat Quelltext Charme. Er ist in jedem Fall erforderlich, das Team versioniert ihn, testet ihn, er ist stets up-to-date. Und tatsächlich kann man dem Quelltext (oder den zugehörigen und gemeinsam versionierten Build-oder Deployment-Skripten) vieles entnehmen. Welche Fremdbibliotheken verwendet werden beispielsweise. Was genau verschweigt der Quelltext?

Einige Informationen lassen sich dem Quelltext zumindest schwierig entlocken. Die Struktur der Lösung beispielsweise, insbesondere wenn es mehrere Zerlegungsideen gibt (technisch in Schichten, fachlich in Komponenten z.B.). Oder wenn Aspekte über die ganze Lösung hinweg einheitlich gelöst sind und es auch bleiben sollen.

Oft macht der Quelltext zwar die Aussage, dass etwas verwendet wird (beispielsweise eine Fremdbibliothek). Aber ob es die Entscheidung des Teams war es zu verwenden, oder eine Vorgabe, das verschweigt der Quelltext bereits. Und im Falle einer Entscheidung des Teams fehlen Informationen zu in Erwägung gezogenen Alternativen, ebenso zu Bewertungskriterien derselben.

Wenn Nachvollziehbarkeit gefragt ist, reicht der Quelltext oft nicht aus. Wenn etwa ein Neuer im Projekt fragt „Warum habt Ihr das so gemacht? Hätte man ja auch anders …“ — da antwortet er nicht. Womit wir direkt bei der nächsten Regel sind.

Schreibe aus Sicht des Lesers (Regel 1)

eyeglasses-of-thin-shapeKlingt vernünftig die Regel, aber beim Nachdenken über Architekturdokumentation wirft sie sofort die Frage auf, wer denn genau dieser Leser ist. Wenn Euch im Team beim besten Willen kein potentieller Interessent für Eure Dokumentation einfällt, solltet Ihr keine schreiben. Dürfte ja keiner merken.

Viele Teams identifizieren jedoch als Zielgruppe sofort den Neuen im Team, oder auch das Entwicklungsteam selbst. Ich mache in Projekten immer sehr Reklame dafür, solche Zielgruppen und deren Informationsbedürfnis (in Form von Zielen) aufzuschreiben. Nicht ausführlich, aber explizit.

Zum Beispiel:

  • Der neue im Team — will sich schnell zurecht finden, zur Lösung beitragen, die Software selber bauen und deployen können …
  • Ein Teammitglied — will Lösungsansätze anderer im Team nachvollziehen können und sich Good Practices abgucken …

Das heißt nicht unbedingt, dass eine Dokumentation diese Ziele ohne Zutun anderer im Team löst. Dokumentation erspart Euch nicht die Kommunikation. Aber: sie unterstützt dabei, d.h. die Sachen, die über den Quelltext hinaus angefertigt werden, helfen beim Erklären.

Und die anderen Regeln?

In zwei Folgebeiträgen hier im Blog führe ich die Diskussion mit den verbliebenen Regeln fort. Ich habe mir ein paar Highlights aufgespart: die Frage nach Redundanz, Aktualität, Notationen …

Artikel im Java Magazin 09/2016: Bring your own Architecture. Softwarearchitektur wird Entwickler-Skill

By | Artikel, Publikationen | No Comments
Bring your own Architecture — Softwarearchitektur wird Entwickler-Skill

Java Magazin 09/2016

Bring your own Architecture — Softwarearchitektur wird Entwickler-Skill
Autor: Stefan Zörner
Artikel im Java Magazin 09/2016, 5 Seiten, Seite 32-36
erschienen am 1. August 2016

Softwarearchitektur beschäftigt sich mit weitreichenden Entscheidungen, die später schwer zurückzunehmen sind. Aktuell liegen hingegen Microservices im Trend, die Applikationen in kleinere Einheiten mit eigenem Entwicklungsteam und individuellem Technologie-Stack aufbrechen. So klein, dass es billiger ist, sie bei Bedarf neu zu bauen. Wenn wir uns falsch entscheiden werfen wir sie einfach weg. Verliert Softwarearchitektur in einem solchen Szenario an Relevanz?

weitere Infos zum Heft

 
follow us on Twitter – @embarced