IMAG0595_Anne_GrungeDie 90er – Vorgaben geben Orientierung.

Vor geraumer Zeit habe ich einen Workshop zur Einführung in Objektorientierung (OO) durchgeführt. Der Kunde spielte mit dem Gedanken, nun tatsächlich alles in Java zu machen, gar kein COBOL mehr. Und eine Reihe Entscheider wollte nun endlich verstehen, was es mit diesem OO auf sich hat. Oft kommt das heute nicht mehr vor, dass Leuten OO fremd ist. Bei oose, wo ich arbeite, ziehen wir schon Vergleiche zu BASF. oose stand ursprünglich für „Objektorientierte Softwareentwicklung“, ähnlich wie „Badische Anilin- und Soda-Fabrik“ (BASF) schreiben wir das heute nicht mehr aus. OO ist Commodity, fast schon Legacy. 90er halt.

Eine Szene aus der Veranstaltung damals ist bei mir besonders haften geblieben. Als ich Entwürfe am Flipchart visualisierte, fragte einer der Teilnehmer: „Kommt da eigentlich später auch Software raus?“ Ich war verwirrt. Worauf der Mann erklärte, ihm wäre aufgefallen, dass in den OO-Projektzimmern immer ganz viele Bilder mit Kästchen und Pfeilen hingen. Zu seiner Zeit hätten sie noch ausgedruckte Listings und ER-Modelle aufgehängt. Zeitreisen sind möglich.

Die Blütezeit von Vorgehensmodellen wie z.B. dem Rational Unified Process (RUP) ist ebenfalls vorbei. Der RUP hat recht umfangreiche Empfehlungen zum Einsatz der graphischen Notation UML, und schlägt auch konkrete Dokumente vor, in denen die „Artefakte“ zusammengefasst werden (z.B. „Software Architecture Description“). Auch das V-Modell des Bundes liefert fertige Vorlagen für Dokumente mit (Beispiel: „SW-Architektur“). In der aktuellen Fassung V-Modell XT von steht XT übrigens für „Extreme Tailoring“.

Die 2000er – Vorgaben sind unagil. Bäh.

Agile Methoden machen dagegen kaum Vorgaben bzgl. Dokumentation. Entsprechend visualisieren Projektteams heute kaum noch die Architektur, sie halten generell wenig dazu fest. So zumindest meine Erfahrung. Der Extremstandpunkt (in Verkennung des agilen Manifests): „Der Quelltext ist die Dokumentation“.

„Funktionierende Software ist toll. Dokumentation wird überbewertet.“

(Agiles Manifest, aus dem Zusammenhang gerissen und falsch zitiert)

Simon Brown bemerkt treffend, dass heutige agile Teams gelernt haben ihren Prozess und Projektfortschritt zu visualisieren. Kanban-Boards, Backlogs mit Post-its und andere analoge Ergebnisse in den Projekträumen beweisen es. Ihre Lösungen zu visualisieren hätten die Teams größtenteils verlernt.

Softwarearchitektur umfasst die grundlegende Struktur eines Softwaresystems, das Fundament. Die Menge der Entscheidungen, die im weiteren Verlauf nur schwer zu ändern sind. Prinzipien, die Entscheidungen leiten. Solche Entscheidungen und Prinzipien gibt es auch in agilen Teams. Auch dort wird eine konsistente Lösung angestrebt. Die Notwendigkeit, Ideen, Konzepte und Lösungen rund um Softwarearchitektur zu kommunizieren, besteht also weiterhin. Vielleicht sogar mehr als früher, da Kommunikation im agilen Weltbild eine große Bedeutung hat. Da Softwarearchitektur heute im Team entwickelt wird.

Warum es trotzdem Wert hat.

Wirkungsvolle Architekturdokumentation unterstützt die Kommunikation, sie ist kein Selbstweck. Und so gibt es auch moderne, schlanke Strukturvorschläge für Architekturbeschreibungen. Im deutschsprachigen Raum ist das von Gernot Starke und Peter Hruschka initiierte arc42 sehr beliebt; auch Simon Brown schlägt in seinem Buch eine Gliederung vor.

Von derartigen Vorlagen profitieren zunächst einzelne Teams und Projekte. Sie brauchen das Rad nicht neu zu erfinden, starten mit einer bewährten Grundlage, passen sie bei Bedarf geeignet an. Die Abbildung unten zeigt zur Illustration die Gliederung von arc42, ein Beispiel für einen danach strukturierten Architekturüberblick finden sie hier.

