Sieben Pfeile auf einem Whiteboard, keiner zeigt mehr in eine nachvollziehbare Richtung. Genau darüber bekomme ich die meisten Fragen - von Leuten, die nach dem dritten Architektur-Review aufgeben und wissen wollen, wie man Software-Architektur so zeichnet, dass sie im Meeting tatsächlich ankommt. Seit dem Sketchnotes-Kurs sammeln sich diese Fragen im Postfach - von Kolleg:innen aus dem Product Management genauso wie von Leuten, die mit visueller Kommunikation und Team-Collaboration in ganz anderen Branchen kämpfen. Die kurze Antwort auf fast alle davon: Man braucht kein Talent. Man braucht ein System.
Reicht ein Whiteboard-Marker gegen UML?
Es gibt die Unified Modeling Language für alle, die es formal korrekt wollen. Präzise, genormt - und in einem Stakeholder-Review ungefähr so beliebt wie eine Steuererklärung. Sobald ein sauberes Sequenzdiagramm auf dem Bildschirm steht, klinken sich die Leute aus, die keine Informatik studiert haben. Das Problem ist eigentlich nicht die fehlende Präzision im Raum - das Problem ist, dass Präzision und Verständlichkeit in diesem Moment zwei verschiedene Ziele sind.
Ein Marker reicht.
Unser Konferenzraum in der HafenCity hat ein Whiteboard, an dem inzwischen mehr korrigiert als neu gezeichnet wird. Ein UML-Tool mit Exportfunktion braucht in diesem Moment niemand.
Muss ich zeichnen können, um eine Systemlandschaft verständlich zu machen?
Nein. Ein Quadrat, ein Kreis, eine Linie mit Pfeilspitze - mehr Repertoire braucht eine erste Skizze nicht, den Rest ergibt sich beim Zeichnen selbst. Wer IT-Infrastruktur visualisieren lernen will, sollte sich genau davon zuerst freimachen: von der Vorstellung, dass eine Zeichnung fertig und schön aussehen muss, bevor sie ins Meeting darf.
Meine Kollegin Gisa Pranger, UX Lead im Nachbarbereich, zweifelt laut an jedem neuen Tool, bevor sie ihm eine Chance gibt. Bei den ersten Architektur-Skizzen war das nicht anders - sie hat im Refinement gefragt, ob wir jetzt Kunstunterricht statt Backlog-Pflege machen. Inzwischen zeichnet sie halt selbst mit, weil das schneller ging, als ihre Einwände in Worte zu fassen.
Warum Tabellen und Textprotokolle bei Software-Architektur scheitern
Vor dem Umstieg hatte ich eine Google-Docs-Tabelle als Protokollvorlage für Architektur-Meetings. Eine Spalte pro Komponente, eine Zeile pro Entscheidung. Nach dem dritten Meeting war sie unleserlich - zu viele Zellen, zu viele Abkürzungen, die nur im Moment der Eintragung Sinn ergaben. Niemand hat sie zwischen zwei Terminen noch geöffnet.
Text-Protokolle scannt man nicht. Man muss sie lesen, Zeile für Zeile, und genau dafür fehlt im vollen Kalender die Zeit. Eine Skizze dagegen erfasst man auf einen Blick - welche Boxen verbunden sind, wo ein Pfeil fehlt, welcher Teil noch offen ist.
Unordentliche Skizzen schlagen fertige Diagramme
Der wichtigste Unterschied zwischen einer Präsentationsfolie und einer Live-Skizze: Eine fertige Grafik wirkt abgeschlossen. Niemand traut sich, ein fertiges Bild zu kritisieren. Eine schiefe, unfertige Zeichnung dagegen ist eine Einladung. Sobald ein Pfeil in die falsche Richtung zeigt oder eine Box ohne Beschriftung bleibt, meldet sich das Team von selbst.
Mein Pfeilcode für synchrone und asynchrone Aufrufe war beim nächsten Blick in die Notizen sofort wieder lesbar, ohne dass ich mich erinnern musste, was ich mir dabei gedacht hatte. Genau das ist der Test, den eine gute Notation bestehen muss - nicht ob sie im Moment des Zeichnens Sinn ergibt, sondern ob sie es später noch tut.
Skepsis im Team abbauen
Ein Systemarchitekt hat mir mal über die Schulter geschaut, während ich eine Datenbank als schiefen Zylinder gezeichnet habe, und nichts gesagt. Erst als ich die Verbindung zum Cache-Layer falsch eingezeichnet hatte, kam der Einwand - und genau die Korrektur, die ich brauchte. Bilder bleiben im Kopf, Fließtext irgendwie nicht. Das ist meine punktuelle Beobachtung aus echten Meetings, kein Forschungsergebnis.
Für den Nutzer eine Farbe, für Daten eine andere, für externe Systeme eine dritte - mehr Farbcode braucht ein Architektur-Sketch selten. Für den Verbindungstyp, synchron oder asynchron, nutze ich inzwischen einfache Symbole für Softwareentwicklung, damit ein Pfeil nicht nur eine Linie ist, sondern eine Aussage.
Funktioniert das auch außerhalb vom Produktteam?
Eine Leserin hat mir geschrieben und gefragt, ob sich das auf Kundenprojekte übertragen lässt. Sina Gottwald, Unternehmensberaterin ohne Zeichenhintergrund, vergleicht in ihrer Mail jede Technik erstmal mit Post-it-Methoden - berechtigt, denn beides löst ein ähnliches Problem: Wissen bleibt im Kopf einzelner Personen hängen, statt sichtbar zu werden. Der Unterschied: Post-its lassen sich nicht verbinden. Eine Architektur besteht aber genau aus Verbindungen.
An anderer Stelle habe ich schon aufgeschrieben, warum Vorteile von Sketchnotes im Business den PM Alltag im SaaS erleichtern können. Für Beratungsprojekte gilt dieselbe Logik, nur mit anderen Stakeholdern am Tisch.
Wo die Methode an Grenzen stößt
Bei einer Systemlandschaft mit weit über zwanzig Services wird ein A4-Blatt zu klein, und die Übersicht kippt zurück ins Chaos, das ich eigentlich vermeiden wollte. Für so einen Umfang braucht es entweder mehrere Skizzen mit klaren Schnittstellen zueinander oder ein Werkzeug, das zoomen kann - eine Handskizze allein reicht dann nicht mehr.
Und in einem Remote-Call mit schlechter Kamera nützt die schönste Live-Zeichnung wenig, wenn niemand erkennt, was auf dem Papier passiert. Für diesen Fall schicke ich lieber, am Schreibtisch in der Eimsbütteler Altbauwohnung, Monitor links im Blick und Notizbuch griffbereit rechts von der Maus, eine E-Mail mit einem abfotografierten Ergebnis, statt live gegen eine wackelige Verbindung zu zeichnen. Die Methode ersetzt kein Diagramm-Tool für hundert Microservices. Sie ersetzt die Situation, in der zwölf Leute in einem Raum sitzen und trotzdem aneinander vorbeireden.