Gute Softwarearchitektur entsteht nicht im Alleingang. Unterschiedliche Perspektiven zusammenzubringen, ein gemeinsames Verständnis zu entwickeln und fundierte Entscheidungen zu treffen, gehört zu den zentralen Herausforderungen moderner Softwareentwicklung.
Genau hier setzt das neue iSAQB-Modul COSMO (Collaborative Software Modeling) an. Es vermittelt Methoden und Techniken der kollaborativen Modellierung, mit denen Teams komplexe Zusammenhänge sichtbar machen, fachliche und technische Perspektiven verbinden und gemeinsam tragfähige Architekturentscheidungen erarbeiten können. Ein weiterer Schwerpunkt liegt auf der Vorbereitung und Moderation solcher Modellierungssessions.
Wir haben mit den drei Kuratoren Eberhard Wolff, Daniel Sack und Tom Asel gesprochen. Im Interview erklären sie, wie COSMO entstanden ist, warum eine gemeinsame Sprache für erfolgreiche Architekturarbeit entscheidend ist, welche Rolle Facilitation spielt und weshalb kollaborative Modellierung gerade im Zeitalter der KI immer wichtiger wird.
COSMO ist jetzt das 22. Advanced-Level-Modul im iSAQB-Portfolio. Für wen ist das Modul in erster Linie gedacht, welche Schwerpunkte setzt ihr inhaltlich – und was sollten Teilnehmende idealerweise schon mitbringen, um wirklich davon zu profitieren?
Daniel Sack:
Viele Problemstellungen sind heute zu komplex, als dass eine einzelne Person sie allein lösen könnte. Das gilt besonders dann, wenn mehrere Bereiche gemeinsam an einer Lösung arbeiten müssen und dabei Zielkonflikte sichtbar werden. Genau hier setzt COSMO an: mit kollaborativen Methoden, die unterschiedliche Perspektiven auf den Tisch bringen, und mit Facilitation, die eine Gruppe zu einer gemeinsam getragenen Lösung führt.
Eberhard Wolff:
Es geht in dem Modul um kollaborative Modellierung. Das ist zum einen ein Bereich von Domain-driven Design, bei dem man sich gemeinsam die Domäne erschließt. Es gibt aber auch Techniken, um andere Architektur-Entscheidungen gemeinsam zu treffen. Alle diese Techniken sollen es mehr Menschen ermöglichen, an der Modellierung teilzunehmen. Dementsprechend steht das Training allen offen, die an Modellierung und Zusammenarbeit interessiert sind. Ein grundlegendes Verständnis für Architektur ist sicher hilfreich. Eigentlich kennen aber alle Personen, die an IT-Projekten arbeiten, die typischen Herausforderungen in diesen Bereichen.
Tom Asel:
Mir ist besonders wichtig, dass die Teilnehmenden kollaborative Architekturarbeit in ihrem Alltag etablieren können. Architekt:innen lernen, ihr Team stärker einzubeziehen. Entwickler:innen erfahren, wie sie selbst Architekturverantwortung übernehmen und Entscheidungen gemeinsam gestalten können.
Dafür braucht es mehr als Modellierungstechniken. Wir beschäftigen uns deshalb auch mit den organisatorischen Voraussetzungen: Welche Freiräume braucht ein Team? Wie wirken Hierarchien und Rollenbilder? Und wie gelingt der Einstieg unter weniger idealen Bedingungen? Die Teilnehmenden sollen konkrete Ansatzpunkte für ihr eigenes Umfeld mitnehmen.
Das ist auch für Teamleiter:innen, Testmanager:innen und Projektverantwortliche wertvoll, die eng mit der Entwicklung zusammenarbeiten. Hilfreich sind eigene Erfahrungen mit Softwareprojekten und die Bereitschaft, gewohnte Rollen und Arbeitsweisen zu hinterfragen.
Wie kam es zu der Idee, COSMO als eigenständiges Modul zu entwickeln? Was war die Lücke im bestehenden CPSA-Advanced-Level-Angebot, die ihr gesehen habt – und wie hat sich eure Zusammenarbeit als Kuratoren-Trio mit euren unterschiedlichen Hintergründen dabei entwickelt?
Tom:
Ich begreife Architekturarbeit schon lange als Teamsport. Trotzdem erlebe ich es in der Praxis häufig, dass strikte Rollentrennungen, Engpässe und Wissensmonopole als gegeben hingenommen werden. Dabei haben Communitys rund um kollaborative Softwareentwicklung längst wirksame Praktiken entwickelt. iSAQB Advanced-Level-Module wie AGILA oder DDD greifen diese auf, lassen durch ihre eigenen Schwerpunkte aber wenig Raum für eine Vertiefung. Diese Lücke wollten wir schließen und das Wissen gebündelt in die Architekturausbildung und die Architektur-Community tragen.
Unsere Stärke als Dreierteam liegt darin, dass wir unterschiedliche Biografien und Erfahrungsbereiche mitbringen, die sich sehr gut ergänzen. Wir haben COSMO nicht nur gemeinsam gestaltet, sondern dabei auch viel voneinander gelernt. Das begann 2025, als ich die Idee mit Mitgliedern der COMO-Community diskutiert habe. Daniel war sofort dabei, und aus unserer Initiative entstand COSMO. Mit Eberhards Einstieg nahm die Lehrplanentwicklung richtig Fahrt auf: Er teilte unsere Begeisterung, brachte Erfahrung und neue Perspektiven ein und half uns, Inhalte und Umfang zu schärfen.
Daniel:
Dass ich sofort dabei war, hat einen einfachen Grund. Als einer der Organisatoren des ComoCamps liegt mir am Herzen, Collaborative Modeling (COMO) zugänglicher zu machen. Seit dem ersten Camp höre ich immer wieder dieselben Fragen: ‚Wie fange ich eigentlich an?‘ oder ‚Bei uns im Unternehmen geht das nicht, weil …‘. Mit COSMO haben wir für alle, die an diesem Punkt stehen, einen Startpunkt geschaffen, in einem Rahmen, der im Architekturumfeld anerkannt ist.
Der Lehrplan legt großen Wert auf die Entwicklung einer bewusst gestalteten „gemeinsamen Sprache“ (Ubiquitous Language) im Team. Woran merkt man in der Praxis eigentlich, dass einem Team genau diese gemeinsame Sprache fehlt – oft ja, bevor es jemandem richtig bewusst wird? Und was ist ein typischer Stolperstein beim Aufbau eines gemeinsamen Verständnisses von Begriffen?
Eberhard:
Durch das Klären von Begriffen entstehen Diskussionen über die Fachlichkeit. Dadurch werden fachliche Anforderungen klar.
Außerdem kann Kollaboration nur erfolgreich sein, wenn alle beteiligten Menschen dieselbe Sprache sprechen. Das Etablieren einer gemeinsamen Sprache ist daher zentral für Software-Entwicklung.
Außerdem basiert Software auf einheitlichen Begriffen: Code ist deterministisch und ist daher gezwungenermaßen immer eindeutig. Wenn man also beim Design keine gemeinsame und eindeutige Sprache nutzt, kann Software-Entwicklung nicht wirklich erfolgreich sein, weil man diesen Determinismus nicht erreichen kann.
Tom:
Oft merken wir es daran, dass alle denselben Begriff verwenden, bei konkreten Beispielen aber unterschiedliche Dinge meinen. Solange wir abstrakt sprechen, fällt das kaum auf. Erst wenn wir gemeinsam einen konkreten Ablauf durchspielen, wird sichtbar, dass die vermeintliche Einigkeit gar nicht besteht. Ein typischer Stolperstein ist daher, dieselben Wörter schon für gemeinsames Verständnis zu halten.
Die Kluft zwischen Development und Fachabteilungen bleibt besonders dann lange unentdeckt, wenn die Kommunikation hauptsächlich über Dokumente oder Werkzeuge läuft und zu wenig durch kollaborative Arbeit und gemeinsame Gespräche entsteht. Kollaborative Modellierung schafft einen Raum, in dem wir Begriffe anhand konkreter Beispiele gemeinsam hinterfragen und ihre Bedeutung klären können.
Mit KI wird das noch wichtiger: Wenn wir schneller implementieren können, müssen wir umso genauer verstehen, was wir eigentlich umsetzen wollen.
Daniel:
Weitere Warnsignale sind Übersetzer:innen, also einzelne Personen, ohne die das Gespräch zwischen Fachbereich und Entwicklung nicht funktioniert, oder Code, in dem die Dinge anders heißen als im Gespräch mit der Fachabteilung. Ein zweiter Stolperstein ist das Gegenteil von scheinbarer Einigkeit: der Versuch, für das ganze Unternehmen eine einzige verbindliche Definition durchzusetzen. Ein ‚Kunde‘ bedeutet im Vertrieb etwas anderes als in der Buchhaltung, und das ist auch richtig so. Eine gemeinsame Sprache gilt immer für einen bestimmten Kontext. Ziel ist Klarheit darüber, wo ein Begriff was bedeutet.
Der Lehrplan unterscheidet klar zwischen der Facilitator-Rolle und der inhaltlichen Mitgestaltung von Architekturentscheidungen – gleichzeitig ist es oft ein und dieselbe Person, die beides übernimmt. Wie bringt man Architekt:innen, die ja meist eine klare fachliche Meinung zur ‚richtigen‘ Lösung haben, bei, diese neutrale Facilitator-Haltung einzunehmen, ohne dabei ihre eigene Expertise komplett auszublenden?
Eberhard:
Gute Architekt:innen müssen beide Bereiche abdecken: Sie können nicht die gesamte notwendige Expertise über jedes technische und fachliche Detail haben, sondern müssen das Wissen des gesamten Teams nutzen und diese Expertise für das Projekt erschließen. Deswegen ist Facilitation sowieso ein wesentlicher Teil erfolgreicher Architekturarbeit. Dabei auf den Input aller Beteiligten zu reagieren, gleichzeitig sein eigenes Wissen nutzbar zu machen, aber nicht einfach alle Entscheidungen selbst zu treffen, ist die entscheidende Herausforderung in der gemeinsamen Architekturarbeit. Das Training vermittelt und vertieft durch den Facilitation-Teil Skills in genau diesem Bereich. Außerdem ist das Ziel des Trainings mit Techniken aus der kollaborativen Modellierung wie Event Storming ganz konkrete Ideen zu geben, wie man die Zusammenarbeit nicht nur mit allgemeiner Facilitation verbessern kann.
Daniel:
Während klassische Facilitation auf eine neutrale Haltung setzt und sich auf die Prozessebene konzentriert, also auf Zeit, Logistik und Gesprächsführung, moderieren wir bei kollaborativer Modellierung zusätzlich auf der inhaltlichen Ebene, dort, wo das gemeinsame kognitive Modell entsteht. Visualisierung hilft dabei, das Gesagte für alle zugänglich zu machen. Architekturkompetenz hilft, Rahmenbedingungen zu verstehen und Trade-offs einzuschätzen. Entscheidend ist, die eigene Rolle als Moderator:in oder Teilnehmer:in bewusst zu steuern und offen zu kommunizieren.
Tom:
Dafür braucht es zunächst das Bewusstsein für die eigenen Vorprägungen durch Meinungen, Gewohnheiten und Erfahrungen. In COSMO-Trainings lernen die Teilnehmenden, solche Prägungen bei sich selbst und anderen zu erkennen und bewusst mit ihnen umzugehen.
Ein zu stark vereinfachter Ansatz wäre, die Session von jemandem ohne eigene Architekturerfahrung leiten zu lassen. Das lehnen wir ab. Aus unserer Sicht setzt die Facilitation von Architektur-Workshops eigene Architekturexpertise voraus. Diese
braucht es, um einzuschätzen, ob sich Diskussionen zielführend entwickeln, bei Bedarf steuernd einzugreifen und Impulse zu geben, wenn die Gruppe nicht weiterkommt. Es geht also darum, die eigene Expertise bewusst einzusetzen, ohne die eigene Vorstellung der richtigen Lösung zum Maßstab der gesamten Session zu machen. Die Herausforderung besteht darin, architektonisch Orientierung geben zu können und zugleich offen für andere Perspektiven und Lösungsansätze zu bleiben.
Machtgefälle und dominante Teilnehmende werden im Curriculum explizit als Risiko für die Qualität einer Session genannt, ebenso die Chance, unterrepräsentierten Perspektiven mehr Gehör zu verschaffen. Habt ihr eine konkrete Technik, die zuverlässig dafür sorgt, dass auch leisere oder rangniedrigere Stimmen im Raum gehört werden?
Daniel:
Machtgefälle wirken oft unbemerkt. Wer viel Rang hat, durch Position, Erfahrung oder Rolle, merkt meist gar nicht, wie sehr sich andere zurückhalten. Deshalb braucht es Techniken für zwei Momente: wenn Ideen gesammelt werden und wenn die Gruppe entscheidet. Bei Entscheidungen frage ich gezielt nach, wer es anders sieht und was es bräuchte, damit diese Person mitgehen kann. Oft steckt genau dort das Wissen, das später gefehlt hätte.
Eberhard:
Zum einen ist das eine Aufgabe von Facilitation und Moderation: Es sollen alle gehört und an den Sessions teilnehmen können. Die Existenz einer solchen Rolle führt schon dazu, dass dominante Personen nicht einfach ad hoc die Moderation übernehmen und sich auch nicht selbst dann in den Mittelpunkt stellen können.
Außerdem unterstützen die Techniken aus der kollaborativen Modellierung diesen Aspekt – und zwar als einen ganz wichtigen Teil. Das fängt schon bei scheinbar unwichtigen Details an: Wenn alle Beteiligten Post-Its schreiben und nicht nur Dinge verbalisieren, kommen Menschen zum Zug, die sich bei Diskussionen sonst nicht in den Vordergrund spielen. Außerdem kann man sicherstellen, dass tatsächlich alle Post-Its in das Ergebnis einfließen und damit der Input aller Beteiligten.
Tom:
Eine konkrete Ergänzung ist, Optionen zunächst so zu sammeln, dass nicht erkennbar ist, wer sie eingebracht hat. Damit rückt der Inhalt eines Beitrags in den Vordergrund. Erfahrung oder Rang der Person bestimmen dann weniger stark, welche Ideen Aufmerksamkeit bekommen. Denn auch der erfahrenste Kollege hat nicht automatisch die beste oder einzig relevante Antwort.
Aufgabe von Facilitation ist es, unterrepräsentierte Perspektiven wahrzunehmen und gleichwertige Möglichkeiten zur Beteiligung zu schaffen. Dazu gehört auch, die eigenen Vorannahmen und bevorzugten Lösungsansätze zu erkennen und bewusst damit umzugehen.
Eine einzelne Technik garantiert das noch nicht. Es braucht Übung und Aufmerksamkeit für die Dynamik im Raum. Gerade deshalb lohnt es sich für Architektinnen und Architekten, die Workshops moderieren, diese Fähigkeiten gezielt aufzubauen.
Ihr sagt, dass das Externalisieren von implizitem Wissen nicht nur der menschlichen Zusammenarbeit hilft, sondern auch bessere Ergebnisse mit LLMs ermöglicht. Verändert das schon jetzt ganz konkret, wie ihr Sessions gestaltet oder Ergebnisse dokumentiert – fließen Outputs aus kollaborativen Modellierungs-Sessions inzwischen strukturiert in KI-Tools ein, oder ist das eher noch ein Zukunftsversprechen?
Tom:
Definitiv. Wenn Code-Erzeugung durch KI-Tools immer günstiger wird, ist Wissen alles. Was sich in den letzten anderthalb Jahren spürbar verändert hat, ist, wie es nach der kollaborativen Modellierung weitergeht.
Je nach Ziel der Session ist es heute nicht mehr ungewöhnlich, dass der nächste Schritt direkt in einer Prototyping-Phase mündet – etwas, das früher als zu aufwendig oder zu teuer galt. KI-Tools nehmen inzwischen direkt unsere Artefakte auf – ob Fotos von voll beklebten Wänden oder Exporte aus Miro-Boards – und erzeugen daraus Prototypen oder bringen Inhalte in Reinschrift, etwa indem aus einer fotografierten Event-Storming-Wand ein interaktives Board wird. Das ist keine Vision mehr, sondern gelebte Praxis, die sich immer weiter verbreitet.
Daniel:
Ich würde den Blick noch etwas weiten. Externalisieren bedeutet im weiteren Sinn, dass wir uns mit Wissensweitergabe und Kommunikation beschäftigen. Und das ist kein neues Problem. Was im Gang, an der Kaffeemaschine oder in einem verpassten Workshop besprochen wird, erreicht viele nie, und ein LLM schon gar nicht.
Bisher war es schlicht zu aufwendig, dieses Wissen festzuhalten. Heute geht das schneller als je zuvor. Die neue Herausforderung ist die Informationsflut.
Deshalb verändert sich auch, wie wir Sessions abschließen: Statt alles zu digitalisieren, fragen wir bewusst, ob das Erarbeitete konkret, wichtig und richtig genug ist, um erhalten zu bleiben, oder ob es vor allem ein Zwischenschritt war, der uns als Gruppe zu einem gemeinsamen Verständnis gebracht hat. Diese Unterscheidung zu treffen, ist eine Stärke kollaborativer Modellierung.
KI schickt sich ja an, die Software-Entwicklung insgesamt zu revolutionieren. Spielt KI für dieses Training auch eine Rolle?
Eberhard:
Durch KI wird mutmaßlich die Geschwindigkeit, mit der Code erzeugt, erhöht. Aber Code ist kein Asset. Das Asset ist der Wert der Software, der sich letztendlich darin ausdrückt, wie gut die Software den Business Case unterstützt. Das Optimum ist, wertvolle und nützliche Software mit möglichst wenig Code zu erstellen.
Im Fokus der KI-Diskussion steht aber das billige Erstellen von Code. Das heißt nicht, dass das Richtige entsteht. Billiger Code, der keinen Wert hat, ist schlicht Verschwendung.
Um wertvolle Software zu entwickeln, ist Wissen über die Domäne zentral und ein Austausch der verschiedenen Rollen. Das ist gerade der Fokus von kollaborativer Modellierung. Wenn das Erstellen von Code billiger wird, werden diese Skills noch wichtiger.
Gleichzeitig geht es um die Interaktion von Menschen. Zwischenmenschliche Beziehungen und Handeln sind nichts, was KI automatisieren kann. Daher ist kollaborative Modellierung gerade jetzt so wichtig.
Tom:
Ja, KI spielt für die Einordnung und Bedeutung kollaborativer Modellierung im Training eine wichtige Rolle. Wir greifen auf, wie sich Software-Entwicklung durch KI verändert und warum das gemeinsam erarbeitete Verständnis dabei so entscheidend ist.
Der Schwerpunkt liegt auf den Fähigkeiten, dieses Wissen gemeinsam zu entwickeln und explizit zu machen. Je mehr KI in der Software-Entwicklung übernimmt, desto wichtiger wird das, was wir im Training vermitteln.
Daniel:
Ein Risiko sehe ich darin, dass KI in Sekunden überzeugend aussehende Modelle erzeugt. Das erweckt leicht den Eindruck, man sei sich einig, obwohl nie jemand gemeinsam darüber gesprochen hat.
Ein generiertes Modell kann ein guter Gesprächsanlass sein, ersetzt aber kein gemeinsames Verständnis. Erst dieses Verständnis ermöglicht es, bewusst Entscheidungen zu treffen, die halten und auf die man bauen kann.
Wenn Teams damit erfolgreicher werden, ist der erste Schritt zu besseren Entscheidungen getan, und damit auch die Grundlage für mehr Wirkung im eigenen Unternehmen und in den Produkten für die Kund:innen.
Vielen Dank an Tom Asel, Eberhard Wolff und Daniel Sack für eure Einblicke und Sichtweisen zum Thema kollaborative Softwaremodellierung!