Collaborative Modeling
In his book The Mythical Man Month, Fred Brooks says that conceptual integrity is the most important consideration in system design. This is common sense. You can’t deliver a systemic change together if you can’t conceptualize and discuss it.
Understanding a system, as a whole and in parts, informs (ideally) how we act. This understanding arises from abstraction as well as code. Not everyone speaks code. When we look at a system strictly through the prism of its technological toolset, we distort our understanding of it.
A technology system is like the parable of the blind men and the elephant. Six blind men are touching the elephant. The man touching the side says “an elephant is like a wall!” The man touching the trunk says “an elephant is a type of snake!” The ears are like a fan. The tail is like a rope. A system is the integration of these concepts and experiences.
Brooks goes on to say that ideally, conceptual integrity is maintained by one person, or a small group of like minds. Perhaps this is true, but as complexity increases, this is often not possible. Or ideal – one person can become the cognitive bias through which decisions flow and are skewed.
Deep schisms in the system’s functional architecture open when people are speaking different languages to describe it. The "wall" people talk business and the "snake" people talk infrastructure and the "fan" people talk marketing tools and the "rope" people deliver code. How do you create conceptual integrity between the wall and the snake and the fan and the rope as the software system, and the world around it, changes?
Enter collaborative modeling. Whenever two or more people are gathered, use modeling to make the elephant visible. Modeling together can help reveal disparities that are hidden behind the cloak of language.
Lack of shared mental models is also a barrier to understanding. Opening a Miro board or pulling out yellow sticky notes can be the fastest and most effective way to create shared insight. While people involved are agreeing on the shape and flow of activities in a system, they are also agreeing on what to call them. And they are cultivating significant-enough shared understanding to seed further discussions and decision making.
Where do you begin?
The domain-driven design (DDD) community has made a concerted effort to bring collaborative modeling out into the world. This edition isn’t about DDD specifically, but most of the teachers here are part of that community. Their success depends on modeling things effectively and impactfully with others. So they’ve practiced.
Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy
by Vlad Khononov
I’ve used exercises from this book three times, in situations where our group was stuck. In all cases, we got unstuck and enjoyed the process. This book is easy to read, friendly, straightforward and a deceptively powerful approach.
Visual and Collaborative Modelling
by Kenny Baas-Schwegler
This is a delightful talk about why collaborative modeling matters and how to approach it. Kenny is an excellent teacher and facilitator, making the process both effective and enjoyable.
Facilitating Collaborative Design Decisions
with Kenny Baas-Schwegler, Gien Verschatse,and Evelyn Van Kelle
This team is literally writing the book on Collaborative Modeling. (Watch for it in further editions!)
Essential DDD Virtual Workshop
February 2023
taught by Paul Rayner
Paul was my collaborative modeling mentor. He taught me how to structure a process. He also showed me how to be a helpful presence when a group thinks together.
A team may be doing great work in isolation and still mess up the system. -- Eduardo da Silva
