Für die meisten Softwaresysteme gibt es keine gute Architekturdokumentation. Oft macht das niemand gerne und manchmal kann es auch niemand im Projekt gut. Früher oder später wird das immer zum Problem, ob man es wahrhaben möchte oder nicht. Aber eigentlich ist es völlig klar, dass es so kommen muss bei der Komplexität, die Softwaresysteme nun mal haben. In diesem Artikel schreiben wir über einen Ansatz, wie dieses Problem auch gelöst werden kann: Durch einen Phantombildzeichner mit der expliziten Rolle und Aufgabe, die Architektur eines Softwaresystems herauszuarbeiten und so zu dokumentieren, dass sie die Realität gut abbildet und mit der Dokumentation die erhofften Ziele erreicht werden.

Das leidige Thema mit der Architekturdokumentation

Kaum jemand schreibt gerne Architekturdokumentation. Befeuert wird das zusätzlich vom agilen Grundsatz: „Working software over extensive documentation“. „Da habe ich die Absolution, doch lieber Code zu schreiben“. „Da kommt wenigstens etwas Ausführbares heraus“. Doku ist ja scheinbar nicht so wichtig und für einen Artikel im Confluence gibt es auch weniger Ruhm.

Gleichzeitig würde aber kaum jemand bezweifeln, dass man in Softwareprojekten eigentlich schon eine Architekturdokumentation braucht. Es würde ja auch keiner auf die Idee kommen, einen Wolkenkratzer oder eine Brücke zu bauen, ohne irgendetwas zu skizzieren, modellieren und aufzuschreiben.

In der Folge wird Architekturdokumentation in vielen Projekten eher stiefmütterlich behandelt. Wenn es dann doch sein muss, nimmt man sich halt mal ein Template her und füllt möglichst schnell mal in alle Kapitel was ein. Task done, nächstes Ticket.

Das ist schade, denn eine gute Architekturdokumentation ist extrem wertstiftend: Einerseits dient sie allen Beteiligten im Projekt als persistenter Speicher von Ideen, Konzepten und Ansätzen. Wahrscheinlich kennt jeder die Situation, dass schon nach wenigen Tagen immer mehr Details im Kopf verschwinden: „Wie sollte das nochmal funktionieren?“, „Warum haben wir das nochmal so entschieden?“, etc. Im Projekt haben wir es mit solch einer Menge an Details zu tun, dass wir uns einfach nicht alles merken können. Um die Entwicklung effizient zu gestalten, sollten wir also unsere Kernideen aufschreiben.

Darüber hinaus dient Architekturdokumentation insbesondere als Kommunikationsmittel. Es ist wichtig, dass sich bei allen Projektbeteiligten ein gemeinsames Bild davon ergibt, wie das System strukturiert sein und funktionieren soll, weil nur so das System konsistent und wartbar umgesetzt werden kann.

Außerdem präzisieren wir durch das Aufschreiben unsere Ideen und Konzepte, können prüfen, ob sie geeignet sind, um damit unsere (Qualitäts-)Ziele zu erreichen, etc.

Aber um diesen Wert zu entfalten, muss die Architekturdokumentation eben auch gut gemacht sein.

Was machen wir aus der Misere? Einerseits ist klar, dass wir eine gute Architekturdokumentation brauchen, andererseits haben wir wenige Leute im Projekt, die sich damit beschäftigen möchten und dafür die richtige Erfahrung mitbringen. Es wäre irgendwie schön, wenn sich jemand anders darum kümmern könnte.

Phantombildzeichner für Softwarearchitektur

Wir schlagen dafür eine neue Rolle vor: den Architektur-Phantombildzeichner. Inspiriert dazu hat uns schon vor langer Zeit ein Talk von Gregor Hohpe bei der OOP 2017, in dem er über die unterschiedlichen Rollen und Aufgaben von Softwarearchitekt:innen gesprochen hat, darunter war auch als Kurzepisode der Phantombildzeichner für die Architektur des Systems. Das haben wir über die Zeit häufiger aufgegriffen, selbst in der Rolle agiert und die Erfahrungen und Erkenntnisse dazu möchten wir in diesem Artikel teilen.

