Architecture Communication Canvas

Sven: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute zur Architecture Communication Canvas mit Ben.

Ben: Hallo.

Sven: Hallo, Ben. Ben, wer bist du? Und was machst du bei INNOQ?

Ben: Ich bin Ben, seit 2017 bei INNOQ als Senior Consultant und Coffee Consultant. Meine Schwerpunkte sind Beratung im Bereich Software Architektur, Architektur Dokumentation und Software Qualität.

Sven: Architektur Dokumentation ist sozusagen heute unser Thema. Der Podcaster Tim Ferris, der ein bisschen berühmter ist als wir und ein paar Downloads mehr hat, hat mal seine Gäste immer gefragt: Was ist eigentlich der wertvollste Kauf unter 50€, den ihr die letzten fünf Jahre gemacht habt? Und ich muss sagen das wertvollste Tool für kleinen Pfennig, was ich die letzten Jahre gesehen habe, ist tatsächlich die Architecture Communication Canvas. Ich bin schwer begeistert und ich bringe es immer so unters Volk bei Schulungen. Und ich muss sagen, da sind die Leute eigentlich auch immer begeistert. Also good job. Jetzt ist die Frage: Was ist überhaupt dieser Architecture Communication Canvas? Bzw. wo kommt er überhaupt her? Vielleicht fangen wir damit an.

Ben: Da kann ich gern einmal einsteigen, wo das herkommt. Gernot und ich haben, oder vielleicht ging es dir genauso, in Projekten immer wieder gehört, dass arc42 als Template eigentlich ganz nett ist, aber da muss man irgendwie immer noch so viel schreiben, man muss so viel Aufwand reinstecken und irgendwie hat man gar keine Zeit dazu, bekommt die Zeit im Sprint nicht zu dokumentieren und es muss doch irgendwas geben, dass es noch schneller geht. Dann haben wir angefangen und haben gesagt: Na gut, dann füllt nur sechs Kapitel von diesem Template aus, so die wichtigsten. Und dann hieß es; Ja, ist schon ganz cool, aber es hat immer noch sehr viel, was wir da schreiben müssen. Geht’s nicht noch besser? Dann haben wir uns Ende letzten Jahres zusammengesetzt und haben überlegt, was wir machen können. Und kamen dann auf die Idee so einen Canvas mal auszuprobieren, haben so ein paar Schlüsselfragen gehabt, an denen wir uns entlang gehangelt haben und haben dann eben diesen Canvas gebaut.

Sven: Was ist ein Canvas?

Ben: Gute Frage. Canvas in unserem Kontext ist einfach eine strukturierte Visualisierung von verschiedenen Informationen, damit ich Leuten den Einstieg in gewisse Themen einfach erleichtern kann. Nicht gemeint ist Canvas, so wie wir es aus der Technik kennen, dass es eine Fläche ist, auf der wir zeichnen.

Sven: Es gibt auch berühmte Canvas. Domain-driven design hat doch auch den Context Canvas.

Ben: Bounded Context Canvas.

Sven: Genau, war eine Context Canvas und es gibt den Value Proposition, Canvas aus dem Lean Startup Umfeld. Ein Canvas Steckbrief früher, kurz und knapp.

Ben: Genau.

Sven: Genau. arc42 ist eine gute Sache. Aber den Leuten die haben es nicht geschafft, das zu dokumentieren. Was sind denn die Anwendungsfälle? Von dem Architecture Communication Canvas?

Ben: Effektiv, dass ich mein System dokumentieren kann, und zwar möglichst schnell. Das kann sein, ich habe ein System, das schon länger lebt und wir wollen es modernisieren, haben aber keine Dokumentation. Dann können wir den Canvas schon mal nutzen, um zumindest einen groben Überblick über das System zu bekommen. Oder aber wenn wir eigentlich gerne arc-42 nutzen wollen, aber irgendwie gar nicht wissen, wie wir anfangen sollen, das auszufüllen.

Sven: Aber es ist kein Ersatz für arc-42. Du würdest eher sagen, das ist eine Begleitung.

Ben: Ich würde sagen, es ist eine Ergänzung. Man kann es nutzen, wenn man noch gar nichts hat, quasi als Einstieg und dann basierend auf dem Canvas anfangen, eine arc-42 Doku abzuleiten. Vielleicht habe ich auch wirklich aus verschiedenen Gründen gar nicht die Zeit, eine ausführliche Dokumentation zu schreiben. Aber dann habe ich trotzdem zumindest die wichtigsten Infos zusammen auf einem Stück Papier. Und wenn irgendjemand neu ins Team kommt oder jemand von einem anderen Team eine Frage hat, dann kann ich einfach sagen: Hier ist unsere Canvas. Das ist unser System und die wichtigsten Aspekte stehen da drauf. Und das ist so viel mehr wert, als einfach überhaupt gar keine Doku zu haben.

