Wo kann GenAI innerhalb von arc42 gut unterstützen (und wo nicht)?

Der Software Architecture Summit findet schon seit geraumer Zeit zweimal im Jahr statt: im Frühjahr in München und im Herbst in Berlin. Das Besondere daran: Das dreitägige Programm besteht im Wesentlichen aus jeweils mehreren parallelen Halbtagesworkshops und ist geprägt von Austausch und Mitmach-Formaten.

Diesen Oktober habe ich dort einen Workshop zum Thema Architekturdokumentation mit generativer AI (kurz GenAI) mit mehr als 40 interessierten Softwarearchitektinnen und -architekten durchgeführt (für eine Impression siehe Abb. 1).

Da ich viel in Gruppen erarbeiten und ausprobieren lassen wollte, die Leute sich aber tendenziell nicht kannten, habe ich zum Einstieg ein kleines Stimmungsbild gemacht: Wo kann GenAI in arc42 gut unterstützen – und wo eher nicht? Die Abfrage sollte in die Thematik einleiten und gleichzeitig die Chance bieten, dass sich die Gruppenmitglieder untereinander ein wenig bekannt machen.

Abfrage und Austausch im Workshop

Konkret hat jede und jeder direkt zu Beginn des Halbtagesworkshops einen Bogen mit dem arc42-Schema und Klebepunkte erhalten. Jeweils drei in Rot und drei in Grün. Die Aufgabe war, damit das Potenzial von GenAI in arc42 zu lokalisieren (siehe Abb. 2).

Die Teilnehmenden sollten für sich die sechs Klebepunkte auf die zwölf Abschnitte des arc42-Schemas platzieren. Die grünen Klebepunkte für besonders hohes Potenzial mit GenAI. Die roten Klebepunkte für vergleichsweise geringes – jeweils nach individueller Einschätzung und gerne auch Bauchgefühl. Inhaltlich zum Thema behandelt hatten wir zu dem Zeitpunkt im Workshop ja noch nichts.

Anschließend habe ich die Leute in kleine Gruppen zu zweit bzw. dritt eingeteilt und gebeten, sich untereinander kurz vorzustellen; in den Gruppen wurde später im Workshop weiter zusammengearbeitet. Vor allem sollten die Leute ihre Klebepunkt-Einschätzungen miteinander vergleichen. Was hat sie jeweils dazu bewogen, in einem Abschnitt von arc42 gute Möglichkeiten für den Einsatz von GenAI zu sehen? Oder umgekehrt weniger Potenzial. Vielleicht hat der eine oder die andere da z.B. schon Erfahrungen gesammelt …

Wir haben dann im Plenum noch einige Dinge kurz diskutiert – insbesondere warum bei einzelnen Abschnitten die Meinungen innerhalb einer Gruppe auseinandergingen (z.B. bei den Architekturentscheidungen).

Die folgenden gut drei Stunden des Workshops haben wir uns verschiedenen GenAI-Ansätzen im Zusammenspiel mit Architekturdokumentation gewidmet. Bezüglich des Stimmungsbildes hatte ich in Aussicht gestellt, die Zettel auszuwerten und das Ergebnis zu teilen, wenn die Leute mögen. Immerhin 40 ausgefüllte Zettel konnte ich mit nach Hause nehmen (siehe Abb. 3). Das Versprechen mit der Auswertung hole ich jetzt in diesem Blog-Beitrag nach.

Die Auswertung

Ich habe die Klebepunkte auf den eingesammelten Zetteln in Excel überführt und ausgewertet. Abb. 4 zeigt das Ergebnis in stark verdichteter Form: pro arc42-Abschnitt jeweils die Anzahl roter und grüner Klebepunkte gegenübergestellt, und in der Differenz-Spalte rechts jeweils ein Saldo. Nicht alle Teilnehmenden hatten ihre Klebepunkte komplett verbraucht, deswegen ist die Summe etwas zu klein (zusammen 224 statt der erwarteten 240 Punkte).

Als arc42-Bereich mit dem größten Potenzial nach Einschätzung der Teilnehmenden stechen die Sichten hervor (5. Bausteinsicht, 6. Laufzeitsicht, 7. Verteilungssicht); sie belegen bezüglich der grünen Punkte die ersten drei Plätze, und zwar in genau dieser Reihenfolge. Übrigens hatten acht Teilnehmende ihre drei grünen Punkte genau auf die Gruppe der drei Sichten geklebt.

Umgekehrt vermuten die Teilnehmenden in den ersten Abschnitten von arc42, die sich mit der Aufgabenstellung und architekturrelevanten Anforderungen beschäftigen, eher ein geringes Potenzial. Abschnitt 1 (“Einführung und Ziele”) enthält insbesondere auch die Qualitätsziele und Stakeholder und hat mit Abstand die meisten roten Klebepunkte abbekommen (30 Stück, also 75 % aller abgegebenen Zettel).

Bei einigen Abschnitten ist das Bild sehr uneinheitlich, etwa bei den Qualitätsanforderungen (Abschnitt 10). Die im Plenum diskutierten Architekturentscheidungen haben nach Einschätzung der Teilnehmenden in Summe eher ein geringes Potenzial (15 rote, 5 grüne Punkte).

Einige Bereiche haben übrigens kaum Punkte abbekommen, etwa die querschnittlichen Konzepte (Abschnitt 8). Die Teilnehmenden hatten sie vermutlich weniger auf dem Schirm, allerdings fördert die Beschränkung auf sechs Punkte ohnehin eine Fokussierung auf spannende Bereiche – in die eine oder andere Richtung.