Die Idee lehnt sich an Phantombildzeichner aus der Kriminalistik an. Was hat es damit im Kern auf sich? Viele Personen können nicht gut Personen zeichnen, jedoch aber punktuelle Antworten zum Aussehen von Personen geben, wenn ihnen die richtigen Fragen gestellt werden. Phantombildzeichner sind Menschen, die in der Lage sind, diese Fragen gezielt an Zeugen von Verbrechen zu stellen und in interaktiven Sessions auf Basis von solchen Personen-Beschreibungen ein sehr gutes und realistisches Bild der beschriebenen Person zu zeichnen, auch wenn der Zeuge selbst kein Bild zeichnen kann.

Das lässt sich auf die Softwarearchitektur übertragen: Jedes System hat eine Architektur. Aber nicht immer ist jemand da, der diese beschreiben kann oder will. Dann können andere (auch externe) Software-Architekt:innen diese Aufgabe übernehmen. Die Idee ist nun, diese grob und intuitiv umrissene Aufgabe klarer herauszuarbeiten und eine explizite Rolle und Verantwortlichkeit daraus zu machen.

Der Architektur-Phantombildzeichner ist dafür verantwortlich, den Teams im Projekt zu helfen, ihre Architektur zu dokumentieren. Dafür spricht er mit den unterschiedlichen Mitgliedern des Teams, findet die wichtigsten, architekturrelevanten Informationen heraus und erstellt daraus eine Architekturdokumentation, die dem Team gehört, mit der es arbeiten und die es perspektivisch auch selbst weiterentwickeln kann. Der Architektur-Phantombildzeichner kann durchaus jemand von außerhalb sein, der für eine gewisse Zeit zum Team kommt und gemeinsam mit den Leuten arbeitet, beispielsweise ein Mitglied eines Enabling-Teams im Sinne von Team Topologies. In jedem Fall sollte es aber jemand sein, der diese Aufgabe gut kann und Spaß dabei hat, und so nicht nur einmal das Ergebnis produziert, sondern auch bei einer nachhaltigen Veränderung beim Umgang mit Dokumentation unterstützen kann.

Vorgehen beim Phantombildzeichnen von Architekturen

Meistens wird eine Phantombildzeichnerin hinzugerufen, wenn schon einiges im Projekt passiert ist. Man hat sich schon einiges überlegt, über einige Sprints hinweg wurde schon entwickelt und man merkt langsam, aber sicher, dass es eigentlich gut wäre, die wichtigsten Dinge mal strukturiert aufzuschreiben. Der Phantombildzeichner sieht sich also zunächst mit einer Situation konfrontiert, in der schon einiges gebaut, aber bisher nur absolut rudimentär aufgeschrieben ist. Der erste und wichtigste Schritt ist also zunächst: Informationen zusammentragen. Und das machen wir, ganz analog zum Phantombildzeichner, indem wir mit den Leuten sprechen, die erklären können, wie der Verdächtige (in unserem Fall also die Architektur des Systems) aussieht.

Das passiert typischerweise im Rahmen von Interviews. Nach unserer Erfahrung funktioniert so ein Interview gut mit einer kleinen Gruppe, optimalerweise mit ein oder zwei Entwickler:innen oder Architekt:innen, die viele der zentralen Entscheidungen für das System oder Systemteil getroffen und / oder umgesetzt haben. Sie müssen sich also richtig gut auskennen und gut auch auf detaillierte Fragen antworten können. Für ein Interview sollte man mindestens zwei Stunden einplanen, ansonsten erreicht man nicht den Grad an Detail, den man benötigt, um sinnvollen Fortschritt zu generieren. Wir haben aber auch schon ganze Tage dafür blockiert. In der Praxis nimmt man einfach, was man bekommen kann.

Diese Interview-Sessions macht man iterativ, das heißt, im Rahmen eines Interviews erhebt man ganz viele Informationen, die man im Nachgang aufbereitet und verarbeitet. Dabei merkt man sehr schnell, was noch unklar ist, wo man Rückfragen stellen muss und was als nächstes Thema besonders relevant ist. Diese Themen bereitet man entsprechend vor und bespricht diese dann in der nächsten Session. Und dann das Gleiche von vorne.

In den Interviews ist die Aufgabe des Phantombildzeichners, alles herauszufinden, was bezüglich der Architektur des Systems wichtig ist. Das heißt: fragen, fragen, fragen. Sowohl breit als auch tief. Man muss immer mental bei der Sache sein, auf alle Besonderheiten achten, klären, was man nicht verstanden hat, und Details hinzufügen, bis sich ein ausreichendes, mentales  Bild der Struktur und Funktionsweise des Systems geformt hat. Gut funktioniert dafür auch ein Wechsel zwischen sehr offenen Fragen („Erklär doch einfach mal, wie hier der Ablauf ist“) und sehr detaillierten Nachfragen. Außerdem empfiehlt es sich, auch mal gemeinsam am Whiteboard zu stehen und Sachverhalte zu visualisieren. Dabei merkt man ganz schnell, ob man vom Gleichen spricht.