Sven: Ich denke, so für mich, ich hatte in der Vergangenheit immer mal wieder das Problem, dass wir eine sehr ausführliche arc-42 Dokumentation haben tatsächlich. Aber dann gibt es Leute, die kommen neu ins Projekt. Oder du hast Dienstleister, die ongeboarded werden. Und die wollen so einen Systemüberblick haben. Und da ist es immer blöd. Dann kannst du sagen: Lese dir mal arc-42 vor. Dann sagen die Leute immer zu mir: Stell mir die Architektur vor, du hast x Minuten Zeit, so ungefähr. Und da kommt man schon, ich würde sagen, natürlich zu dieser Canvas. Jetzt ist es so die Zuhörer, wir reden die ganze Zeit davon. Vielleicht wollen wir mal versuchen, so ein bisschen zu visualisieren, aber dass wir vielleicht auch mal so auf die konkreten Inhalte eingehen. Es gibt auch einen Haufen Beispiele auf eurer Website, das verlinken wir alles. Da kann man mal draufgucken. Wenn man es sieht, bekommt man einen besseren Überblick. Aber im Grunde genommen kann man sagen: Das ist so eine DinA4 Seite, wo die in unterschiedliche Teile aufgeteilt ist.

Ben: Ich würde sagen, vielleicht lieber die DinA3, dann hat man ein bisschen mehr Platz. Aber das ist richtig. Insgesamt sind es neun Bereiche, die auf dem Canvas abgebildet sind. Und man kann sich so vorstellen: Auf der linken Seite sind all die Bereiche, die sich mit dem Thema Anforderungen, Qualitätsanforderungen, Stakeholder Business Context befassen. Auf der rechten Seite sind dann die ganzen technischen Entscheidungen, Technologien, die wir einsetzen. Und dann haben wir noch ein zusätzliches Feld, wo wir Risiken mit unserer aktuellen Lösungen und unserem aktuellen System eintragen können. Aber auch zum Beispiel Information, die uns einfach fehlt und irgendwie verhindert, dass wir zum Beispiel weiterentwickeln können und das System besser machen kann.

Sven: Zu dem Teil Anforderungen. Ich würde vielleicht einfach mal ganz kurz diese neuen Punkte durchgehen in aller Kürze. Bei den Anforderungen, da geht es los mit der Value Proposition. Was ist das? Was kommt da rein?

Ben: Da war quasi unser Hintergedanke, dass wenn man in der Lage sein sollte, den Business Wert des Systems in der Länge eines Tweets wie er früher war, 140 Zeichen ungefähr. Da muss ich mich nämlich konzentrieren, wirklich prägnant zu schreiben und nur das zu schreiben, was tatsächlich der Mehrwert meines Systems ist, ohne dass ich da irgendwie ausschweifend zusätzliche Sachen mit dazu schreibe, die eigentlich gar nichts bringen.

Sven: Ich weiß nicht, ob sie gar nichts bringen, aber ich muss sagen, wenn man die Beispiele, die wir verlinken sieht, dann denke ich auch immer: Ah, genau. Einmal drauf geguckt und du siehst es. Der nächste Punkt sind die Stakeholder.

Ben: Ja, das ist ähnlich wie auch in einem arc-42 Dokument. Da habe ich eine Reihe von meinen wichtigsten Stakeholdern aufgelistet, einfach damit ich weiß, wer hat denn irgendwie Einfluss auf mein System? Wer benutzt mein System? Oder welche anderen Systeme benutzen wir? Um das schon mal klarzustellen: Alle die solltest du im Auge behalten. Entweder wenn du dein System änderst oder aber falls von diesen Personen oder Organisationen eventuell auch Änderungen dich betreffen.

Sven: Gibt es da irgendwie so eine Beschränkungen, wo du sagst, die wichtigsten drei oder die wichtigsten fünf?

Ben: Ich würde da auf die Beraterantwort „Es kommt drauf an“ zurückgreifen. Manchmal habe ich vielleicht nur zwei, wenn es nur eine kleine Anwendung ist. Manchmal habe ich vielleicht sogar sieben, acht oder neun. Da muss ich dann einfach abwägen: Ist es wirklich wichtig und bringt es was, wenn ich jemandem diese Information zur Verfügung stelle oder es ist mehr so intern, für mein Dev Team vielleicht wichtig, aber für den Überblick halt noch nicht? Also ich würde sagen, 3 bis 5 klingt schon mal ganz gut. Manchmal sind es vielleicht ein bisschen mehr, manchmal ein bisschen weniger.

Sven: Dann hätten wir die wichtigsten Funktionalitäten. Gewissermaßen selbsterklärend, aber vielleicht kann es trotzdem noch ein Ansatz sein.

Ben: Genau. Wir haben in diesem Feld für die Value Proposition haben wir nur kurz Platz, um zu sagen: Das kann unser System, das ist der Mehrwert davon. Und hier bei diesem Core Functions habe ich dann die Möglichkeit, noch mal ein bisschen detaillierter darauf einzugehen, was denn so die einzelnen Teilbereiche oder Teilfunktionen meines Systems sind, die es mitbringt.

Sven: Bei so einem Webshop, dass man sagt: Suchen, Finden und Kaufen von Produkten zum Beispiel. Das finde ich auch nicht schlecht, dass man wirklich sagt, das fehlt mir manchmal so ein bisschen. Was sind eigentlich die wichtigsten Dinge? Dann kriegt man irgendwie 100 Funktionalitäten an den Kopf. Aber mich interessiert eigentlich: Was ist das Wichtigste für das System? Genau, dann eine meiner Lieblingssektionen, die Qualitätsziele.

