Agile Zone is brought to you in partnership with:

My engineering career spans 25 years and includes research on relational databases, designing geographic map software, building email products, and creating scalable web applications. I am currently CTO at Rearden Commerce. Dan is a DZone MVB and is not an employee of DZone and has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

Conway's Law

11.29.2010
| 4736 views |
  • submit to reddit

How many of you have heard of Conway's Law? Melvin Conway postulated in 1968 that:

...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

I usually paraphrase it into:

Software architectures will reflect the structure of the organization that built them.

Of course stated like that, there is a sense of fatalism. Our organization structure is possibly flawed, sub-optimal so of course we'll wind up with a software architecture that is also flawed and sub-optimal. I prefer to look at the law from the other direction though. Start with the architecture, then derive the organization.

This is something that is contrary to how most companies think though. The idea that you would create your architecture component diagram first, then design your entire technology organization to support the architecture isn't your typical process. In some cases it works out that way through organic growth or even through a logical accident of fate where teams form as components spin off. These fortunate evolutions, when they occur, provide the framework for good architectures, but why leave this as an accident of fate?

Starting a new product? Start with a small senior team and focus on determining your component architecture. From there, you can create your organization to deliver that architecture. The teams will become obvious, formed around components so that high frequency communication occurs within teams and lower frequency communication across teams. Your component interfaces become your team communication boundaries. Of course, this also lends itself well to agile processes which is an additional benefit.

What if you have a legacy architecture? How do you improve your existing architecture? The same way. Figure out how you want your architecture to look and then before doing any engineering work, reorganize to create an organization structure that reflects the desired software architecture. This will potentially be suboptimal in the beginning but it will become a forcing function to drive change. The benefit is that the organization will draw the new architecture out of the code because it's the only way the teams can become more effective.

Approaching organizations in this way provides the opportunity to form teams with a higher sense of ownership as well. So many companies attempt to achieve quality through process, governance, checklists, sign offs, and many other impediments to delivery. The hope is that through all these processes poorly built software will not be released to site. The reality is the best way to achieve high quality software is to give people a sense of ownership in the code they write.

If you align your organization around your architecture and create teams that fully own a component, then the natural result is a better quality product. Quality that becomes inherent and owned by the people creating the software, without heavy processes that impact the efficiency of the team.

Ready to apply Conway's law to your company?

References
Published at DZone with permission of Dan Pritchett, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Emma Watson replied on Fri, 2012/03/30 - 3:57am

I think the main gist of the law is that in order to improve your codebase, you really need to work on your organization and vice versa. Just throwing some hip new techniques to the coders and expecting that to do the trick won't do the trick. It's more complicated than that. :)

JDBC

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.