Interviews müssen gut vorbereitet werden, das heißt, man muss sich einen guten Plan zurechtlegen, was man im anstehenden Interview alles herausfinden will. Da jedes System anders und einzigartig ist, gibt es dafür natürlich kein vorgefertigtes Rezept. Trotzdem kann man sich für das Grobvorgehen von typischen, häufig wiederkehrenden Fragestellungen leiten lassen. Hier einige Beispiele:

• Warum bauen wir das System?
• Was ist der geschäftliche Kontext?
• Wie sieht die Ausgangssituation aus?
• Was sind die wichtigsten Ziele, die mit dem System erreicht werden sollen?
• Wie sieht die Produktvision aus?
• Wie sehen die Geschäftsprozesse aus, die wir mit dem System unterstützen wollen?
• Wer sind die wichtigsten Stakeholder?
• Was sind wichtige Rahmenbedingungen, die wir beachten müssen?
• Was sind die zentralen, funktionalen Anforderungen für das System?
• Was sind die wichtigsten Qualitätsanforderungen für das System?
• Was ist die übergeordnete Lösungsstrategie?
• Was sind die zentralen Entscheidungen, die für das System getroffen wurden?
• Wie sieht der System-Kontext aus: Welche Nutzer:innen gibt es und mit welchen anderen Systemen muss unser System interagieren?
• Wie ist das System intern strukturiert (Bausteine, Interaktionen)?
• Wie ist die grundsätzliche Funktionsweise des Systems?
• Was sind die zentralen Datenmodelle?
• Wie werden Daten verarbeitet und gespeichert?
• Wie wird das System deployt?
• Welche Ausführungsumgebung kommt zum Einsatz?
• Wie ist der Code strukturiert?
• Was sind die zentralen fachlichen / technischen / Qualitäts-Konzepte?
  • Welches Problem muss gelöst werden?
  • Was sind Anforderungen?
  • Was ist der Lösungsansatz / wie funktioniert das Konzept?
  • Was sind die wichtigsten Entscheidungen darin?
  • Welche Alternativen wurden berücksichtigt aber verworfen und aus welchem Grund?

Diese allgemeinen Fragestellungen sollen natürlich nur als erste Anregung dienen. Sie müssen dann auf das konkrete System angepasst und um spezifische Fragestellungen ergänzt werden. Ihr seht aber, es gibt einiges herauszufinden.

Informationen, die man im Rahmen von Interviews herausgefunden hat, kann die Phantombildzeichnerin nun verarbeiten, um damit die Architekturdokumentation zu erstellen. Der erste Schritt dafür ist meistens, eine geeignete Struktur für die Architekturdokumentation zu gestalten. Templates, wie arc42 können dafür ein guter Startpunkt sein, müssen aber umfassend auf das konkrete System angepasst werden. Das gilt insbesondere da, wo es um die spezifischen fachlichen, technischen und Qualitäts-Konzepte geht.

Hat man sich eine geeignete Struktur überlegt, geht es darum, die Kapitel / Artikel sukzessive mit Leben zu füllen und alle Informationen, die man herausgefunden hat, strukturiert und gut aufbereitet aufzuschreiben. Dazu kommt natürlich auch das eine oder andere Diagramm, um bestimmte Sachverhalte zu visualisieren.

Gut funktioniert ein iteratives Vorgehen: Artikel schreiben, den Interviewpartnern zum Review schicken, nächstes Interview, direkt den nächsten Artikel beginnen, Review-Feedback einarbeiten, rinse and repeat. Das macht man so lange, bis ein ausreichender Grundstock an Architekturdokumentation aufgebaut ist. Hat man das geschafft, kann man die Intensität des Phantombildzeichnens auch langsam etwas herunterfahren und dazu übergehen, eher dem Team zu helfen, anzuknüpfen und darauf aufzubauen. Es bietet sich auch an, noch weiterhin für Fragen bereitzustehen (davon wird es einige geben) und Artikel von anderen zu reviewen und zu überarbeiten. So können die notwendigen Fähigkeiten, die für die Erstellung guter Architekturdokumentationen benötigt werden, auch breiter im Team aufgebautwerden.

