Softwarearchitektur ist mehr als nur Technik und Implementierung. Sie umfasst auch Abstimmung, Entscheidungsfindung, Wissensaufbau/-austausch und vor allem Teamarbeit. Wie so oft in komplexen Systemen ist das Wissen darüber vorhanden, aber leider nicht immer dort, wo man es braucht. Wo steckt es also? In den Köpfen der Teammitglieder, in verschiedenen Tools oder altmodisch auf Notizen in Blöcken, Mitschriften oder Whiteboards.
Bei pentacor arbeiten wir in mehreren Teams an verschiedenen Projekten bei unseren Kunden. Dabei treffen wir stetig technische Entscheidungen, die die Architektur unserer Systeme prägen und beeinflussen. Zunächst trifft jedes Team diese Entscheidungen für sich in seinem Kontext. Aus Architektursicht haben uns dabei Ende letzten Jahres folgende Fragen beschäftigt: Wie machen wir diese Entscheidungen auch über die Teamgrenzen hinweg sichtbar? Wie schaffen wir einen strukturierten, aber alltagstauglichen Überblick darüber, wie wir Architektur leben? Und wie kann die gesamte Firma davon profitieren?
Die Antwort: Wir nutzen ein Canvas. Da es kein passendes gab, das wir 1:1 nutzen konnten, haben wir uns kurzerhand selbst eines erstellt.
Gibt es das nicht schon?
Die Idee für ein Canvas kam auf, da wir in unseren Projekten bereits jetzt Canvases für verschiedene Themen verwenden. Zu Beginn haben wir uns daher mit bestehenden Formaten wie dem Architecture Inception Canvas (AIC), dem Architecture Communication Canvas (ACC) und einzelnen Elementen des arc42-Modells beschäftigt. Alle bieten wertvolle Perspektiven – etwa auf Business-Ziele, funktionale Anforderungen, Systemumgebungen oder Risiken.
Aber uns fehlte etwas.
Ein Format, das weniger auf das Was und Womit, sondern mehr auf das Wie und Warum eingeht. Ein Format, das nicht nur dokumentiert, was wir gebaut haben, sondern auch wie wir dahin gekommen sind und was wir auf dem Weg dahin gelernt haben. Und das auch das Erfahrungswissen im Team gezielt einbezieht.
Das p-Architecture Knowledge Canvas
Es ist ein bewusst einfach gehaltenes Canvas entstanden, das aber Grundlage für tiefere Diskussionen bieten kann. Es kann in einem etwa zweistündigen Workshop gemeinsam mit Entwickler*innen, Product Ownern, dem Agile Coach und – sofern es diese gibt – Solution-Architekt*innen ausgefüllt werden. Wir beziehen nicht nur die Entwickler*innen, sondern auch diejenigen mit ein, die Fachwissen einbringen oder die agilen Prozesse beeinflussen. Denn auch hier liegen wertvolle Erfahrungen in den einzelnen Teams.
Außerdem lebt das Canvas davon, dass man es iterativ weiterführt. Denn Entscheidungen, die zu einem früheren Zeitpunkt getroffen wurden, können sich später eventuell als sehr gut oder auch als „daneben gegriffen“ erweisen.
Ähnlich dem AIC und ACC besteht das Canvas aus drei Bereichen und zugehörigen Feldern.
Prerequisites
Jedes Projekt hat einen Zweck sowie Vorbedingungen und Regeln, die eingehalten werden müssen. Der Punkt „Quality Goals” wird meist vernachlässigt bzw. ist nicht festgehalten und führt auch bei uns regelmäßig zu Diskussionen. Hier sollte investiert und aktiv diskutiert werden, da alle wesentlichen Entscheidungen immer durch die Qualität getrieben sein sollten.
- Business Case & Goals: Was ist der Zweck der Software? Welche Anforderungen treiben uns an?
- Quality Goals: Welche Qualitäten sind uns wichtig? Was steht über allem: Sicherheit? Performance? Erweiterbarkeit?
- Constraints: Was setzt uns Grenzen? Zeit, Budget, Tools oder rechtliche Rahmenbedingungen?
Solution & Communication
Wie wir kommunizieren und Wissen teilen, um damit jeden im Team zu befähigen, Entscheidungen mitzudiskutieren und zu treffen, ist genauso wichtig wie die eigentliche Lösung. Daher bilden diese Themen den Kern des Canvas.
- Knowledge Sharing Approaches: Wie verteilen wir Wissen im Team? Hier ist neben dem technischen Wissen vor allem auch die Fachlichkeit relevant.
- Architectural Approach / Solution Strategy: Welchen Lösungsideen, Prinzipien und Mustern folgen wir? Was ist unser architektonischer Kern? Was haben wir umgesetzt?
- Technologies: Welche Technologien nutzen wir – in welchen Bereichen sind wir Experten und in welchen Bereichen experimentieren wir?
Reason & Learnings
Der finale Abschnitt enthält die gesammelten Erfahrungen und betrachtet sowohl Entscheidungen als auch die Weitergabe von Erkenntnissen.
- Decisions (Good & Bad): Was hat funktioniert? Was nicht? Was würden wir wieder genauso tun – oder nicht mehr auf diese Weise? Die Antworten sind bewusst getrennt nach Methoden, Architektur und Technologien.
- Learnings & Insights: Was nehmen wir mit? Was können wir in neuen Projekten von Anfang an besser machen? Was raten wir anderen Teams?
Einige Felder findet man in ähnlicher Form auch im AIC oder ACC, oder sie sind angelehnt an arc42. Andere ergänzen bewusst neue Perspektiven. Uns ist besonders wichtig, dass es nicht um eine vollständige Dokumentation geht. Sondern um Orientierung, Reflexion und Dialog.
Und was bringt das?
Das Canvas hilft einem einzelnen Team, sich aktiv mit der Architektur auseinanderzusetzen. Es macht transparent, wie wir die Architektur gedacht und umgesetzt haben. Es macht getroffene Entscheidungen – ob gut oder schlecht – explizit. Es hilft, Lücken zu erkennen, Klarheit zu schaffen und besser zu kommunizieren.
Das Wichtigste dabei ist, dass eine Grundlage entsteht, auf der wir künftige Entscheidungen bewusster und fundierter treffen können. Zudem können wir unsere Architektur so erklären, dass auch andere sie verstehen – intern wie extern, technisch wie organisatorisch.
Zwischen Teams ermöglicht es einen schnellen und einfachen Überblick über die Aktivitäten der anderen. Man sieht, wer welche Technologie einsetzt und wer welche Entscheidung positiv sieht. So weiß man, an wen man sich bei konkreten Fragen zu Technik oder Kommunikationsmethoden wenden kann. Auch das Wissen darum, welche Qualitätsanforderungen zu welchen Lösungen geführt haben, lässt sich sichtbar machen.
Dinge, die wir gelernt haben
Inzwischen haben wir das Canvas in mehreren Projekten mit Teams zwischen drei und acht Personen in unterschiedlichen Kunden-Settings eingesetzt. Dabei zeigte sich: Die Diskussionen über Qualitäten, Wissensaustausch oder Architekturansätze waren stets äußerst wertvoll. Es gab sogar Meinungen, dass die Diskussionen wertvoller waren als die ausgefüllten Felder an sich.
- Ein gutes Architektur-Canvas stellt die richtigen Fragen und ermöglicht offene Diskussionen. Beim Ausfüllen geht es nicht um Vollständigkeit, sondern um Relevanz. Diskutiert und sprecht über alles. Vor allem in Teams, in denen es häufiger personelle Wechsel gibt, wissen die „alten Hasen“ oft sehr viel, was nicht direkt dokumentiert ist, für die neueren Teammitglieder aber wichtig sein kann.
- Nicht alles muss ins Canvas. Wichtig ist, dass die Gespräche stattfinden. Das Canvas ist ein Katalysator, kein Archiv. Es soll eine Kurzdokumentation sein, die als Einstieg in eine tiefere Beschreibung dient.
- Architektur ist auch ein soziales System. Wer nur auf Komponenten, Technologien und technische Aspekte schaut, verpasst die eigentlichen Hebel für eine gute Softwarearchitektur.
Willst du es mal ausprobieren?
Das Canvas ist offen gestaltet. Wenn du Lust hast, es in deinem Projekt einzusetzen, dann mach das gerne. Wir freuen uns über Feedback, Erfahrungen und Anpassungen.
Vielleicht hilft es euch, Klarheit zu gewinnen, Muster zu erkennen oder das Gespräch über Architektur anzustoßen oder zu verbessern.
Denn eins ist klar: Gute Architektur entsteht nicht durch Zufall, sondern durch aktive Auseinandersetzung, Diskussion und natürlich (wenn auch in angemessener Kürze) Dokumentation, um das Erarbeitete wiederzufinden.
Download: p-Architecture Knowledge Canvas
