Please enable JavaScript.
Coggle requires JavaScript to display documents.
Team Topologies - Coggle Diagram
Team Topologies
Conway's Law
System's/ Product’s architecture tends to mirror the
structure of the organization in which it is developed.
If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.
The organization is constrained to produce designs that match or mimic the real, on-the-ground communication structure of the organization.
Scenarios
An organization that is arranged in functional silos (where teams specialize in a particular function, such as QA, DBA, or security) is unlikely to ever produce software systems that are well-architected for end-to-end flow.
An organization that is arranged primarily around sales channels for different geographic regions unlikely to produce effective software architecture that provides multiple different software services to all global regions.
-
Organization design and software design are, in practice, two sides of the same coin, and both need to be undertaken by the same informed group of people.
Team design
Low Coupling, High Cohesion
Team-Scoped
Restrict Unnecessary Communication
(Domain Driven Design, Bounded Context)
Conway’s law tells us that an organization’s structure and the actual communication paths between teams persevere in the resulting architecture of the systems built.
-
The design of the organization constrains the “solution search space,” limiting possible software designs.
-
-
Limiting communication paths to well-defined team interactions produces modular, decoupled systems.
Team-First Thinking
-
-
-
-
The team is the most effective means of software delivery, not individuals.
An effective team size
-
-
-
Dunbar’s number
-
-
-
Around five people—limit of people with whom we can hold close personal relationships and working memory
-
-
-