Skills für das Phantombildzeichnen von Architekturen

Als grundlegende Voraussetzung für das erfolgreiche Phantombildzeichnen von Softwarearchitekturen sehen wir, dass jemand selbst schon als Softwarearchitekt gearbeitet hat und in der Lage ist, Architekturdokumentationen zu erstellen. Dazu gehört z.B. die Kenntnis von Dokumentationsmethoden und -templates und von Sichten-Frameworks als Grundlage von aussagekräftigen Architekturdiagrammen.

Ganz explizit möchten wir die Rolle des Phantombildzeichners hier nicht direkt mit der Rolle eines „Technischen Zeichners / Schreibers“ gleichsetzen. Gerade dann, wenn Architekturdokumentation fehlt und niemand sie erstellen konnte oder wollte, gibt es immer zu viel Interpretationsspielraum und zu wenig Konventionen, als dass eine Person, die nicht selbst tiefe Kenntnisse in der Gestaltung von Softwarearchitektur hat, diese Rolle gut ausfüllen könnte. Das basiert auf unserer Erfahrung und schließt nicht aus, dass es im Einzelfall auch anders klappen könnte. Wir würden aber davon abraten, Personen mit dem fachlichen Hintergrund Technisches Zeichnen / Schreiben zu suchen, um ihr diese Aufgabe zu übertragen.

Über die grundlegenden Skills hinaus gibt es noch etliche weitere Skills und Erfahrungen, die besonders hilfreich sind. Diese können sowohl bei der Auswahl passender Personen helfen als auch zur Orientierung für die eigene Weiterentwicklung dienen:

• Zielsichere Kommunikation und Hartnäckigkeit: Ein Phantombild einer Softwarearchitektur zu erstellen (also die Architektur zu dokumentieren) bedeutet, sehr viel zu fragen. Typischerweise erzählt einem niemand alles einfach und es muss nur aufgeschrieben werden. Dazu ist es nötig, in netter und klarer Weise sehr viele Fragen zu stellen und teilweise auch sehr hartnäckig zu bleiben, ohne dass es sich anfühlt wie bei einem Verhör.
• Abstraktionsfähigkeit bei gleichzeitiger Präzision: Beim Zeichnen eines Phantombilds einer Softwarearchitektur muss sehr viel Abstraktion aufgebaut werden, weil häufig vorher eher techniknah gearbeitet wurde und niemand die Abstraktionen klar benennen kann. Die passenden Abstraktionen zu finden ist herausfordernd, vor allem weil zwar teilweise Dinge wegabstrahiert werden aber gleichzeitig bezüglich anderer Aspekte eine große Präzision nötig sein kann, um den Kern sauber herauszuarbeiten.

• Stärke in der Entwirrung verflochtener Konzepte: Wenn Architekturen über die Zeit entstanden sind und nicht sauber dokumentiert sind, dann sind häufig viele relevante und verwandte Konzepte miteinander verwoben bis verworren. Für eine saubere Dokumentation sollte das nicht so bleiben. Teils bewegt man sich dabei auf einem schmalen Grat zwischen intendierter Architektur und implementierter Architektur: Es ist klar herauszuarbeiten, wie die Architektur eigentlich gedacht war und wie es dann tatsächlich umgesetzt wurde, weil sich das nicht selten signifikant unterscheidet. Hier muss die Zielsetzung ganz klar sein, was eigentlich dokumentiert werden soll. Auf jeden Fall sollten beobachtete Abweichungen in der Umsetzung immer notiert werden, sodass klar ist, wo nachgearbeitet muss.
• Mut zur temporären Lücke: In den Gesprächen und Interviews zur Erfassung von Informationen über die vorliegende Architektur gibt es keine vorab bekannte vollständige Liste an Fragen, die zur vollständigen Beantwortung führt. Deshalb muss man sich schrittweise vorarbeiten und schrittweise in die Tiefe gehen. Es braucht erst mal einen groben Überblick auf der Gesamtebene, bevor es schrittweise in die Tiefe gehen kann. Deshalb muss man erkennen, wann erst einmal genug besprochen wurde zu einem Thema, obwohl noch viele Fragen dazu offen sind.
• Schnelle Einarbeitung in unbekanntes Terrain: Ein Phantombild von einem unbekannten System zu zeichnen erfordert typischerweise, sich in viele neue Dinge sehr schnell einarbeiten zu müssen. Das kann von der fachlichen Domäne über bestimmte Architekturstile und Technologien bis hin zur spezifischen Arbeitsweise in einem Unternehmen alles sein. Die Kunst besteht darin, zum richtigen Zeitpunkt viele dieser Aspekte zu streifen und zu erfassen und sich dabei sehr schnell einzuarbeiten, auch wenn immer noch viele Wissenslücken bestehen.