Quelle der Abbildung: [1]

Bild 1: Struktur von arc42, aus Softwarearchitekturen dokumentieren und kommunizieren

Macht es nun Sinn, schlanke Dokumentationsansätze wie beispielsweise arc42 flächendeckend im eigenen Unternehmen zu etablieren. Oder ist das voll 90er?

Zunächst einmal: Es gibt klassische Szenarien, in denen über die Vereinheitlichung der Dokumentation von Softwareentwürfen nachgedacht wird:

  • Ein Unternehmen/eine Organisation beschreibt seine Systemlandschaft.
  • Ein Unternehmen stellt eine Produktfamilie her, und  muss Varianten bzw. ähnliche Lösungen dokumentieren.
  • Ein Unternehmen ist Dienstleister, hat viele Projekte bei unterschiedlichen Kunden, und muss seine Lösungen festhalten.

In all diesen Fällen geht es nicht um ein einzelnes System. Wer hier die Art der Architekturdokumentation vereinheitlicht, verspricht sich verschiedene Dinge (je nach Szenario), zusätzlich zu der Tatsache, dass nicht jedes (Teil-)projekt das Rad neu erfindet. Hinzu kommt insbesondere die Hoffnung, dass sich Mitarbeiter schneller in anderen Projekten oder Systemen zurechtfinden, und dass sich Teile der Dokumentation über Systemgrenzen wiederverwenden lassen, etwa übergreifende Konzepte.

Was nun? Was tun?

Der Ansatz, einfach das arc42-Template an die Projektteams zu verteilen, am besten als einzelnes Word-Dokument, und gut ist, greift meiner Erfahrung nach nicht. Er treibt im Gegenteil sogar seltsame Blüten. Kombiniert mit einer rigiden Kontrolle, ob denn auch alle Kapitel ausgefüllt werden, landen wir tatsächlich in einer vergessen geglaubten Zeit. Selbst das Zugeständnis, die Vorlage nicht vollständig ausfüllen zu müssen, ist meines Erachtens nicht zeitgemäß, sondern erinnert eher an das Tailoring (Zurechtschneidern) früherer Vorgehendmodelle, das dann in der Praxis schnell zum Weg-Tailorn wurde: Möglichst viel weglassen, und dann nur noch das tun, was übrig bleibt.

Das Problem: Wenn Entwickler fragen, warum sie Kapitel xy ausfüllen müssen, und als Argument nur kommt, dass es nicht gelungen ist, es wegzutailorn, motiviert das die ohnehin unbeliebte Aufgabe des Dokumentierens nicht. Die Ergebnisse sind entsprechend. Andersherum streichen vorsichtige Teams eher zu wenig („Vielleicht ist es ja doch irgendwann sinnvoll“), und machen dann zu viel, oder sind darin behindert fokussiert zu starten.

Lösungsansatz fernab vom Weg-Tailorn

Wirkungsvoller ist es aus meiner Sicht, sich bewusst für einzelne Zutaten einer Architekturdokumentation zu entscheiden, und diese Entscheidung jeweils an den Zielen und vor allem den anvisierten Zielgruppen festzumachen. Diese einzelnen Zutaten lassen sich dann rekombinieren, sie werden weitaus beweglicher als mit einem einzelnen Dokument. Und sie können das Anfertigen der einzelnen Zutaten besser motivieren. Die erste Regel für gute Dokumentation („Schreibe aus Sicht des Lesers“, siehe „Rules for Sound Documentation“ in [2] oder auch Software Architecture Documentation in Practice), lässt sich ebenfalls weitaus besser befolgen.

Dieser Ansatz macht Strukturvorlagen wie arc42 nicht überflüssig. Im Gegenteil: sie können als Kandidatenliste für Zutaten dienen, und zur Orientierung, wie man die Zutaten geschickt in eine Reihenfolge bringt. Es ist ein Unterschied, ob Sie eine Vorlage (ggf. nur teilweise) ausfüllen, oder Zutaten zusammenführen. Wenn sich Teams und Projekte eine einheitliche Wissensbasis zu Zutaten und Strukturierung teilen, sich gegenseitig Ergebnisse (und damit ihre Entwürfe und Lösungen) vorstellen und Rückmeldung dazu geben, erzielen sie Effekte, die einer starren Vereinheitlichung von Architekturbeschreibungen überlegen sind. Und im Einklang mit agilen Prinzipien ist der Ansatz obendrein.