Ben: Ja, genau. Bei den Qualitätszielen wollen wir, dass nur die wichtigsten drei, aber wenn es mindestens drei gibt, drin stehen. Dass man sich wirklich mal Gedanken machen muss: Wie priorisieren wir das? Falls es nicht eh schon passiert ist. Vielleicht mache ich mir dann auch erst mal Gedanken: was sind eigentlich unsere Qualitätsziele? Dann muss ich erst mal mit Menschen sprechen um die rauszufinden. Aber da kann ich die dann eben reinschreiben. Und das könnte ich mal nach ISO Taxonomie machen, dass ich irgendwie Dinge wie Wartbarkeit, Sicherheit, Zuverlässigkeit reinschreibe. Ich kann das aber auch ganz konkret machen, dass ich zum Beispiel sage: Ich habe eine strikte Datentrennung von unterschiedlichen Mandanten. Das ist eine meiner Hauptqualitätsanforderungen, dass sie nicht vermischt werden können. Oder kann da auch schon konkretisieren, dass die zweite Anforderung ist, dass alle Anfragen innerhalb von zwei Sekunden beantwortet werden, zum Beispiel. Da kann ich wirklich sehr konkret werden, kann es aber auch sehr abstrakt halten.

Sven: Ich muss sagen, dass ihr habt Beispiele genannt. Ihr habt Beispiel Canvas dabei, auch von existierenden Systemen. Und da sieht man es eigentlich ganz gut. Und ich muss sagen, ich bin ein großer Freund von diesen konkreten Qualitätszielen. Wie du gesagt hast, strikte Trennung von Mandanten. Dann hat man noch ein bisschen besser so ein Gefühl: Was bedeutet das eigentlich? Security, Wartbarkeit ist immer so ein bisschen abstrakt. Und wenn bei Wartbarkeit irgendwie so steht: Neue Tarifgenerationen sollen schnell hinzugefügt werden, also ein bisschen konkreter. Und ich finde, Qualitätsziele sind immer so ein bisschen problematisch in Projekten, weil es einfach so schwer greifbar ist manchmal und das finde ich, macht diese ACC Beispiele, die machen das wirklich gut, dass die einem noch mal so in aller Kürze zeigen: Was wollen wir damit erreichen? Ziemlich cool auf jeden Fall. Der letzte Punkt, der ist wahrscheinlich den meisten arc-42 Leuten auch bekannt, der Business Context.

Ben: Genau, das ist wirklich einfach das Gleiche. Das ist ein Diagramm, das unser System zeigt und um Systeme oder Personen, die mit unserem System interagieren. So ähnlich, wie wir es aus arc-42 Doku auch kennen. Dass hübscht das Ganze immer ein bisschen auf, weil dann auch so ein Diagramm noch mit dabei ist. Und weil so eine Kontextsicht so simpel aufgebaut ist, dass sie wirklich jedem verständlich gemacht werden können. Idealerweise habe ich vielleicht noch eine kleine Legende mit dabei, falls ich unterschiedliche Pfeile verwende oder die Pfeile nicht beschriftet sind, damit die Leute ungefähr grob einen Anhaltspunkt haben, was denn eigentlich gemeint ist. Aber da gebe ich dann einfach einen visuellen Überblick über mein System, wo es eigentlich lebt, was es so der Kontext, in dem wir uns bewegen.

Sven: Und das waren sozusagen die Anforderungen. Der zweite Teil wäre der Lösungsteil. Wie wurde es umgesetzt? Ihr habt euch entschieden: Wir haben diese Kontextsicht und dann zoomen wir noch einmal rein in die Komponenten und die wichtigsten Module.

Ben: Genau. Wir können auch die drei Felder mal durchgehen. Das eine hast du gerade angesprochen, die Komponenten oder Module, die es gibt. Da würde ich einfach aus fachlicher Sicht sehen wollen, wie meine Software aufgeteilt ist. Da kann ich mich oft an Core Funktionalitäten von der linken Seite orientieren, weil meistens eine so eine Core Funktionalität durch ein Modul abgebildet ist. Das muss nicht sein, aber kann sein. Und ich kann das dann entweder als textuelle Liste machen oder aber auch als Bausteinsicht zum Beispiel, dass ich da mein System aufmache und dann zeige: Wie sieht es innen aus? Was sind die Module und wie sind die Abhängigkeiten zueinander? Das ist aber gefährlich, wenn ich zu viele dieser Bausteine habe und dann so eine Bausteinsicht mache auf diesem kleinen Teil des Canvas, dass es dann unter Umständen nicht lesbar wird, außer man druckt es vielleicht auf DinA0 oder so aus.

Sven: Wenn ich zu viele wichtigste Module habe und ich kann nichts weglassen, dann ist es besser, das einfach textuell zu machen.

Ben: Es ist auch sehr einfach, wenn das System schon existiert, sich an einer vorhandenen Code-Struktur zu orientieren. Wenn ich irgendwie Packages oder namespaces oder so habe, dann sind sehr oft die obersten Packages so ein Indikator dafür, dass das möglicherweise ein Modul ist und dann kann ich das relativ leicht herausziehen die Informationen. Da brauche ich auch gar nicht lang, um das auszufüllen.

Sven: Ich denke in earc-42 ist es die Bausteinsicht Level 1.

Ben: Genau.

Sven: Was ein Tick anders ist als bei arc-42 und da bin ich auch großer Fan von, ist der Teil: Die wichtigsten Entscheidungen - gut oder schlecht?

