3 ms·

The bit about Conway's Law >Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's comm

The bit about Conway's Law >Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. is mind blowing. How did I not notice this the whole time? Awesome article. <3

eightysixfour 6y ago
A lot of the job of effective large organizational software/management consultants is understanding where there are mismatches between org structure and software architecture and helping to drive changes to get those in alignment. A big part of this is finding better places to put the interfaces (whether they are human or API), because they're usually holdovers from the past and no longer related to the business structure or architecture.
steerpike 6y ago
It's colloquially described as "shipping the org chart". Which I always liked as a way to describe it to a wider audience.
ako 6y ago
You can use this to change the architecture of your software: change the structure of your teams, and your software architecture will follow.
layoric 6y ago
Here is a post by Martin Fowler James Lewis in 2014 pointing out the same thing [0]. A lot of the thoughts expressed there I think are still relevant but I guess we had to wait for this hype cycle to play out? [0] https://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities https://martinfowler.com/articles/microservices.html#Organiz...
baq 6y ago
note the law doesn't specify if this is by necessity/on purpose - but designing a system which doesn't do that is usually setting yourself up for failure.
vishnugupta 6y ago
It takes one to "experience" this phenomenon from the inside of an org to appreciate it. Analogous to how one would have to work on largish codebase/architectures to appreciate design patterns. I have a corollary to Conway's Law. The number of network hops an end customer's request goes through before it is served is directly proportional to the number of teams in that org. A native English speaker could help me simplify that sentence :-)

eightysixfour 6y ago

A lot of the job of effective large organizational software/management consultants is understanding where there are mismatches between org structure and software architecture and helping to drive changes to get those in alignment. A big part of this is finding better places to put the interfaces (whether they are human or API), because they're usually holdovers from the past and no longer related to the business structure or architecture.

steerpike 6y ago

It's colloquially described as "shipping the org chart". Which I always liked as a way to describe it to a wider audience.

ako 6y ago

You can use this to change the architecture of your software: change the structure of your teams, and your software architecture will follow.

layoric 6y ago

Here is a post by Martin Fowler James Lewis in 2014 pointing out the same thing [0]. A lot of the thoughts expressed there I think are still relevant but I guess we had to wait for this hype cycle to play out? [0] https://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities https://martinfowler.com/articles/microservices.html#Organiz...

baq 6y ago

note the law doesn't specify if this is by necessity/on purpose - but designing a system which doesn't do that is usually setting yourself up for failure.

vishnugupta 6y ago

It takes one to "experience" this phenomenon from the inside of an org to appreciate it. Analogous to how one would have to work on largish codebase/architectures to appreciate design patterns. I have a corollary to Conway's Law. The number of network hops an end customer's request goes through before it is served is directly proportional to the number of teams in that org. A native English speaker could help me simplify that sentence :-)