3 ms·

I've actually been wondering about this in regard to microservices. As people switch from monolithic architecture (where one war or package might have both fro

I've actually been wondering about this in regard to microservices. As people switch from monolithic architecture (where one war or package might have both frontend and backend) to microservice architecture, are you finding it useful and necessary to change your team structures? A lot of place have product-focused teams with frontend and backend people mixed together, but as products become more about frontends consuming services, it seems that might imply a different team structure is better. (And kind of a variation of how Conway's law is stated in the OP since the architectural progression is driving the team structure, rather than the other way around.)

jerf 11y ago
Well, I'm sort of running that logic in the reverse direction... I'm pushing microservices because our organization is already set up with a lot of independence in the teams, and we've been struggling for years with coding methodologies that fight that by trying to enforce monolithic coding practices. Conway's law is really important, but like mathematical equality, it doesn't really have a direction. You can bring organization into conformance with code, or code into conformance with organization. The full situation, as always, may suggest one or the other is a better idea, but Conway's law just says that you really need to do one or the other, or you'll pay a price. (Which may also be one you find yourself having to pay for other reasons... sigh... "ask not an engineer whether something is a good idea, for he shall say neither yea nor nay...")