Ben: Das ist bewusst so formuliert, dass wir sowohl gute als auch schlechte Entscheidungen wollen. Wir wurden schon öfter darauf angesprochen, dass Leute gesagt haben: Ja, aber niemand will doch dokumentieren, wenn sie oder er eine schlechte Entscheidung getroffen hat. Und das ist auch gar nicht das, was wir beabsichtigen, sondern was damit gemeint ist: Welche Entscheidungen wurden denn getroffen? Und wir gehen immer davon aus, dass die Entwicklerinnen und Entwickler und Architektinnen, wenn sie eine Entscheidung treffen, immer die bestmögliche Entscheidung in dem zu dem Zeitpunkt gültigen Kontext treffen. Es kann natürlich sein, dass sich nach fünf Jahren herausstellt, auf irgendeine Technologie zu setzen war keine gute Idee, weil die zum Beispiel nicht mehr weiterentwickelt wird und wir jetzt zwingend auf was ganz anderes setzen müssen. Dann war das aus heutiger Sicht eine schlechte Entscheidung, weil wir jetzt Dinge ändern müssen oder unser System instabil wird oder was auch immer die Konsequenzen sind. Heißt aber nicht, dass die Leute eine schlechte Entscheidung getroffen haben.

Sven: Wir hatten es neulich noch mal diskutiert. Niemand steht morgens auf und sagt: Ich will irgendwie eine schlechte Entscheidung treffen und die Firma in den Abgrund reißen. Eigentlich startet alles immer mit besten Intentionen. Nur ich denke, wenn man so wie in euren Beispielen, wenn man ganz kurz sieht: Das waren wirklich die wichtigsten Dinge und da haben wir danebengelegen, da kann man wirklich gut so ein System kommunizieren.

Ben: Ich finde, das ist auch ein Argument. Wenn ich da schlechte Entscheidungen stehen habe oder Entscheidungen, die sich als schlecht erwiesen haben, dann kann ich damit auch noch mal vielleicht beim Management oder so argumentieren, warum das denn jetzt doch vielleicht geändert werden müsste oder sollte. Und dann steht es auch einfach schon mal da. So ist das in den Köpfen der Leute verankert und alle wissen, dass es vielleicht doof ist, das so zu machen, aber alle machen es irgendwie und dann steht es einfach mal aufgeschrieben und dann kann ich zu jemanden hingehen und sagen: Hier, das sind so Entscheidungen, die wir getroffen haben, die hat sich leider als ungünstig erwiesen. Und dann entsteht wieder ein neuer Dialog. Und vielleicht gibt es dann andere Leute, die das angucken, die dann genau dafür schon eine Lösung haben. Und dann ist es vielleicht gar nicht so viel Aufwand, wie wir ursprünglich dachten, so was dann wieder auszumerzen.

Sven: Beziehungsweise auch als Dokumentation, wenn es ein wirklich großes System mit vielen Teams ist, damit die Leute auch sehen: Das ist irgendwie auf dem Schirm, dass das keine gute Entscheidung war, weil in so Gesprächen bekomme ich dann immer wieder mit, dass sie sagen: Alles Mist. Und die Elfenbeinturm Leute, die wissen das gar nicht. Doch, doch. Die wissen das. Super Sache. Und es ist auch ein Tick anders als bei arc-42. Bei arc-42, da sagen wir, wir haben einen Haufen Entscheidungen, haben vielleicht auch 300 Entscheidungen. Und du kannst gar nicht so genau sehen, welche Entscheidung jetzt gut oder schlecht war. Und das ist hier eigentlich ganz gut. Gibt es eine Idee, dass vielleicht auch so einen Backport arc-42 zu machen, dass man noch mal vielleicht in dem Kapitel Entscheidungen sagt: Vielleicht markieren wir gute und schlechte Entscheidungen?

Ben: Das ist durchaus eine gute Idee, so was zu machen. Im Moment ist es erst mal so, dass dann nur alle Entscheidungen als Architecture Decision Records irgendwie hinterlegt sein sollten. Und in diesen Records selbst habe ich eine Wertung, dass ich sage hier: Vielleicht ist es auch einfach das kleinste Übel, für das wir uns entscheiden. Auch das ist eine Entscheidung, wo die Konsequenzen mit dokumentiert sind. Man könnte überlegen, ob man noch so ein Einführungskapitel macht und sagt: Die und die Entscheidungen sind nicht so gut. Falls es dann aber so Entscheidungen von neueren überschrieben werden, müsste ich auch wieder in diesen Einstiegsbereich des Kapitels gehen und sagen: Die Entscheidung ist nicht mehr schlecht, weil wir haben sie eh schon durch etwas anderes ersetzt. Und dann habe ich wieder zusätzlichen Wartungsaufwand, dann ist es wieder mehr Arbeit und die Leute wollen eigentlich nicht arbeiten, wenn sie Dokus schreiben und dann wird es wahrscheinlich schon wieder nicht gemacht. Aber wäre natürlich eine Möglichkeit, das optional mit dazu anzubieten.

Sven: Gut. Letzter Punkt der Lösungen. Auch ein bisschen anders als bei arc-42 direkt. Und das sind die Technologien.

