Development Teams Are Software: Team Topologies and Domain-Driven Design Map How
When you struggle to find the proper design for your software, you may need to fix how you designed your teams
As Matthew Skelton writes in the first pages of his Team Topologies: Organizing Business and Technology Teams for Fast Flow (non-affiliated link):
The key takeaway here is that thinking of software architecture as a standalone concept that can be designed in isolation and then implemented by any group of teams is fundamentally wrong.
Software architectures and people are two gears of the same engine, but manipulating software is much less sensitive than organizing people. That’s why organizations often design teams as if they were other than the software they produce.
Conway’s law says:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Don’t look at this “law” as a dogma; treat it as a hypothesis to check because even if it doesn’t apply to your organization — never say never — it forces you to focus on the edge between humans and software. Assuming that your organization delivers software made by humans for humans, that edge is where the business value sparks: it’s worth it to explore how.
Explorations require target territories to reach and maps to orientate. In this article, territories are software and teams — the teams that develop software; Domain-Driven Desing is the software’s map, and Team Topologies are the teams’ maps.
Communication
Information flows through software systems, while knowledge flows through teams: for both, communication is what makes them work.
Besides, software systems and teams communicate to fulfill a purpose that shapes the boundaries and languages of communication.
Look at the types of teams — as the Team topologies define them:
Now, look at the types of subdomains — as the Domain-Driven Design defines them:
Eventually, add to the equation the bounded context, which:
- Consists of a set of subdomains
- Is developed by one team
- Has its ubiquitous language
In the end, the title’s statement — teams are software — arises:
Teams are the software because their communication style adheres to one of the software components. And the same happens when teams and bounded contexts integrate:
Consequences
Conway’s law is an isomorphism law: it says that maps to explore software and maps to explore teams that make software map one over the other.
Team topologies, the teams’ side, and Domain-Driven Design, the software side, are a manifestation of this law.
Conclusion
It’s common sense, but now we have a formal way of stating it: people — software development teams — are part of the software they deliver.
On the other hand, the software calculates, so it requires processing capability. Team side, that’s cognitive load:
Cognitive load was characterized in 1988 by psychologist John Sweller as “the total amount of mental effort being used in the working memory.” [Skelton, Matthew; Pais, Manuel. Team Topologies (p.81). IT Revolution Press.]
The cognitive load deserves a dedicated article. What’s relevant to highlight here is the awareness that teams mirror software as they are the hardware of the communication flow that builds the software. That’s why teams are software.
