Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
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?
Published at DZone with permission of Dan Pritchett , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.