Ben: Genau, das ist einfach nur eine Liste der wichtigsten Technologien, die ich einsetze. Wir nutzen Gradle zum Bauen unserer Software. Wir machen eine Java Webanwendungen mit Spring Boot, JUnit als Testing Zeug, Thymeleaf und ein bisschen Node für Frontend Sachen, JavaScript. Vielleicht schreibe ich auch mal rein, wie ich deploye, dass ich irgendwie im Keller einen Server habe, wo ich das drauf schmeiße. Oder ich sage: Wir nutzen AWS und folgende Technologien davon. Sowas kann ich da alles reinpacken. Das hat den Vorteil, wenn ich vielleicht gucke, wie könnte ich dann neue Personen, die bei uns angefangen haben, verteilen auf die Teams? Dass ich dann schauen kann: In dem Team, welche Technologien werden denn da verwendet? Kann die Person das überhaupt? Oh, kann sie gar nicht. Schade, es ist nicht so das Feld von ihr, sondern sie ist mehr im .NET Umfeld und dann schaue ich: Habe ich das Thema .NET zum Beispiel mit dabei? Und dann schmeiße ich die darein. Oder genauso für mich als Architekt, wenn ich in Projekte gucke oder in Teams. In meinem aktuellen Projekt mache ich das, dass ich die Teams die Canvas erstellen lasse und schaue rein: Was nutzen sie für Technologien. Und wenn das Dinge sind, die ich noch nie gehört habe, vielleicht, dann weiß ich, dass ich da auch nicht wirklich irgendwie Input geben kann, Weil ich habe keine Erfahrung mit den Technologie und kann mich da zurücknehmen und bei anderen Teams, wo ich das dann weiß, kann ich vielleicht mehr reingucken und sagen: Hier, guck mal, schaut euch das vielleicht nochmal an.

Sven: Gut, letzter Punkt. Ich habe gedacht, wir verbraten mehr Zeit. Aber die Diskussion ist genauso kurz wie die Canvas. Und zwar die Risiken und die fehlenden Informationen.

Ben: Da kann ich Risiken bezüglich veralteter Technologien zum Beispiel mit aufführen oder eben auch Risiken von Entscheidungen, die sich als schlecht erwiesen haben. Da kann ich Risiken bezüglich Personal mit reinschreiben. Wenn ich der einzige Mensch bin, der dieses System maintained, dann ist das definitiv ein Risiko. Denn wenn ich morgen im Lotto gewinne, dann sage ich: Auf Wiedersehen, Dann gibt es niemanden mehr, der sich um dieses System kümmern kann und dann kann ich das damit hinschreiben, kann vielleicht auch mit drauf, effektiv, so wie im arc-42 Kapitel mit den Risiken kann ich auch mit aufnehmen: Es gibt vielleicht Marktbegleiter, die das besser können und billiger sind als wir. Möglicherweise kickt uns das diesen Service weg. Oder vielleicht gibt es Dinge, die wir einkaufen sollten, statt so ein System selbst zu entwickeln. Und auch da wieder ist es so, dass dann diese Information erst mal aufgeschrieben wird und explizit gemacht wird und nicht nur so im Kopf ist. Ich habe vielleicht ein .NET Team von acht Leuten, die kümmern sich um das alles. Und dann sind es acht Leute, die dieses System maintainen. Aber effektiv ist es nur eine einzige Person und dann steht das da. Oder auch Kommunikationsprobleme zwischen Teams. Wenn ich irgendwie zwei Tage vor Release Bescheid bekomme: Hey, wir haben die APIs geändert. Bitte testet einmal die komplette Anwendung durch, dann ist das ungünstig, weil ich brauche vielleicht ein bisschen mehr Zeit.

Sven: Die fehlenden Informationen, was wir da für ein Beispiel?

Ben: Das wäre zum Beispiel das, was ich gerade am Schluss gesagt habe, dass Informationen über Änderungen immer erst zu spät kommuniziert werden oder dass sie gar nicht da sind. Was man auch mit reinschreiben kann: Es gibt keine ausführliche Dokumentation von meinem System. Das ist auch ein Risiko und ist Information, die fehlt. Klar, wir haben schonmal eine Canvas, immerhin, aber mehr halt nicht.

Sven: Was ich mir ganz gut vorstellen kann und das entwickelt sich gerade so ein bisschen in meinem Kopf. Wenn man eine Organisation mit vielen Teams hat oder vielleicht ein System baut, wo viele Teams dran arbeiten. Da hat man immer das Problem zu verstehen: Was sind eigentlich die Probleme auf Komplettsystem und auf Organisationsebene? Du kannst natürlich Interviews machen mit den Leuten, das ist immer sehr zeitintensiv. Aber ich denke mir hier gerade, wenn jedes Team eine Architecture Communication Canvas hat. Und ich sage mal, wenn man jetzt viele Teams unterstützen will, da ist natürlich auch ganz cool, dass man einfach diese ACCs einsammelt und darüber geht. Und dann sieht man auch: Oops, also irgendwie fällt auf: 60% der Teams haben dieses Risiko oder sehen jenes Problem. Da ist eigentlich nicht nur ein Tool für die Teams selbst, sondern auch Leute, die mit mehreren Teams arbeiten, um einen ganz guten Überblick zu bekommen: Wo gibt es Probleme bzw. wo läuft es gut? Das sieht man auch bei den guten Entscheidungen. Ben, okay, ich würde mal sagen. Ich hoffe, wir haben verkauft, dass das einfach eine gute Idee ist, das zu tun. Im Grunde genommen, glaube ich, ist es für alle eine gute Idee, so was zu tun. Aber jetzt weiß ich das. Wie fange ich denn an?

Ben: Den Canvas auszufüllen?

Sven: Genau.

