This blog post is also available in English
Der Ansatz, auf kleinstem Raum nützliche Informationen zu einem spezifischen Thema zu sammeln, hat mit dem „Business Model Canvas“ (BMC) Aufsehen erregt. Das Buch dazu wurde millionenfach verkauft und gilt als Klassiker für moderne Unternehmen und Startups. Einen Grund für diesen Erfolg sehen wir in der Reduktion auf ein absolutes Minimum an Informationen: Der BMC lässt einfach keinen Platz für ausführliche oder ausufernde Dokumentation. Sie müssen sich auf die wesentlichen Dinge konzentrieren.
Seit dem BMC im Jahre 2010 sind eine Reihe weiterer Canvas-Modelle hinzugekommen, etwa der „Lean UX Canvas“, der „Product Design Canvas“, oder der für Fans von Domain-driven Design hilfreiche „Bounded Context Canvas“ (siehe unten).
Was ist überhaupt ein Canvas?
Diese Frage haben wir ChatGPG gestellt, und folgende Antwort erhalten:
In der Softwareentwicklung bezieht sich ein Canvas in der Regel auf einen visuellen Container, in dem Benutzer interagieren und Elemente manipulieren können, um Inhalte zu erstellen oder zu ändern.
Diese Erklärung ist zwar korrekt, bezieht sich aber eher auf UI-Frameworks (wie Tkinter, wxPython, HTML5, Java2D, JavaFX oder WPF), die einen canvas als Zeichenfläche verwenden.
In unserem Kontext besitzt das Wort „Canvas“ eine etwas andere Bedeutung:
Ein Canvas ist eine strukturierte Visualisierung, die Verständnis und Analyse von Schlüsselelementen bestimmter Themen erleichtert.
Alles klar, oder? Da wir Kürze lieben, hier diese Definition mal in vereinfacht:
Canvas: geordnete Darstellung von Schlüsselelementen.
Es geht also um wichtige Informationen (aka „Schlüsselelemente“) zu einem Thema. Das können Geschäftsmodelle sein, wie beim Business Model Canvas, oder eben wichtige Informationen zu einem Softwaresystem.
Die Konzentration auf wesentliche Elemente kennen wir auch als Abstraktion oder Modellbildung – also dem Weglassen unwesentlicher Details. Solche Modelle dienen einem konkreten Zweck, und welche Elemente ein Modell jeweils hervorhebt, hängt genau von diesem Zweck ab.
Vorgänger: Steckbrief
Die Idee solcher Verkürzung haben sich schon frühere Generationen zunutze gemacht, und so genannte Steckbriefe verfasst. Ursprünglich dienten die dazu, eines Verbrechens verdächtige Personen zu finden. Heute nutzen wir Steckbriefe als Zusammenfassung wesentlicher Fakten.
Aber zurück zu Software und IT. Dort können Sie den Canvas für technische Dokumentation verwenden.
Dafür gibt’s doch arc42?!
Klar, Sie können auch das arc42-Template hochgradig sparsam einsetzen. Aber in der Praxis kommt arc42 immer noch als ein Dokument oder Wiki daher – was manchen Teams oder Menschen zu viel oder zu umständlich erscheint.
Wir haben in der Praxis häufiger den Ruf nach „noch kürzer“ gehört, und mit verschiedenen Teams aus unterschiedlichen Branchen an immer kompakteren Versionen von Dokumentation gearbeitet. Lange Zeit haben wir die Ergebnisse allerdings in der (klassischen) Form als Template abgelegt. Das funktioniert an sich gut – aber hat eben nicht den Steckbriefcharakter, den ein Canvas mit sich bringt.
Was diese Disziplinen können, schaffen wir in der Softwarearchitektur auch: In super-kompakter Form die wesentlichen Highlights eines Systems in strukturierter Form darzustellen – mit dem Architecture Communication Canvas.
In typischer arc42-Manier steht dieser Canvas unter einer liberalen Open-Source-Lizenz, d.h. Sie dürfen ihn auch im kommerziellen/beruflichen Umfeld verwenden. Canvas und Dokumentation sowie die zugehörige Website https://canvas.arc42.org werden in einem öffentlichen Github-Repository gepflegt.
Schlüsselelemente von IT-Systemen
Um die wesentlichen inneren Details von IT-Systemen wirklich zu verstehen, benötigen wir Antworten auf drei Kernfragen:
- Welche Aufgabe löst das System? Anders gefragt: Was sind die Anforderungen?
- Wie sieht die Lösung aus? Anders gefragt: Was sind die wesentlichen Aspekte der Architektur?
- Welche Probleme gibt es?
Wenn wir diese drei Fragen etwas spezifischer formulieren, gelangen wir zu folgender Liste von Schlüsselelementen, über die wir Bescheid wissen müssen:
- Was ist der Business-Case dieses Systems? Warum gibt es dieses System?
- Was sind die wesentlichen Fähigkeiten oder Funktionen dieses Systems?
- Was sind die wesentlichen Qualitätsanforderungen an das System, etwa Skalierbarkeit, Sicherheit, Zuverlässigkeit, oder Benutzungsfreundlichkeit?
- Wer sind die wesentlichen Stakeholder?
- In welchem Umfeld existiert unser System?
- Was sind die wichtigsten/prägnantesten Entscheidungen, die getroffen wurden – gute wie schlechte?
- Was sind die wesentlichen Bestandteile (aka Komponenten, Bausteine, Module) des Systems?
- Was sind die wesentlichen Technologien?
- Was sind die wesentlichen Risiken und Probleme?
All diese Informationen finden Sie auch im bekannten arc42-Template, aber manchmal benötigen Sie einfach eine kompakte Fassung. Genau da kommt der Canvas ins Spiel.
Platz für Anforderungen und Lösung
Der Canvas bietet Raum für die Antworten auf die drei oben genannten Kernfragen (Anforderungen hier mit grünlichem Hintergrud, Lösung mit blauem Hintergrund, Probleme mit rotem Hintergrund)
Der Business Context bildet den Übergang von Anforderungen zur Lösung, darum verläuft dieser Teil von grün nach blau.
Beispiele statt Details
An dieser Stelle möchten wir den Canvas lediglich kurz vorstellen, ohne auf die detaillierte Bedeutung der einzelnen Elemente einzugehen. Die können Sie bei Bedarf in der Online-Dokumentation nachlesen. Weiter unten finden Sie den Canvas als Diagramm und auch ein paar Download-Links, mit denen Sie direkt loslegen können.
Zwei Beispiele möchten wir Ihnen auf jeden Fall zeigen, damit Sie den Architecture Communication Canvas mal in „fertig“ erleben können.
Massenmarkt-CRM (MaMa CRM)
Das folgende Beispiel zeigt den Canvas für die Software MaMa CRM, die von Gernot Starke begleitet und ausführlich sowie nach arc42-Template in arc42 by Example beschrieben wurde.
Gehaltssoftware (gehalt.io)
Dieses Beispiel zeigt den Canvas für die Software „gehalt.io“, die INNOQ-intern von Benjamin Wolf und einigen Kollegen entwickelt wurde.
Erfahrungsberichte und Anwendungsgebiete, oder: Wozu das Ganze?
Vielleicht fragen Sie sich, wozu Sie einen Canvas überhaupt einsetzen können, was also vernünftige Anwendungsgebiete sein könnten. Wir haben den Canvas bereits in verschiedenen Projekten für Folgendes eingesetzt:
- Als Keimzelle oder Ausgangspunkt weiterer Dokumentation. Insbesondere in Fällen, wo zu bestehenden Systemen jegliche systematische Dokumentation gefehlt hat. Der Canvas hat dabei geholfen, das blank paper syndrome zu vermeiden, und dem Entwicklungsteam ein schnelles Erfolgserlebnis zu verschaffen.
- Als Notlösung, wenn das Team wirklich (!!) keine Zeit hat, weitere oder detaillierte Dokumentation zu erstellen. Wenn es wirklich keinen anderen Ausweg gibt.
- Als Ausgangspunkt für Reviews oder Bestandsaufnahmen: Ich habe hier und dort darüber geschrieben. Ein Canvas ist dafür ein großartiger Start, der allen Beteiligten eine gemeinsame Kommunikationsbasis liefert.
- Als Einstieg in das Thema Architekturdokumentation, wenn bei Teilnehmenden kein oder nur wenig Wissen diesbezüglich vorhanden ist.
Unabhängig von den Anwendungsfällen haben wir immer wieder folgende Erfahrungen gemacht:
- Innerhalb einer Stunde entsteht ein Stück Dokumentation, das echten Wert liefert.
- Das gemeinsame (einer von uns und 1-n Personen aus dem Projekt) Beantworten der einzelnen Bereiche auf dem Canvas führt zu Aha-Momenten, fördert vergessen-geglaubte Informationen zu Tage und zeigt, dass Dokumentation Spaß machen kann.
- Das Dokumentieren eines Systems mit dem Canvas ist ein hervorragender Einstieg in die Dokumentation von Softwarearchitekturen, wenn man damit noch keine oder nur wenig Erfahrung hat. Ein positiver erster Berührungspunkt mit dem Thema Architekturdokumentation ist nicht zu unterschätzen.
Noch am Anfang?
Falls Sie bisher nur wenige Architekturentscheidungen getroffen haben, sich also noch in der Findungs- oder Planungsphase für ein System befinden, kann Ihnen der Architecture Inception Canvas helfen – ebenfalls unter https://canvas.arc42.org verfügbar. Dieser fokussiert auf neue IT-Systeme und enthält im Wesentlichen Anforderungen.
Mehr Technik?
Falls Sie mehr über die verwendete Technologie oder das Technologie-Portfolio Ihres Systems zusammentragen möchten, empfehlen wir Ihnen den TechStack Canvas. Unbedingt mal anschauen, das ist eine prima Ergänzung zum hier gezeigten Architecture Communication Canvas.
Und nun: Wie erstelle ich einen Canvas?
Wir haben es als großartiges Teamwork erlebt, den Canvas für ein System gemeinsam in einer Gruppe motivierter und kundiger Menschen zu erstellen. Das funktioniert sehr low tech, mit einem Flipchart, ein paar Stiften und Sticky-Notes: Hängen Sie ein leeres Flipchart-Blatt mit der rein weißen Seite nach oben im Querformat an die Wand. Übertragen Sie grob die einzelnen Segmente des Canvas auf dieses Blatt und beschriften Sie diese entsprechend. Schon kann’s losgehen: Beginnen Sie oben links, mit den Business-Zielen des Systems. Die anderen Segmente befüllen Sie in beliebiger Reihenfolge.
Falls Sie lieber elektronisch oder online arbeiten, gibt’s den Canvas aktuell in folgenden Formaten:
- als Template für Miro® (miro template, rtb-Format)
- als Vorlage für draw.io/diagrams.net (drawio-Vorlage)
- als PDF
Fazit
Worauf warten Sie noch? Mal schnell zum Stift (oder Zeichenwerkzeug) gegriffen und ein paar Stichworte zu Ihrem System zum Canvas gebracht. Erfolgserlebnis (fast) garantiert. Falls Sie Ihren Canvas der Öffentlichkeit zugänglich machen wollen: Erstellen Sie einen Pull-Request im Canvas-Repository.
Danksagung
Danke an Patrick Roos für aktive Mitarbeit, Jörg Müller, Peter Hruschka und einige unserer Kunden für Feedback zum Canvas. Und natürlich an Lucky, die beste Maine-Coon dieser Welt!
Und wenn Sie den Canvas lieber in den INNOQ-typischen Farben genießen möchten, dann können wir Ihnen auch hier weiterhelfen (Bild anklicken, um zur hochauflösenden Version zu gelangen):
