Good software architecture is not created in isolation. Bringing together different perspectives, developing a shared understanding, and making informed decisions are among the key challenges of modern software development.
This is where the new iSAQB module COSMO (Collaborative Software Modeling) comes in. It introduces collaborative modeling methods and techniques that help teams visualize complex relationships, connect business and technical perspectives, and make sound architectural decisions together. Another key focus is preparing and facilitating collaborative modeling sessions.
We spoke with the three curators, Eberhard Wolff, Daniel Sack, and Tom Asel. In this interview, they explain how COSMO came about, why a shared language is essential for successful architecture work, what role facilitation plays, and why collaborative modeling is becoming increasingly important in the age of AI.
COSMO is now the 22nd Advanced Level module in the iSAQB portfolio. Who is the module primarily intended for, what are its main areas of focus, and what should participants ideally bring to get the most out of it?
Daniel Sack:
Many of today’s challenges are too complex for one person to solve alone. This is especially true when different departments need to work together on a solution and conflicting objectives come to light. This is exactly where COSMO comes in: with collaborative methods that bring different perspectives to the table and facilitation that helps a group reach a solution everyone can support.
Eberhard Wolff:
The module focuses on collaborative modeling. This is one part of Domain-Driven Design, where people work together to explore and understand the domain. But there are also techniques for making other architectural decisions collaboratively.
All these techniques are designed to enable more people to participate in modeling. Accordingly, the training is open to anyone interested in modeling and collaboration. A basic understanding of software architecture is certainly helpful. However, virtually everyone working on IT projects is familiar with the typical challenges in these areas.
Tom Asel:
What matters most to me is that participants can establish collaborative architecture practices in their everyday work. Architects learn how to involve their teams more actively. Developers learn how to take responsibility for architecture themselves and help shape decisions together.
Achieving this requires more than modeling techniques. That’s why we also address the organizational conditions: How much autonomy does a team need? How do hierarchies and established roles influence collaboration? And how can teams get started when conditions are less than ideal? Participants should leave with concrete ideas they can apply in their own environments.
This is also valuable for team leads, test managers, and project managers who work closely with development teams. Experience with software projects and a willingness to question established roles and ways of working are helpful.
How did the idea of developing COSMO as a standalone module come about? What gap did you identify in the existing CPSA-Advanced Level portfolio, and how did your collaboration as three curators with different backgrounds evolve?
Tom Asel:
I’ve long viewed architecture work as a team sport. Nevertheless, in practice, I often see strict divisions of responsibility, bottlenecks, and knowledge monopolies being accepted as inevitable.
Yet communities focused on collaborative software development have long established effective practices. iSAQB Advanced Level modules such as AGILA and DDD address some of these practices, but their specific focus leaves little room to explore them in greater depth. We wanted to close that gap and bring this knowledge together in a way that would benefit software architecture education and the architecture community.
Our strength as a team of three is that we bring different backgrounds and areas of experience that complement one another very well. We didn’t just develop COSMO together; we also learned a great deal from each other along the way.
It started in 2025, when I discussed the idea with members of the COMO community. Daniel was immediately on board, and COSMO grew out of our initiative. When Eberhard joined, curriculum development really gained momentum. He shared our enthusiasm, contributed his experience and fresh perspectives, and helped us refine the content and scope.
Daniel Sack:
There’s a simple reason why I was immediately on board. As one of the organizers of ComoCamp, making Collaborative Modeling (COMO) more accessible is something I care deeply about.
Ever since the first camp, I’ve heard the same questions again and again: “How do I actually get started?” or “That wouldn’t work at our company because…”
With COSMO, we’ve created a starting point for everyone facing these challenges, within a framework that is recognized in the software architecture community.
The curriculum places great emphasis on deliberately developing a shared language (Ubiquitous Language) within a team. In practice, how can you tell when a team lacks this shared language, often before anyone even realizes it? And what is a typical obstacle to developing a common understanding of terminology?
Eberhard Wolff:
Clarifying terminology leads to discussions about the business domain. These discussions, in turn, help clarify business requirements.
Collaboration can only succeed when everyone involved speaks the same language. Establishing a shared language is therefore central to software development.
Software also relies on consistent terminology: code is deterministic and, by necessity, unambiguous. If you don’t use a shared and unambiguous language during design, software development cannot truly succeed because you cannot achieve that determinism.
Tom Asel:
We often notice it when everyone uses the same term but means different things when discussing concrete examples. As long as the conversation remains abstract, this is hardly noticeable. Only when we walk through a specific process together does it become clear that the apparent agreement doesn’t actually exist.
A common pitfall is therefore assuming that using the same words means sharing the same understanding.
The gap between development teams and business departments often remains undiscovered for a long time when communication happens mainly through documents or tools, with too little collaborative work and direct conversation.
Collaborative modeling creates a space where we can question terminology together, using concrete examples to clarify what terms actually mean.
This becomes even more important with AI: If we can implement things faster, we need to understand even more precisely what we actually want to build.
Daniel Sack:
Other warning signs include “translators”: individuals without whom communication between business departments and development teams simply doesn’t work. Another sign is code that uses different names for things than the business department does.
A second pitfall is the opposite of apparent agreement: trying to impose a single, binding definition across an entire organization.
A “customer” means something different in sales than in accounting, and that’s perfectly fine. A shared language always applies within a particular context. The goal is to be clear about what a term means in each context.
The curriculum clearly distinguishes between the facilitator’s role and actively contributing to architectural decisions. At the same time, the same person often takes on both roles. How can architects, who usually have a clear professional opinion about the “right” solution, adopt a neutral facilitator mindset without completely setting aside their own expertise?
Eberhard Wolff:
Good architects need to cover both aspects. They cannot possess all the expertise required for every technical and business detail. Instead, they need to draw on the knowledge of the entire team and make that expertise available to the project.
That’s why facilitation is already an essential part of successful architecture work.
Responding to everyone’s input while also contributing your own knowledge, without simply making all the decisions yourself, is the key challenge of collaborative architecture work.
The facilitation component of the training develops and strengthens precisely these skills. In addition, the training aims to provide concrete ideas for improving collaboration through collaborative modeling techniques such as Event Storming, rather than relying on general facilitation skills alone.
Daniel Sack:
While traditional facilitation emphasizes neutrality and focuses on the process level, such as timing, logistics, and guiding discussions, collaborative modeling also involves facilitating at the content level, where the shared mental model takes shape.
Visualization helps make what is being said accessible to everyone. Architectural expertise helps us understand constraints and evaluate trade-offs.
The key is to consciously manage your role as a facilitator or participant and communicate that role openly.
Tom Asel:
First, you need to become aware of your own biases, shaped by opinions, habits, and experience. In COSMO training courses, participants learn to recognize these biases in themselves and others and deal with them consciously.
An overly simplistic approach would be to have someone without architectural experience facilitate the session. We reject that approach.
In our view, facilitating architecture workshops requires architectural expertise. You need that expertise to assess whether discussions are moving in a productive direction, intervene when necessary, and provide guidance when the group gets stuck.
The point is to use your own expertise deliberately without making your personal idea of the right solution the standard for the entire session.
The challenge is to provide architectural guidance while remaining open to other perspectives and possible solutions.
The curriculum explicitly identifies power imbalances and dominant participants as risks to the quality of a session, while also highlighting the opportunity to give underrepresented perspectives a stronger voice. Is there a specific technique that reliably ensures quieter or less senior participants are heard?
Daniel Sack:
Power imbalances often operate unnoticed. People with high rank, whether because of their position, experience, or role, usually don’t realize how much others are holding back.
That’s why we need techniques for two distinct moments: when ideas are being collected and when the group is making decisions.
When making decisions, I deliberately ask who sees things differently and what it would take for that person to support the decision. Often, that’s exactly where the knowledge lies that would otherwise have been missing later.
Eberhard Wolff:
First, this is a responsibility of facilitation and moderation: everyone should be heard and have the opportunity to participate in the session.
Simply having someone in that role helps prevent dominant individuals from spontaneously taking over the discussion or putting themselves at the center of attention.
Collaborative modeling techniques also support this goal, and it’s a very important aspect of these methods.
It starts with seemingly minor details. When everyone writes sticky notes instead of only expressing their ideas verbally, people who would otherwise stay in the background during discussions have an opportunity to contribute.
You can also ensure that all the sticky notes are incorporated into the outcome, so everyone’s input is taken into account.
Tom Asel:
One specific technique is to collect options initially without revealing who suggested them. This puts the content of each contribution at the center of attention.
A person’s experience or seniority then has less influence on which ideas receive attention. After all, even the most experienced colleague doesn’t automatically have the best or only relevant answer.
Facilitators need to recognize underrepresented perspectives and create equal opportunities for participation. This also means becoming aware of their own assumptions and preferred solutions and dealing with them consciously.
No single technique can guarantee this. It takes practice and awareness of the dynamics in the room. That’s precisely why it’s worthwhile for architects who facilitate workshops to deliberately develop these skills.
You say that externalizing tacit knowledge not only improves human collaboration but also enables better results with LLMs. Is this already changing how you design sessions or document outcomes? Are the outputs of collaborative modeling sessions now being fed into AI tools in a structured way, or is that still more of a future promise?
Tom Asel:
Definitely. As AI tools make code generation increasingly inexpensive, knowledge becomes everything. What has noticeably changed over the past year and a half is what happens after collaborative modeling.
Depending on the goal of the session, it’s no longer unusual for the next step to lead directly into a prototyping phase, something that previously would have been considered too expensive or time-consuming. AI tools can now work directly with our artifacts, whether they’re photos of walls covered in sticky notes or exports from Miro boards.
They can generate prototypes from these artifacts or turn the content into a clean, structured format. For example, a photograph of an Event Storming wall can be transformed into an interactive board. This is no longer a vision of the future. It’s already happening in practice and becoming increasingly widespread.
Daniel Sack:
I’d like to take a slightly broader view. In a wider sense, externalizing knowledge means dealing with knowledge sharing and communication. And that’s not a new problem. Things discussed in hallways, over coffee, or during workshops that someone missed never reach many people, let alone an LLM.
Until now, capturing that knowledge was simply too time-consuming. Today, we can do it faster than ever before. The new challenge is information overload.
That’s why the way we conclude sessions is also changing. Instead of digitizing everything, we consciously ask whether what we’ve developed is concrete, important, and accurate enough to be preserved, or whether it was primarily an intermediate step that helped us reach a shared understanding as a group. Being able to make that distinction is one of the strengths of collaborative modeling.
AI is poised to revolutionize software development as a whole. Does AI also play a role in this training?
Eberhard Wolff:
AI will presumably increase the speed at which code can be generated. But code is not an asset. The real asset is the business value of the software, which ultimately depends on how well it supports the business case. The ideal is to create valuable and useful software with as little code as possible.
However, much of the AI discussion focuses on generating code cheaply. That doesn’t mean the right thing is being built. Cheap code that delivers no value is simply waste.
Developing valuable software requires domain knowledge and communication between people in different roles. That’s precisely what collaborative modeling focuses on. As code generation becomes cheaper, these skills will become even more important.
At the same time, collaborative modeling is about human interaction. Interpersonal relationships and human behavior are not things AI can automate. That’s why collaborative modeling is particularly important right now.
Tom Asel:
Yes, AI plays an important role in how we position collaborative modeling and explain its significance during the training. We address how AI is changing software development and why a shared understanding developed through collaboration is so crucial.
The focus is on the skills needed to develop this knowledge together and make it explicit. The more AI takes on in software development, the more important the skills we teach in this training become.
Daniel Sack:
One risk I see is that AI can generate convincing-looking models in seconds. This can easily create the impression that everyone agrees, even though no one has actually discussed the model together.
A generated model can be a useful starting point for discussion, but it cannot replace a shared understanding. Only that shared understanding enables teams to make deliberate, sound decisions they can rely on.
When teams become more successful at this, they’ve taken the first step toward better decisions and laid the foundation for greater impact within their organizations and in the products they build for their customers.
Many thanks to Tom Asel, Eberhard Wolff, and Daniel Sack for sharing their insights and perspectives on collaborative software modeling!