Eine interessante Diskrepanz in der Auswertung: Während die Qualitätsziele als mit wenig Potenzial eingeschätzt wurden, ist das Bild bei den Qualitätsanforderungen etwas besser. Eine mögliche Erklärung: Während die Ziele tendenziell eher von Menschen kommen, vielleicht im Austausch mit den Stakeholdern, kann GenAI beim Konkretisieren in Form von Qualitätsszenarien sehr gut helfen. Womit wir bei der Diskussion sind.

Was sagt uns das Ergebnis?

Tatsächlich solltet ihr die Ergebnisse in Abb. 4 nicht überinterpretieren. Immerhin stand das Stimmungsbild ganz am Anfang der Veranstaltung. Und in der Diskussion im Plenum kam eine interessante Annahme heraus.

Viele der Teilnehmenden sind in ihrer Einschätzung davon ausgegangen, dass die Software bereits vorliegt, zum Beispiel als Quelltext, und die Architekturdokumentation dann im Nachgang mit AI-Unterstützung entsteht. Dies ist ein möglicher Ansatz, um mit GenAI Dokumentationsinhalte zu erstellen. Ich habe ihn hier im Blog bereits mit meinen Blog-Beiträgen zu DeepWiki und ähnlichen Lösungen vorgestellt, welche Dokumentation aus Code-Repositories ableiten.

Und tatsächlich scheinen die grünen Punkte das zu bestätigen, denn die Sichten lassen sich aus einer bestehenden Software vergleichsweise gut extrahieren. Das ginge auch schon ohne GenAI mit klassischer, statischer Code-Analyse oder Werkzeugen wie Doxygen, zumindest für die Bausteinsicht. GenAI kann zusätzlich Lücken mit Text füllen, die aufgrund eventuell fehlender Quelltext-Kommentare leer bleiben. Auch die nötigen Diagramme kann ein Large Language Model (LLM) mit Hilfe von Mermaid oder PlantUML gut generieren. Insbesondere auch Sequenzdiagramme für die Laufzeitsicht.

Ein ganz anderer Ansatz basiert auf der Idee, GenAI als interaktiven Sparringspartner zu nutzen. Das LLM fungiert dabei als Ideengeber und bietet einen Rahmen. GenAI generiert aus Stichpunkten erste Fassungen und befüllt Strukturen iterativ im Gespräch, im einfachsten Fall tatsächlich als Chat, oder stärker geführt durch agentische Workflows.

Solche Ansätze sind auch für architekturrelevante Anforderungen (z.B. Qualitätsziele, Kontextabgrenzung) gut geeignet und können etwa beim Erarbeiten einer Lösungsstrategie oder konkreter Architekturentscheidungen helfen. Einen Agenten speziell für Qualitätsziele habe ich in einem Beitrag in Informatik Aktuell vorgestellt (siehe weitere Informationen).

Fazit

Für eine Abschätzung, welche Abschnitte von arc42 gut mit GenAI zu erstellen, zu aktualisieren oder auch zu reviewen sind, ist ein Blick auf den Fortschritt des Entwicklungsvorhabens entscheidend.

Gerade die architekturrelevanten Anforderungen oder nachvollziehbare Architekturentscheidungen lassen sich aus der Umsetzung allein nur schwer extrahieren – unabhängig davon, ob GenAI im Spiel ist oder nicht. Stark lösungsbezogene Inhalte wie die Sichten sind hier viel zugänglicher.

Umgekehrt lassen sich aufgabenbezogene Inhalte mit einer AI als Sparringspartner sehr gut erarbeiten – gerade früh im Vorhaben, wenn es noch keinen Code gibt. Je weiter die Umsetzung fortschreitet, desto mehr lösungsbezogene Inhalte lassen sich daraus ableiten. Abb. 5 zeigt arc42 noch einmal strukturiert in drei Kategorien: aufgabenbezogene, lösungsbezogene und bewertungsbezogene Inhalte. Je nach GenAI-Ansatz und Zeitpunkt bergen die Abschnitte mal mehr, mal weniger Potenzial. Komplett nutzlos wäre GenAI nirgendwo.

Ein arc42 auf Knopfdruck allein mit GenAI und ohne menschliches Zutun zu befüllen, ist aus meiner Sicht illusorisch. Dem steht zum einen im Wege, dass sich viele Informationen nicht aus dem Quelltext extrahieren lassen (z.B. die Randbedingungen), zum anderen erfordern bestimmte Inhalte den Austausch mit den maßgeblichen Stakeholdern.

Gleichwohl gab es im Workshop auf dem Summit einige spannende und erfolgversprechende Dinge zu sehen. Mein persönlicher Favorit ist hier das Thema “Review von Dokumentation”, wo GenAI zum Beispiel Inkonsistenzen zwischen Abschnitten aufdecken kann. Und gerade in der dritten Kategorie von Abbildung 5 (bewertungsbezogene Inhalte, Abschnitte 10 und 11 in arc42) steckt viel Potenzial. Vielleicht erklärt das auch das uneinheitliche Bild für diese Abschnitte in Abb. 4.

Aber das wäre eine separate Diskussion wert. Mehr dazu in einem der nächsten Blog-Beiträge.

Weitere Informationen

• “Sind DeepWiki und seine "Nachbauten" die Zukunft der Architekturdokumentation?”, Blog-Beitrag bei embarc
• “Ein erster AI-Agent für die Softwarearchitektur: Qualitätsziele im Dialog”, Artikel in Informatik Aktuell (Deutsch)
• “Was passiert, wenn man DeepWiki & Co. die Quelltext-Kommentare wegnimmt?”, Blog-Beitrag bei embarc
• Welche Ansätze von GenAI tatsächlich bei Architekturdokumentation helfen und wo die Grenzen dabei sind, ist auch Thema in meinem Seminar “Leichtgewichtige Architekturdokumentation” (“iSAQB CPSA-A ADOC”). Infos und meine nächsten Termine