4 ms·

Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department. Even better is

by kitd 9y ago

Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department. Even better is that such an architecture requires (or at least greatly benefits from) specifying precisely the communication between the interacting parts in the form of interfaces. IIRC there is a study that Steve McConnell mentions in one of his books (sorry, I can't find the link) that shows that the number of bugs introduced into system is highly correlated to the number of lines of communication between the people or teams that write it. Add another team and that number potentially rises exponentially. Conway's Law is the scaffold on which all these understandings hang.

kristianc 9y ago
> Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department. I wouldn't say Conway's Law validates a decision to move to an SOA, so much as further enshrines it in code. There is something to be said for forcing different business units or departments to work together.
SideburnsOfDoom 9y ago
> Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department. Organising the business units around the desired deployables is also know as "the Inverse Conway Maneuver" https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver https://www.thoughtworks.com/radar/techniques/inverse-conway... http://betica.com/blog/2016/06/17/transform-your-organization-with-the-inverse-conway-maneuver/ http://betica.com/blog/2016/06/17/transform-your-organizatio...
vlehto 9y ago
So it's "microservices" now? Mongols figured out around year 1200 that in a proper military organization, you have one boss and maximum of about 10 subordinates and 10 peers. Though it was already written about by Sun Tzu way earlier. Chain of command ought to be clear from private to general. Romans had earlier found out that a group of about 100 men is good department size for day to day operations. (Roughly the Dunbar number of the least capable members of the group.) Then commercial companies noticed that they don't have to abide to military hierarchy. But they didn't notice the underlying biological tendencies. As a result every second industry fad is reinventing the same social structure over and over again. Factory with departments -> open plan office -> teams -> matrix organization -> sprints -> (I lost track here) -> microservice? Every company has problems. If the biggest problem is poor flow of information between departments/teams, then that company has competitive advantage to the guys who have some serious issues.
tabtab 9y ago
Not necessarily. It depends how you define "service". There are two interpretations of Conway's Law: 1) orgs "just" end up making software partitioned like the org structure due to human nature, or 2) orgs should partition software like the org structure. My experience heavily leans to #2. If your software doesn't "fit" the org, friction happens. For example, if you try to share a common service but there is nobody with sufficient power and staff to manage and coordinate changes in that service, then it's not clear who to blame when bleep happens. A technician can make a shared service, but then the technician is left holding the responsibility bag when there are conflicts or complaints among the shared service users. Managers don't want to let "lowly" techies control such decisions. Almost nobody is used to that. Either create a formal org sub-structure with a sufficiently ranked manager(s) to coordinate the shared service, or split it and live with redundancy.

by kitd 9y ago

kristianc 9y ago

> Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department. I wouldn't say Conway's Law validates a decision to move to an SOA, so much as further enshrines it in code. There is something to be said for forcing different business units or departments to work together.

SideburnsOfDoom 9y ago

> Conway's Law validates a decision to move to a service-oriented and/or microservice architecture. Each service ~= a business unit or department. Organising the business units around the desired deployables is also know as "the Inverse Conway Maneuver" https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver https://www.thoughtworks.com/radar/techniques/inverse-conway... http://betica.com/blog/2016/06/17/transform-your-organization-with-the-inverse-conway-maneuver/ http://betica.com/blog/2016/06/17/transform-your-organizatio...

vlehto 9y ago

So it's "microservices" now? Mongols figured out around year 1200 that in a proper military organization, you have one boss and maximum of about 10 subordinates and 10 peers. Though it was already written about by Sun Tzu way earlier. Chain of command ought to be clear from private to general. Romans had earlier found out that a group of about 100 men is good department size for day to day operations. (Roughly the Dunbar number of the least capable members of the group.) Then commercial companies noticed that they don't have to abide to military hierarchy. But they didn't notice the underlying biological tendencies. As a result every second industry fad is reinventing the same social structure over and over again. Factory with departments -> open plan office -> teams -> matrix organization -> sprints -> (I lost track here) -> microservice? Every company has problems. If the biggest problem is poor flow of information between departments/teams, then that company has competitive advantage to the guys who have some serious issues.

tabtab 9y ago

Not necessarily. It depends how you define "service". There are two interpretations of Conway's Law: 1) orgs "just" end up making software partitioned like the org structure due to human nature, or 2) orgs should partition software like the org structure. My experience heavily leans to #2. If your software doesn't "fit" the org, friction happens. For example, if you try to share a common service but there is nobody with sufficient power and staff to manage and coordinate changes in that service, then it's not clear who to blame when bleep happens. A technician can make a shared service, but then the technician is left holding the responsibility bag when there are conflicts or complaints among the shared service users. Managers don't want to let "lowly" techies control such decisions. Almost nobody is used to that. Either create a formal org sub-structure with a sufficiently ranked manager(s) to coordinate the shared service, or split it and live with redundancy.