• Grundlegendes Verständnis vieler Paradigmen und Technologien: Um sich in ein unbekanntes System schnell einarbeiten zu können, braucht es viel Wissen über möglichst viele Arten, wie Systeme gebaut sein können. Das umfasst z.B. Architekturstile oder -paradigmen und auch Technologien. Natürlich kann niemand in allen diesen Themen absoluter Experte sein. Hier hilft eher etwas abstrakteres Wissen, um sich Zusammenhänge und Konsequenzen schnell zu erschließen, sodass man nicht alles bis ins letzte Detail erfragen muss. Es geht immer eher darum zu fragen, wie ein gewisses Architekturparadigma konkret eingesetzt wurde als darum, wie es grundsätzlich funktioniert. Das ist nämlich auch genau die Information, die dokumentiert werden sollte.
• Didaktische Fähigkeiten für die Vermittlung von Vorgehensweisen bei der Architekturdokumentation: Ein Phantombild einer Softwarearchitektur zu zeichnen ist ganz oft der initiale Schritt, um darauf basierend andere Personen zu befähigen, auf einer soliden Ausgangsbasis in kleinen Schritten weiterzuarbeiten. Dazu ist es notwendig, auch klar erklären und didaktisch aufbereiten zu können, was erarbeitet wurde und wie darauf aufgesetzt werden kann.

Situationen und Aufwand für das Phantombildzeichnen von Architekturen

Die am häufigsten anzutreffende Situation, in der es sinnvoll ist, einen Phantombildzeichner auf die Architektur eines Systems anzusetzen, ist die folgende: Das Entwicklungsvorhaben läuft schon eine ganze Weile und es ist schon ordentlich Fortschritt gemacht worden. Die Architekturdokumentation wurde aber immer stiefmütterlich behandelt. Eigentlich ist klar, dass man besser früher als später anfangen würde, die Architekturdokumentation zu erstellen. Gleichzeitig schrecken aber alle davor zurück, es zu machen, weil klar ist, dass das schon mit einem gewissen Aufwand verbunden ist, der in der aktuellen Situation ungern geleistet wird. Irgendwas ist immer wichtiger. Wenn in dieser Situation ein Phantombildzeichner aushilft, dann kann in relativ kurzer Zeit nachgeholt werden, was lange verpasst wurde. Die vielbeschäftigten Personen in der Hitze des Projekts müssen nur punktuell für Interviews zur Verfügung stehen und es geht trotzdem schnell voran. Für ein mittelgroßes System kann innerhalb von Wochen und mit einem Aufwand von vielleicht 20 Personentagen ein großer Fortschritt und Mehrwert erzielt werden. Verglichen mit dem Aufwand für sonstige Tätigkeiten in Projekten ist dieser Aufwand oft sehr überschaubar und überaus gut angelegt. Mit einem erfahrenen Phantombildzeichner fällt der Aufwand oft sogar geringer aus, als wenn die Projektbeteiligten es selbst machen würden.

Auch in der Pflege und Aktualisierung kann ein Phantombildzeichner hilfreich sein. Oft fehlt es an klaren Verantwortlichen für die Aktualisierung von Dokumentation. Direkt in die Entwicklung involvierte Personen ziehen häufig die Karte, dass ihre Entwicklungstasks viel höhere Priorität haben als Dokumentation. Damit verschleppt sich die Aktualisierung von Dokumentation immer weiter, bis sie nahezu wertlos ist. Wenn ein Phantombildzeichner dafür die explizite Verantwortung hat, dann klappt das mit bedeutend höherer Wahrscheinlichkeit.

Sogar während der frühen Phasen einer Neuentwicklung kann es sinnvoll sein, einen Phantombildzeichner hinzuzuziehen: Damit können sich die sonstigen Teammitglieder auf andere Aufgaben fokussieren, sie bekommen aber sehr zeitnahes und direktes Feedback zu ihren Entwürfen, wenn diese durch den Phantombildzeichner dokumentiert werden sollen. Durch dieses Feedback entsteht die Chance, gleichzeitig ein leichtgewichtiges Review der Architektur zu bekommen und direkt auf Verbesserungsmöglichkeit zu reagieren und so direkt zu einer besseren Architektur mit besser passenden Konzepten zu kommen.