Ben: Idealerweise gibt es eine Person, die damit schon ein bisschen Erfahrung hat oder motiviert ist, das zu tun. Und dann nehme ich mir den. Nehmen wir mal eine Situation. Ich bin jetzt Architekt in einer Firma und ich habe drei Teams und die haben keine Doku. Ich möchte gerne, dass die anfangen zu dokumentieren. Dann schnappe ich mir von dem ersten Team eine Entwicklerin oder Entwickler oder einen Lead Dev zum Beispiel, plus idealerweise noch aus dem Fachbereich PO oder einfach eine Person mit viel Expertenwissen und setze mich mit denen zusammen und gehe diesen Canvas durch. Und wenn ich mir dieses Template davon von der Website herunterlade, dann sind auch immer so ein paar Schlüsselfragen mit dabei, die mir ein Indiz geben, in welche Richtung ich dann gehen sollte mit diesem jeweiligen Bereich, den ich gerade ausfüllen möchte. Und dann hat sich bisher immer als total gut erwiesen, diese Dinge der Reihe nach durchzugehen und zu diskutieren. Und dann gab es öfter mal Widersprüchlichkeiten, dass die Fachseite gesagt hat: Ja, das ist so und so. Und die Tech Seite hat gesagt: Ja, nee, wir haben es eigentlich ganz anders gemacht. Und dann habe ich wieder die zwei Leute, die zwei Bereiche zusammengeholt und dann stellen wir fest: Es ist gar nicht so, wie es in Köpfen von manchen ist, und dann füllt sich das Ding fast von alleine aus. Und sehr oft, es ist jetzt, wenn ich das gemacht habe, mit Teams, vorgekommen, dass die Leute so Aha-Momente hatten, dass ihnen dann wieder einfiel: So, ach stimmt, so haben wir das damals gemacht. Das habe ich schon total vergessen. Sie haben sich eigentlich vor zwei Jahren vorgenommen, das niemals zu vergessen, dass sie das so gemacht haben. Eine Woche später war das weg. Und jetzt, einfach weil wir wieder gemeinsam darüber gesprochen haben, kommen diese Dinge hoch und dann kann man das ausfüllen. Und dann reserviere ich üblicherweise 90 Minuten mit zwei Personen und innerhalb dieser 90 Minuten haben wir den Canvas fertig ausgefüllt.

Sven: Du hast gerade noch was erwähnt. Da haben wir so vielleicht noch gar nicht darüber gesprochen. Da gibt es zum Beispielfragen, an denen wir uns entlanghangeln können. Als ich mir das angeguckt habe fand ich das auch total wertvoll. Wenn ich wissen will: Was ist die Value Proposition? Dann sagt sie: Was sind die wichtigsten Ziele? Welchen Wert liefert das System zu Kunden? Was sind die wichtigsten Geschäftsziele? Warum bauen wir dieses System überhaupt? Und was ist die Hauptverantwortung? Für alle neun Punkte habt ihr so immer mindestens fünf Fragen, wenn ich diese durchgehe. Immer mal 4 bis 5 Hilfestellungen.

Ben: Genau.

Sven: Das finde ich auch super. 90 Minuten, da kriegt man schon ein bisschen was hin. Ich muss sagen, bei arc-42 ist mir das auch aufgefallen, weil ich mache immer so eine Stakeholder Analyse. Und dann ist immer die Frage, wir raten mal, was welchen Leuten am wichtigsten ist. Und das ist auch wieder interessant, wie unterschiedlich doch die Meinungen sind, was wem wichtig ist. Aber wenn man es schon in 90 Minuten machen kann und alles aufsammelt, ist es natürlich fast noch besser.

Ben: Die Teams haben dann auch wirklich entweder einen virtuellen Zettel oder man kann das Ganze auch ausdrucken und in den Raum machen. Und haben wirklich was in der Hand, das das System dokumentiert. Und bisher jedes Mal waren die Leute danach total begeistert, weil sie gesagt haben: Oh, das ging ja schnell. Das war total unterhaltsam, weil wir miteinander gesprochen haben und dann füllt sich das irgendwie von selbst. Meistens habe ich es ausgefüllt, aber durch den Dialog ist die Information da aufs Blatt geflossen. Und dann haben sie was, was schon taugt und was sie ihrem Team geben. Ein Team hat es benutzt, um in so einem Town Hall Meeting ihr eigenes System einfach mal den anderen vorzustellen. Und die sind all diese Aspekte von dem Canvas mal durchgegangen und haben das ganz kurz besprochen. Und dann hat die gesamte Gruppe einen Überblick gehabt, was eigentlich dieses System macht und was für Entscheidungen waren, die getroffen wurden. Bisher hieß es immer: Boah krass, sind wir schon fertig? Das ist ja cool. Und: Hey, wir haben etwas, was wirklich einen Mehrwert liefert. Und ich hatte es auch schon, dass von Fachseite kamen ein paar Leute, die gemeint haben: Wir brauchen Infos über Systeme, ob die unseren Anwendungsfall, den wir jetzt diskutieren wollen, betreffen oder nicht. Da habe ich gemeint: Hier sind die Canvases. Schaut auf das Kontextdiagramm und auf die Stakeholder Liste, ob ihr da eventuell tatsächlich mit dabei steht oder ob es ein System betrifft für euren Anwendungsfall. Und dann haben die innerhalb von 20 Minuten den Überblick gehabt und wussten: Okay, mit den drei Teams müssen wir reden und mit allen anderen brauchen wir gar nicht sprechen. Spart natürlich auch wieder super viel Zeit.

Sven: Jetzt hast du gerade gesagt, mit einer kleinen Anzahl von Entwicklern und noch einem Fachexperten wird das ausgefüllt und dann gebt ihr es dem Team. Wie sieht das aus „geben ans Team“? Einfach so ein Handout, so nach dem Motto: Guckt euch das an? Oder würdest du eher sagen: Wir machen eine kleine Präsi oder so, damit Leute auch nur mal ein bisschen Input geben können.

Ben: Ich würde sagen, das hängt davon ab, wie die Teams ticken. Manche Leute haben das dann so gemacht, haben einfach ins Confluence gehängt und haben ihren Teams Chat geschrieben: Guckt mal hier ist Doku, schaut euch das bitte an. Manche haben das in der Retro verwendet, um zu sagen: Guckt mal, das ist übrigens entstanden, als ihr nicht dabei wart. Wir schauen uns jetzt mal gemeinsam an, gebt mal Feedback dazu. Manche haben es einfach per Mail geschickt an alle Teammitglieder: Hier, das ist jetzt unser erstes Stück an Dokumentation. Es ist ganz unterschiedlich. Wichtig ist, dass alle im Team wissen, dass es das gibt und vielleicht dann auch noch mal darüber gucken können und dann feststellen: Hey, da habt ihr was übersehen, wir haben das und das gemacht. Da fehlt zum Beispiel irgendwie ein wichtiges Modul oder folgende Funktion haben wir inzwischen schon ausgebaut. Solche Dinge. Und es ist ja auch nicht so, dass ich das einmal diesen Canvas anlege und dann ist er für immer gültig, sondern ich darf auch da iterieren und immer wieder Dinge anpassen. Und ich würde sogar empfehlen, das zu tun. Alle drei Monate ist vielleicht bisschen häufig, je nachdem wie sehr die Software sich ändert oder auch die Architektur. Aber alle sechs Monate mal darüber zu gucken: Passt das noch alles, was da steht? Oder müssen wir vielleicht Dinge anpassen? Und dadurch, dass es nur sehr wenig Zeit gebraucht hat, um das Initial anzulegen. Es braucht natürlich noch viel weniger Zeit, um schnell ein Update zu machen.

Sven: Ich denke, da ist eine großer Charme davon, dass die wichtigsten Dinge, die sich selten ändern, runter gepresst ist. Gibt es auch Situationen, wo du sagst: Dafür sollte man das nicht nutzen. Ich sage mal so ein Misuse sozusagen. Dass man es mit den falschen Zielen vielleicht nutzen will.

Ben: Ich hatte es tatsächlich einmal schon, dass ich gebeten wurde, das für die Infrastruktur der Firma zu verwenden. Wirklich für: Welche Server gibt es, welche Netze habe ich? Und dafür passt das einfach gar nicht, weil mit dem Canvas beschreibe ich ein Stück Software oder ein Software Produkt oder Bibliothek, aber nicht eine Firmeninfrastruktur. Das passt einfach überhaupt nicht zusammen. Das würde ich auch mit arc-42 nicht machen, sondern da gibt es irgendwelche anderen Werkzeuge, die ich dann verwende. Das wäre ein so ein Beispiel. Ansonsten wüsste ich jetzt nichts, was dagegen spricht, das zu machen. Wenn ich schon eine sehr ausführliche arc-42 Doku habe, dann fällt es mir total leicht, all das, was schon da ist, einfach in den Canvas zu packen. Fertig. Und ich bin in einer Viertelstunde vielleicht schon durch. Auch dann ist es toll, weil es eben, wie du vorhergesagt hattest, einen viel schnelleren Einblick in ein System geben kann als 30 Seiten Doku, die ich erst mal lesen muss. Ansonsten habe ich bisher zumindest noch nichts erlebt, wo ich sagen würde: Naja, dafür ist es vielleicht nicht geeignet.

Sven: Okay. Und dann vielleicht noch eine letzte Frage. Es gibt ja noch auf der arc-42 Seite noch eine andere Canvas, die Architecture Inception Canvas heißt die glaube ich. Was ist da die Abgrenzung? Was tut die?

Ben: Als wir angefangen hatten mit unserem Canvas, kam irgendwann mal ein Kollege von uns, hat uns einen Link geschickt und hat gesagt: Guckt mal, da hat jemand schon Software Architektur Canvas gemacht. Es war Patrick damals, im Februar diesen Jahres oder so. Und da haben wir uns gedacht: Na toll, jetzt kann uns jemand zuvor und haben uns dann mit ihm ausgetauscht, was denn so sein Hintergrund ist und seine Idee. Und deswegen wurde der dann auch umbenannt in Inception Canvases, dass ich anfange den zu erstellen, wenn ich noch gar keine Software habe. Das heißt, ich fokussiere mich sehr stark erst mal auf den Problemraum, auf die fachliche Seite. Ich hab da sechs Bereiche, die ich ausfüllen kann. Klar, da sind Überschneidungen mit der Business Kontext und Funktionsübersicht. Aber so rein an Architekturthemen ist erst mal nur so eine Architektur Hypothese. Das könnte dafür passen, ohne dass es in irgendeiner Form validiert ist. Und noch ein kleiner Bereich: Was könnten denn Herausforderungen oder Risiken sein mit dem Ansatz, den wir da uns als Hypothese überlegt haben? Und der Architecture Communication Canvas ist eher dafür gedacht, wenn ich schon ein System habe, das vielleicht ein halbes Jahr lebt oder vielleicht auch schon 25 Jahre und ich möchte das dann redokumentieren oder ich möchte meine arc-42 Doku um das ergänzen. Und da ist dann eben ein größerer Fokus noch auf die Entscheidungen, auf die technische Seite und die Modularisierung meines Systems gelegt.