Fazit

Wir haben gezeigt, dass ein Phantombildzeichner für eine Softwarearchitektur in vielen Projekten und Situationen Mehrwert bringen kann. Gerade wenn die Aufgabe im Team niemand gerne macht und sie deshalb kontinuierlich vernachlässigt wird, bietet sich so die Chance in kurzer Zeit drastisch aufzuholen und den Mehrwert von sauberer Architektur und Architekturdokumentation wieder wahr werden zu lassen. So bietet sich für Personen, die das gerne und gut machen, die Chance, außerordentlichen Nutzen zu stiften. Und wenn jemand wirklich dafür zuständig und nicht zig andere auch wichtige Aufgaben hat, dann wird es auch wirklich gemacht.

Das Ergebnis mit seinem umfangreichen Nutzen und die Verlässlichkeit, dass das Ergebnis dann wirklich da sein wird, überzeugt meist auch das Management, eine sorgsam ausgewählte Person mit der Aufgabe der Architekturdokumentation zu betrauen. Diese Person wird aber in den allermeisten Fällen nicht Vollzeit und nur vorübergehend gebraucht. Dann kostet es zwar ein bisschen was, aber der Return-on-Invest ist typischerweise sehr gut.

So wird Klarheit geschaffen und häufig führt es auch dazu, dass versteckte Probleme eher zu Tage treten, weil eine weitere Person sich einfach eher traut, Unstimmigkeiten aufzudecken und zu benennen und sie nicht in der Schwammigkeit einer Dokumentation zu übertünchen. Somit bekommt man häufig noch direkt ein leichtgewichtiges Review mit, was weiteren Nutzen bietet.

Sobald eine initiale und gut strukturierte Architekturdokumentation da ist, ist häufig auch die Angst vor dem weißen Blatt Papier weg und es fällt bedeutend leichter, inkrementelle Aktualisierungen und Vervollständigungen zu machen. Außerdem verbreitet sich so das Wissen über gute Architekturdokumentation und beschränkt sich nicht auf abstrakte, verkürzte und häufig konstruierte Beispiele von Architekturtemplates. Somit hilft der Phantombildzeichner auch bei der Verbreitung und Skalierung von Architekturwissen und Dokumentationsmethodik.

In Summe der Skills lässt sich feststellen, dass die Rolle Phantombildzeichner einer Softwarearchitektur eine Rolle ist, die stark von umfangreicher und vielfältiger Erfahrung einer Person profitiert. Es ist nichts, was sich „mal schnell“ lernen lässt. Aber es lässt sich lernen und stiftet dann großen Mehrwert und dazu möchten wir ausdrücklich ermutigen! Was natürlich auch stark hilft, ist eine gewisse Freude an der beschriebenen Arbeitsweise und an der entstehenden Dokumentation. Manchmal kommt diese Freude auch einfach mit dem Können und den erzielten Erfolgen.

Wir haben die Aufgabe des Phantombildzeichners für Softwarearchitekturen schon für viele Unternehmen und Softwaresysteme unterschiedlichster Art ausgefüllt. Deshalb wollten wir in diesem Artikel andere Interessierte an den Erfahrungen teilhaben lassen, vielleicht lässt sich ja der eine oder die andere auch für diese Aufgabe begeistern.

Zu Beginn erscheint die Aufgabe oft groß und beschwerlich. Es ist aber zu schaffen und hat bisher immer geklappt. Wenn wir dann die erste vollständige Version erstellt haben, können wir uns über das Ergebnis und eine gewisse Ästhetik einer guten Architekturdokumentation erfreuen. So richtig freuen wir uns aber, wenn dann an der Erstellung unbeteiligte Personen die Dokumentation gelesen haben und sich mit Feedback melden wie „Das hätten wir schon vor Jahren so aufschreiben sollen!“, „Das habe ich vorher noch nie verstanden!“, „Ist ja eigentlich klar, dass es so sein sollte!“. Und am größten ist die Freude, wenn wir sehen, wie die Dokumentation dann aktiv genutzt wird, die Kommunikation verbessert und andere Personen beginnen, die erarbeiteten Strukturen und die Bildsprache für ihre eigene Dokumentation zu verwenden.