Sven: Okay, habt ihr den Teil „eingesetzte Technologien“ und da gibt es jauch die Tech Stack Canvas. Wir verlinken das alles. Wo grenzt ihr euch da ab? Was kann die, was ihr nicht könnt? So wollte ich das gar nicht formulieren. Aber offensichtlich gibt es eine eigene Canvas für den Tech Stack. Und warum sollte ich das nutzen? Weil ich kann bei euch auch schon Technologien reinschreiben.

Ben: Bei uns ist es ein kleiner Bereich für Technologien und der Tech Stack Canvas bietet da einfach noch viel mehr Platz um da detaillierter auf einzelne Bereiche einzugehen. Da habe ich einen Bereich, der sich rein auf die Frontend Technologien fokussiert, einer nur aufs Backend. Ich habe vielleicht spezielle Werkzeuge, die ich für mein Testing, für meine QA anwende. Hoffentlich habe ich Dinge für Monitoring und Analyse Werkzeuge für meine Software. Ich habe sogar Platz, um meinen tatsächlichen Entwicklungsprozess da irgendwie abzubilden, um zu schreiben: So arbeiten wir. Das heißt, da habe ich eine wirklich sehr starke Fokussierung auf die einzelnen Teilbereiche und Werkzeuge, die da sind, die ich jetzt im Architecture Communication Canvas vielleicht gar nicht auflisten würde, weil ich sage hier: das sind die neuen Haupttechnologien, das passt schon. Und eben in diesem Tech Stack Canvas kann ich da noch viel tiefer einsteigen.

Sven: Wie gesagt, ich bin ein großer Fan. Ben sowieso. Guckt es euch an. Extrem hilfreiche Tools für wenig Geld. Kost ja nix, aber für wenig Aufwand. Man kann es einfach mal kurz umsetzen. Und ich sehe keinen Grund, das nicht zu tun. Ich bin begeistert. Ich hoffe, die Begeisterung kam ein bisschen rüber und ihr probiert es einfach aus.

Ben: Ich würde gerne noch einen Punkt euch auf den Weg geben, Euch Zuhörerinnen und Zuhörern. Sehr oft in Meet Ups oder grundsätzlich im Projekt, wenn ich mit Leuten rede und das Thema Architektur Dokumentationen anspreche, dann ist: Oh nee, das schon wieder, keine Lust. Das ist langweilig, das ist doof, das liest doch eh niemand. Da ist sehr, sehr viel negative Vorerfahrungen da und es ist auch tendenziell eher nicht so, dass man in der Ausbildung. Architektur Dokumentation lernt. Ich hatte es nicht an der Hochschule und ich hatte es auch nicht an der Uni. Das war einfach nie Teil davon. Und so ein Canvas ist für Leute, die noch nie mit Architektur Doku Berührung hatten, ein super Einstieg, weil sie sehen: Architektur Dokumentation kann schnell gehen. Ich muss nicht die komplette UML beherrschen, um dokumentieren zu können. Sehr viel entsteht einfach durch das Sprechen miteinander. Und dann ist meine allererste Erfahrung: Dokumentieren macht Spaß und ist cool. Und dann habe ich schon eine ganz andere Grundlage geschaffen, als wenn Leute immer nur negative Erfahrungen diesbezüglich gesammelt haben.

Sven: Was ich mir ganz gut vorstellen kann, ist, dass das ein super Startpunkt ist, weil du hast ganz wenig und dann kannst du sagen: Eigentlich, der ACC ist meine Doku. Aber immer wenn dir irgendwie auffällt: Ach, hier bräuchte ich vielleicht mal ein bisschen mehr Information, hier könnte es hilfreich sein, dann schreibe ich es auf. Weil der umgekehrte Weg fällt mir auch auf. Du bist vor diesem leeren Papier und dann denkst du vielleicht: Mehr schreiben ist besser als weniger schreiben. Und dann steht in so einer Doku ziemlich viel drin, wo du denkst: Das ist jetzt wirklich Architektur Dokumentation. Dass man es umgekehrt so sieht, dass man sagt: Wir fangen mit so einem Minimum an und arc-42 ist sozusagen der Teil, wo uns in unserem Projekt auffällt: Hier reicht der ACC einfach nicht mehr aus. Wir brauchen ein bisschen mehr.

Ben: Genau. Und was dann die Leute auch feststellen werden, ist, dass all diese Bereiche auf dem ACC tatsächlich auch eine Heimat im arc-42 Template finden. Das heißt, das, was ich dafür schon gemacht habe, kann ich einfach übernehmen und muss die Arbeit nicht doppelt machen.

Sven: Okay, dann, Ben, bedanke ich mich bei dir sein. Es sei denn, es gibt noch ein finale Worte? Und ja, auch bedanke ich mich auch bei euch Zuhörern und Zuhörerinnen und wünsche Happy Architecture Communication. Vielen Dank. Bis dann.

Ben: Bis dann. Ciao.

Sven: Ciao ciao.